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