背景
本文结合一些自己理解，讲解cache miss等情况下如何保证缓存和db的一致性，下面的例子中缓存以redis为例
读
先redis，redis没有就读db
写
有几种
1.先更新redis再更新db
2.先更新db再更新redis
3.先更新DB再删除redis
4.先删除redis再更新DB
5.延迟双删
6.延迟删除等变种
各种写场景与db redis一致性
1.先更新redis再更新db
按下面步骤会有问题,AB是两个线程
A_update_redis
B_update_redis
B_update_db
A_update_db
最终db是a值但是redis是b值，不一致
2.先更新db再更新redis
A_update_db
B_update_db
B_update_redis
A_update_redis
最终db是b值但是redis是a值
3.先更新DB再删除redis
A_update_db
B_update_db
B_rm_redis
A_rm_redis
是不是不明白。想不出来怎么不一致了？
不是这样的，没这么简单，第二次rm_redis就会保证后面的redis和db是一致的
实际是下面这种形式
A_get_data
redis_cache_miss
A_get_db
B_update_db
B_rm_redis
(此时如果拿db是b值，但是redis没有值)
A_update_redis
依赖于A_update_redis在B_update_db之后，极端情况
此时redis是old，db是new
4.先删除redis再更新DB
A_rm_redis
B_get_data
B_redis_miss
B_get_db
B_update_redis
A_update_db
此时redis是old值，db是new值
5.延迟双删
即
rm_redis
update_db
sleep xxx ms
rm_redis
这样叫做双删，最后一次sleep一段时间再rm_redis保证再次读请求回溯打到db，用最新值写redis
6.思考变种
上面的3和5情况可以直接变种，即
update_db
sleep xxx ms
rm_redis
解决了3中的极端情况（靠sleep解决），
并且减少5中第一次不必要的rm redis请求
当然，这个rm_redis还可以考虑异步化（提高吞吐）以及重试（避免异步处理失败），这里不展示
总结
从db回源到redis，需要考虑上面这些极端情况的case
适用场景
当然这些极端情况本身要求同一个key是多写的，这个根据业务需求来看是否需要，比如某些场景本身就是写少读多的
最终从网上看到的延迟双删变种为延迟删除redis也是一种优化
refer
https://my.oschina.net/LucasZhu/blog/1827267
https://blog.csdn.net/hjm4702192/article/details/80518922
https://shidonghua.work/2018/06/05/redis-DB-consistency/
