本文共 658 字,大约阅读时间需要 2 分钟。
更新数据库后如果保证缓存与数据库的一致性
数据库为修改,而缓存可以修改也可以删除,因此延伸出4种方案
场景如下:
1.A改库
2.B改库
3.B改缓存
4.A改缓存
得到的结果为 A的缓存,B的库,故存在不同步场景
场景如下:
1.A改缓存
2.B改缓存
3.B改库
4.A改库
得到的结果为 A的库,B的缓存,故存在不同步场景
场景如下:
1.A删缓存
2.B查缓存无值,故查数据库得到旧值
3.B将旧值设回缓存
4.A改库
得到的结果为 A的库,旧值缓存,故存在不同步场景
场景如下:
1.无缓存或缓存刚好过期
2.A查库得到旧值
3.B改库
4.B改缓存
5.A将旧值设回缓存
得到的结果为 B的库,旧值缓存,故存在不同步场景
但该场景出现的概率较低,因为需要在A查库结束到设缓存的时间内,B要完成改库+改缓存,而改库的时间一般会远大于设缓存的耗时。
上面列的4种方案理论上都有概率出现不同步的场景,那要如何保证数据库与缓存的一致性呢?
答案是双删法。
在上述 3.先删缓存,再改库和与 4.先改库,再删缓存 的基础上,延伸出
5.先删缓存,再改库,延迟N秒后,再删缓存
6.先删缓存,再改库,延迟N秒后,再删缓存
N需根据业务时间及系统对不同步的容忍度设置
但如果延迟N秒后的删缓存失败,依旧会有小概率出现不同步场景。
如果系统对不同步场景的容忍度很低,那么此时就需要借助mq等中间件来保证该次删除一定成功了。
转载地址:http://uriob.baihongyu.com/