我们有一个使用 SQL 数据库的企业应用程序。数据库访问特征大约是90%的读取。更新或创建的数据需要立即更新。缓存需要高度确定地正确失效。 98% 的情况下，实体是通过其主键引用的。
该应用程序基于 Node.js，并且是 AWS 原生的。由于该应用程序是 AWS 原生的，因此我希望依赖 AWS 的托管服务，而不是托管自己的服务。一种选择是实现基于 Redis 的读取缓存。检索实体后，我们会检查缓存，如果数据未缓存，我们会将其放入缓存中，然后再将其交给用户。更新这些实体的代码部分将使主键的缓存失效。
一般来说，在计算机科学中，缓存一致性是最难解决的问题之一。我认为，与其实现 Redis 缓存并考虑所有可能的场景以使其正确失效，不如配置一个专门用于读取频繁访问的实体的 Aurora 只读副本更为明智。 RDBMS 在缓存方面比我们自己构建的任何东西都做得更好。
因此，我面临两个选择——努力实现自己的缓存，或者使用只读副本。我个人的意见是使用只读副本。
一如既往，非常感谢任何建议。
是的，你是对的，缓存失效是一个棘手的问题。最简单的解决方案是向数据写入添加代码，以替换缓存的值。所以它们总是最新的。但只有当缓存的值与数据库中的行具有几乎 1 对 1 的相关性时，这才很容易。
您自己的缓存的一个优点是您可以缓存与数据库中的数据行“不”1对1的数据。例如，您可以缓存下拉菜单的整个 HTML 片段。这可能是多个 SQL 查询的结果。可以这么说，缓存“食物链”更高层的数据可能是一个相当大的优势。但缓存失效变得不那么简单。最适合存储不经常更改的查询结果。 使用只读副本并不能替代使用缓存。查询只读副本仍然需要建立数据库连接、身份验证、SQL 查询解析和优化、锁定以及 RDBMS 工作中的所有其他开销。
从缓存中查询数据可以快几个数量级。
两者都有自己的位置。对于不同的任务，最好同时使用缓存
和只读副本。我还将添加消息队列作为一项重要技术。我相信数据库、缓存和队列构成了一个三足凳。 但是您必须有经验和判断力才能知道每种工具何时是针对特定案例的最佳工具。
一般来说，
使用