为什么说延时双删很扯淡
Posted zhouj-happy
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了为什么说延时双删很扯淡相关的知识,希望对你有一定的参考价值。
redis和mysql数据一致性的问题
在这里,我们讨论三种更新策略:
- 先更新缓存,再更新数据库
- 先更新数据库,再更新缓存
- 先删除缓存,再更新数据库
- 先更新数据库,再删除缓存
第一种,先更新缓存,再更新数据库
问题:更新缓存成功,更新数据库失败,导致数据不一致。
第二种,先更新数据库,再更新缓存
问题:
1、A更新数据库
2、B更新数据库
3、B写入缓存
4、A写入缓存
出现数据不一致。
第二种,先删除缓存,再更新数据库。网络上的方案
延时双删
1、先删除缓存
2、更新数据库
3、等待一会再删除缓存
问题之一:延时双删,演变成了:先更新数据库,再删除缓存。。。。
比如:
1、A删除缓存
2、B查询数据库获取旧值
3、B更新了缓存
4、A更新数据库
5、A延时删缓存
1~3步执行后,数据库和缓存是一致的,成了开支执行前的状态,相当于没执行。
4~5步:先更新数据库,再删缓存。
所以延时双删演变成了:先更新数据库,再删除缓存。问题还是没解决。。。
为什么?假设,此时,在第4步执行之前,又来了个查询C,C查询到旧值。第6步:C将旧值插入缓存。此时出现缓存和数据库不一致。
延时并不能解决:C插入缓存的操作在第5步后面执行,比如C遇到网络问题、GC问题等。当然这是小概率,但并不代表不存在。
当然,延时越长,这个问题越能规避。如果业务需求不是非常严格,是可以忽略的。
第三种,先更新数据库,再删除缓存
问题:上面C的查询,已经说明问题了。
出现数据不一致的概率,比较小。采取这个方案,取决于业务需求。
终极方案
真正靠谱的方案:将访问操作串行化
- 先删缓存,将更新数据库的操作放进有序队列中
- 从缓存查不到的查询操作,都进入有序队列
会面临的问题:
- 读请求积压,大量超时,导致数据库的压力:限流、熔断
- 如何避免大量请求积压:将队列水平拆分,提高并行度。
- 保证相同请求路由正确。
以上是关于为什么说延时双删很扯淡的主要内容,如果未能解决你的问题,请参考以下文章