缓存一致性

《缓存更新的套路》 -陈皓
（不考虑二步失败，只考虑并发状况）

1. 先指出了”先删除缓存，再更新DB“策略在并发时存在的一致性问题

2. 说明cache aside缓存模式，其更新为“先更新DB，再让缓存失效”模式（让缓存失效也可以理解为删除缓存）
   这里让缓存失效而不是更新缓存，也是为了防止并发情况下出现一致性问题。
   但这种策略在下面这种并发情况下依然会有不一致问题：
   1. 缓存刚好过期，来了一个读请求，未命中缓存，从db中读取数据x=1
   2. 写请求到来，更新了db x=2
   3. 写请求接着让cache失效(其实此时cache已经没有此key了)
   4. 之前的读请求从db中读取数据后写到cache(x=1)
   但出现这种情况的概率很低，需要同时满足【读时缓存已失效】，然后并发来了一个写请求，并且写请求最终操作完db后，
   读请求才最终回写cache。而一般情况下写请求操作db的时间较长，等它写完db后，读请求早就结束了。

3. 说明read through、write through模式

4. 说明write back模式

《缓存和数据库一致性问题，看这篇就够了》 -Kaito

1. 最简单方案，写请求只写db，后台定时任务周期性把全量db数据刷入cache
2. 为提高缓存利用率，cache中只保留热点数据，因此：
   -写请求只写db
   -读请求先读cache，再读db，并把db数据回写cache，并设置过期时间
   为保证实时性，不再使用定时任务，在db的同时也要写cache：
   • 先更新cache，再更新db： 二步失败时，cache为新，db为旧，cache过期后的读请求会拿到旧数据
   • 先更新db，再更新cache：二步失败时，db为新，cache为旧，读请求会拿到旧数据
     这两种方案，并发问题可以采用分布式锁来解决。
     同时，每次更新数据时，都采用无脑更新缓存，浪费缓存资源，且缓存中存放的数据可能非原db数据，
     可能需要消耗cpu进行计算，如果更新频繁，明显消耗系统资源，因此改【更新缓存】为【删除缓存】。
3. 删除缓存对应的两种方案：
   • 先删cache，再更新db：二步失败时，db中数据未改动，下次读请求仍读db中旧数据并回写cache，数据是一致的【？】
   • 先更新db，再删除cache：二步失败时，db中为新数据，cache中为旧数据，出现不一致现象
     并发问题上，先【更新db再删cache】策略出现不一致的概率很低
4. 如何解决二步问题？
   失败时就重试，可以引入消息队列或者订阅db变更日志的方式来做。
5. 再【先删cache，再更新db】和【读写分离+主从复制延迟】情况下不一致问题解决的思路:
   本质上都是cache中保存了旧值，而db中存的时新值，这次采取【延迟双删】，注意
   -延迟时间大于主从复制延迟时间
   -延迟时间大于读取数据库+写入缓存时间
   但实际上都是凭经验估计，所以还是不要采用【延时双删】这个方案了。
   仍然用【先更新db，再删cache】方式，只要【主从复制】不要有太大延迟出问题的概率就不大。

参考链接：
缓存和数据库一致性问题，看这篇就够了
缓存更新的套路