缓存的三种更新模式
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
