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

Question

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

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

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

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

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

Answer 1

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

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

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

从缓存中查询数据的速度可以提高几个数量级。

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

但您必须具备经验和判断力，才能知道每种工具何时是针对给定案例的最佳工具。