缓存的三种更新模式

Cache Aside（旁路缓存）#

最常使用的模式。一般由写操作删除cache，读操作设置cache

写#

• 先更新DB
• 然后直接删除 cache

读#

• 从 cache 中读取数据，读取到就直接返回
• cache 中读取不到的话，就从 db 中读取数据返回
• 再把数据放到 cache 中。

缺陷#

缺陷1：首次请求或更新删除cache后，cache不存在，当访问量较大时会将请求打到DB#

• 提前刷入热点数据到cache

缺陷2：可能出现以下情况，主要出现在query中的[select db] 到 [update cache]耗费时间较长，可能中间做了一些代码计算#

• 追求强一致。加入分布式锁，主要保证[clear cache]与[select db]-[update cache]的顺序。缺点影响并发
• 非强一致。
  • 延时双删。当update的[clear cache]完了之后，再做一次[clear cache]，可以采用MQ延时消息，或其他异步手段来触发删除缓存动作
  • [update cache]操作时合理设置cache的失效时间兜底

Read/Write Through（读写穿透）#

服务端把 cache 视为主要数据存储，从中读取数据并将数据写入其中。cache 服务负责将此数据读取和写入 db，从而减轻了应用程序的职责

写（Write Through）：#

• 先查 cache，cache 中不存在，直接更新 db。
• cache 中存在，则先更新 cache，然后 cache 服务自己更新 db（同步更新 cache 和 db）。

读(Read Through)：#

• 从 cache 中读取数据，读取到就直接返回 。
• 读取不到的话，先从 db 加载，写入到 cache 后返回响应。

与Cache-Aside比较#

• Cache-Aside的读操作由客户端负责写入cache，而Read-Through是由cache服务端负责写入cache，对客户端透明

Write Behind（异步缓存写入）#

又叫Write Back。在更新数据的时候，只更新缓存，不更新数据库，缓存服务会异步地批量更新数据库

消息队列中消息的异步写入磁盘、MySQL 的 Innodb Buffer Pool 机制都用到了这种策略。非常适合一些数据经常变化又对数据一致性要求没那么高的场景，比如浏览量、点赞量。

优势#

• 主要特性是I/O操作性能非常高
• 缓存刷新操作由cache服务端来完成，与客户端解耦

缺陷#

• 数据不是强一致性的，而且可能会丢失

总结#

• Cache-Aside。最常用的策略，由客户端读操作做cache刷新，写操作做cache删除
• Read/Write Through 与 Write Behind使用的一般较少。相同的是主要的刷新操作都由cache服务完成。
• Read Through与Cache-Aside的读操作流程相似，不同的是Read Through是由cache服务端完成，对客户端透明
• Write Through与Write Behind不同的是Write Behind只更新cache，不更新db，由cache服务异步批量更新db。而Write Through在没有读取到cache时会主动同步更新db

参考#

• 3种常用的缓存读写策略详解
• CacheAsidePattern和延时双删
• 缓存和数据库数据一致性问题
• 缓存更新的套路
• 一文读懂关于Redis的缓存更新策略
• redis缓存更新策略
• Redis缓存更新策略
• A beginner’s guide to Cache synchronization strategies
• Design Patterns: Cache-Aside Pattern
• Cache-Aside pattern
• The Cache Aside Pattern