提问人：Maxx 提问时间：6/21/2023 更新时间：6/21/2023 访问量：377
缓存留存策略：写入后删除或更新缓存？
Cache aside strategy : delete or update the cache after the write?
问：
我正在尝试了解有关缓存旁策略的一些信息。如果找到（缓存命中），则从缓存中读取数据，如果未找到（缓存未命中），则从缓存中读取 + 更新的数据。
在写入时，它被放在主数据库中，然后缓存应该通过以下方式更新：
- A：删除缓存中对应的条目（所以下次读取时会遇到缓存未命中并更新缓存）
- 或者 B ： 更新缓存中的相应条目（所以如果下次读取发生在缓存条目 TTL 之前，则会遇到缓存命中）
我不明白解决方案 A 和 B 的优缺点是什么。使用 redis，两者似乎都很容易实现，但我想还有其他考虑因素。
答：
2赞
for_stack
6/21/2023
#1
这两种解决方案都试图使数据库更改尽快同步到缓存，即使数据库和缓存尽可能一致，以便应用程序代码可以读取（可能的）最新数据。
以下是每种解决方案的缺点。
解决方案 A：删除缓存中的项目
如果项目更新非常频繁，则此解决方案会一直删除缓存条目，并且会收到大量缓存未命中。大多数请求都会命中数据库，并使缓存变得无用。
解决方案 B：更新缓存中的项
此解决方案可能会将不常见的项目插入到缓存中，并降低缓存命中率。当数据库中的项目更新时，您不知道它是否是热门项目。如果它是冷项，并且您将其插入到缓存中，则可能会从缓存中逐出热项（因为缓存大小有限）。
缓存不一致问题仍然存在
尽管这两种解决方案都试图使缓存尽可能保持一致。他们不能保证这一点。以以下案例为例。
- 客户端 A 读取缓存，发现缓存不存在。
- 客户端 A 读取数据库并获取值：old-value。
- 客户端 B 使用新值更新数据库：new-value。
- 客户端 B 使用新值更新缓存或删除缓存中的条目（尽管它可能不存在于缓存中）。
- 客户端 A 使用 old-value 更新缓存。
在这种情况下，缓存仍保留旧值。
解决方案C：结交不一致的朋友
由于您使用的是缓存，因此无法避免与数据库不一致。因此，在大多数情况下，我们在更新数据库时不需要更新/删除缓存项。检查这个和这个了解更多细节。
下一个：计时器在范围内找不到
评论