update 更新缓存 mysql_先更新数据库，还是缓存？

这一篇来聊聊缓存一致性的问题，这里讨论的范围有限，仅仅是应用缓存与后端存储的一致性，当然也会适当做下延伸

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

参考