架构师必备：缓存更新模式总结

大家好，我是Java烘焙师。如何更新缓存和DB、做到性能和一致性的取舍，是一个很常见的话题。下面结合笔者的经验和思考，系统性地总结一下缓存更新模式，讲透讲明白。

1、旁路缓存（cache-aside）

实现方案

• 查询：先查缓存，查不到缓存时再查DB，并把DB内容写入缓存、设置合适的过期时间
• 更新：先更新DB，再删缓存；做到极致则需引入延迟双删机制

之所以不是先删缓存、再更新DB，是因为在这两个操作间隙，如果有其它查询请求，则会把DB旧值写到缓存。

之所以不是先更新DB、再更新缓存，是因为写DB和缓存无法保证一致性，并且可能因为2个并发写的时序问题而把旧数据写到缓存。

之所以延迟双删，是因为在极端情况下，读线程会把DB旧值写到缓存。需要同时满足几个条件：缓存已过期，并且读线程先查询到DB旧值，然后写线程更新DB、删除缓存之后，读线程才把DB旧值写入缓存。如下图所示。

因此第一次删除缓存后，延迟一小段时间再删除，就能保证缓存和DB的最终一致。下图是引入了延迟双删机制的cache-aside架构图。

cache-aside查询场景：

cache-aside更新场景：

适用场景

• 绝大部分场景

优点

• 当数据量大时，可按需加载到缓存

缺点

• 如果存在热点key，在失效后，会有大量查询请求穿透缓存，直接打到DB，造成DB CPU使用率飙升

旁路缓存优化：主动预刷新缓存

为了解决热点缓存失效问题，可考虑设置TTL为较长时间，并主动预刷新热点key。

根据数据量大小区分：

• 如果数据量较大，则针对热点key，配置白名单。做得更好的话，是自动发现、并更新热点key白名单。
• 如果数据量较小，则可以考虑全部加载到缓存中，永不过期。如：一些全局的配置数据。

根据触发刷新缓存的时机区分：

• 定时拉取：程序自行实现，根据热点key白名单，定时查DB、并更新缓存
• 异构数据：监听mysql变更，DB变化时触发更新缓存

更推荐异构数据的方式，好处是：缓存更新及时，并且做成通用功能之后、无需额外开发。

2、异步写回DB模式（write-back）

实现方案

• 查询：只查询缓存
• 更新：先写入缓存，然后发消息、消息链路异步写入DB，或定时任务兜底写入DB

适用场景

查询qps很高、极其热点的数据，优先保证性能。

场景举例：

• 计数统计：有的页面会滚动刷新访问人次、使用人次
• 爆品库存扣减：redis扣减库存，然后异步落库，而不是常规地操作DB扣减库存

优点

• 支撑高qps、热点场景

缺点

• 短期内会出现缓存和DB数据不一致情况，需要消息触发、或兜底定时任务写回DB

3、read/write through模式

实现方案

不论是cache-aside、还是write-back模式，都需要应用程序自己来控制读写缓存、DB。而read/write through模式是把控制权交给底层存储服务。

存储服务维护缓存、持久化数据，应用程序无需感知，这也是优点了。不过完全依赖于存储服务是否靠谱，实际业务场景并不常见。

4、持续优化

搭积木方式，根据实际情况做优化。

多级缓存：进一步降低缓存、DB的热点风险

• 增加本地缓存，如caffeine
• 或增加DB以外的异构数据，当查不到缓存时再查异构数据、查不到异构数据时最终查DB。异构数据可以是HBase、ES等

通过逻辑层面来实现生效、过期的效果，而非系统层面

• 架构设计必须适配业务，比如通过逻辑过期解决不一致、缓存集中过期的问题，如缓存记录业务开始时间、结束时间，TTL可设置稍长些、并且通过增加随机时长来避免key集中失效。这样就能实现到时间点就变的场景，如活动开始、结束。

强一致场景，只查DB、已DB数据为准

• 特别地，对一致性有强要求的场景：只查DB、不查缓存，以DB数据为准。如下单时查询DB里的价格，避免缓存数据非最新。

更进一步，考虑使用rocksdb，代替redis

• rocksdb相当于是自带缓存的持久化数据库，值得专门写一篇文章介绍原理、区别，后面有空整理。

结论

• 绝大部分场景，使用旁路缓存模式（cache-aside）。更进一步，对部分热点key做主动预刷新，可监听DB变更、或定时刷新。
• 高qps、极热key场景，使用异步写回DB模式（write-back），优先保证性能，可接受短时间内DB与缓存不一致。
• 持续优化：
  • 增加多级缓存、异构数据，来降低缓存、DB的热点风险
  • 通过逻辑层面来实现生效、过期的效果
  • 强一致场景，只查DB、已DB数据为准

延伸阅读：笔者之前写的缓存相关文章，欢迎围观。

• 架构师必备：本地缓存原理和应用
• Spring cache源码分析