这一篇来聊聊缓存一致性的问题，这里讨论的范围有限，仅仅是应用缓存与后端存储的一致性，当然也会适当做下延伸
1. Cache Aside，更通用的选择
问题
- 先更新 DB 还是 Cache
- 选择 Delete Cache 还是 Update Cache
如下 4 种组合，该如何决策？标准在哪里？一致性问题出在哪？
- update cache + update db
- update db + update cache
- delete cache + update db
- update db + delete cache
关键
从根本上讲，我们维护着两个数据源，两个数据源之间的一致性你得实时关照，这其实是一个分布式事务问题，既然是事务，就得老生常谈 ACID 了，持久性由 DB 和 Cache 存储机制保证，一致性作为原子性和隔离性的结果，我们主要要从这两个维度去衡量我们的方案是否可行
隔离性
多线程同时操作临界资源，需要保证符合调用时序，不能乱，否则就会相互干扰造成逻辑错误
保障方案
- 单一源操作有着天然时序保证，按照请求先后即可
- 多个源的请求时序需要做人为干预，比如说加锁
当隔离性不能保障我们看看会出现什么问题:
image
不难看出，DB 的操作时序性保证需要将 DB 操作放在第一步
而如果选择 update 而不是 delete 操作缓存，那缓存的操作也需要放在第一步，由此可见，为了保证逻辑自洽，update db + delete cache 是最佳选择
原子性
同时成功，同时失败
保障方案：
a. 尽量不要存在中间状态，调用失败需要同步反馈调用方重新发起调用
b. 做补偿删除，如更新数据库失败则删除已更新的缓存
原子性这一块，当我们不引入其他原子性保护机制的时候，不能保证强一致性，对于以上所有选型都是差不多的，不能起到决策作用
综上，update db + delete cache 是我们更加通用的选择，简单点叫 Cache Aside
2. Read/Write Through，高一级的抽象
作为数据源的调用方同时也是一致性的管理者，我们全知全能，上层使用者需要关心一致性的保障细节，同时有了代码耦合，编程模型被要求先 update db + delete cache，复杂度扩散在每一个使用 cache aside 策略的地方
其实缓存这个通用问题也可以有另外一种思路：抽象缓存组件，缓存一致性由缓存组件来保证，对调用者屏蔽掉缓存一致性的细节，调用者只需要跟缓存组件交互即可
主要流程
image
-
read hit: 直接返回
-
read miss: 加载数据库真实数据，填充缓存，返回客户端
-
write hit: 缓存，由缓存组件同步写到 DB
-
write miss: 写 DB 后返回
讨论
这种方式的缺点就是引入了缓存组件，依赖缓存组件的高性能，但是缓存组件还可以做很多事情，比如过期回调，逐出等。另外业界也有产品可以参考：腾讯云Redis 混合存储版
3. Write Back，追求性能，一致性次要
适用场景
- cache 与 main memory 速度差异很大，性能影响远远大于数据不一致的影响
- 数据不太重要
- 作为组合技中的一环，数据的完整性由其他机制保证
- 计算机架构里面的 page-cache
主要流程
image
- read hit: 直接返回
- read miss: 寻找缓存页，如果是脏页，先刷盘，再标记干净页，最后返回数据（对于没有 block 概念的 k-v 存储这一步可以省略掉）
- write: 写脏页需要刷盘再写，非脏页写后添加脏页后返回
关键
存储并非每次访问都写，而是引入脏页的概念，当缓存第一次被访问，只会做脏页标记，当缓存再次命中，需要做替换更新，才将老数据做刷新
借鉴
- cache 端可以借助速度优势多做一些计算，批量写入存储当中
- cache 中的数据朝生夕死，不需要实时写入存储
4. 延伸
Write Allocate
write miss 的同时，加载 back-store 中的数据到 cache，然后走 write hit 的流程。这种方式更契合 Write Back
No Write Allocate
write miss 的同时，直接写 back-store。这种方式更契合 Write Through
参考
https://en.wikipedia.org/wiki/Cache_(computing)
https://www.geeksforgeeks.org/write-through-and-write-back-in-cache/
网友评论