我应该实现自己的缓存还是依赖只读副本？

Question

我们有一个使用 SQL 数据库的企业应用程序。数据库访问特征是大约 90% 的读取。更新或创建的数据需要立即更新。缓存需要以高确定性正确失效。在 98% 的情况下，实体由其主键引用。

该应用程序基于 Node.js 并且是 AWS 原生的。由于该应用程序是 AWS 原生的，因此我希望依赖 AWS 的托管服务，而不是托管自己的服务。一种选择是实现我们的基于 Redis 的读取缓存。检索实体后，我们会检查缓存，如果数据未缓存，我们会将其放入缓存中，然后再将其提供给用户。更新这些实体的代码部分将通过主键使缓存无效。

一般来说，在计算机科学中，缓存一致性是最难解决的问题之一。我的观点是，与其实现 Redis 缓存并考虑所有可能的场景以使其正确无效，不如配置一个专门用于读取频繁访问的实体的 Aurora 只读副本更为明智。与我们自己构建的任何东西相比，RDBMS 在缓存方面做得更好。

所以，我面临两种选择——通过自己的缓存实现努力，或者使用只读副本。我个人的意见是使用只读副本。

非常感谢任何建议，一如既往。

Answer 1

是的，你是对的，缓存失效是一个棘手的问题。最简单的解决方案是在数据写入中添加代码，以替换缓存的值。所以他们总是最新的。但这只有在缓存值与数据库中的行具有几乎一对一的相关性时才容易实现。

您自己的缓存的一个优点是您可以缓存非与数据库中的数据行一对一的数据。例如，您可以为下拉菜单缓存整个 HTML 片段。这可能是几个 SQL 查询的结果。可以说，缓存位于“食物链”上游的数据可能是一个相当大的优势。但是缓存失效变得不那么简单了。最适合存储不经常更改的查询结果。

使用只读副本不能替代使用缓存。查询只读副本仍然会产生建立数据库连接、身份验证、SQL 查询解析和优化、锁定以及进入 RDBMS 工作的所有其他开销的开销。

从缓存中查询数据可以快几个数量级。

两者都有自己的位置。对于不同的任务，最好同时使用缓存和只读副本。我还将消息队列添加为一项重要技术。我相信数据库、缓存和队列构成了一个三足凳。

但您必须有经验和判断力才能知道何时每个工具都是特定案例的最佳工具。