三分钟掌握数据库缓存双写一致性

更新数据库后如果保证缓存与数据库的一致性

数据库为修改，而缓存可以修改也可以删除，因此延伸出4种方案

 

1.先改库，再改缓存

场景如下：

1.A改库

2.B改库

3.B改缓存

4.A改缓存

得到的结果为 A的缓存，B的库，故存在不同步场景

 

2.先改缓存，再改库

场景如下：

1.A改缓存

2.B改缓存

3.B改库

4.A改库

得到的结果为 A的库，B的缓存，故存在不同步场景

 

3.先删缓存，再改库

场景如下：

1.A删缓存

2.B查缓存无值，故查数据库得到旧值

3.B将旧值设回缓存

4.A改库

得到的结果为 A的库，旧值缓存，故存在不同步场景

 

4.先改库，再删缓存

场景如下：

1.无缓存或缓存刚好过期

2.A查库得到旧值

3.B改库

4.B改缓存

5.A将旧值设回缓存

得到的结果为 B的库，旧值缓存，故存在不同步场景

但该场景出现的概率较低，因为需要在A查库结束到设缓存的时间内，B要完成改库+改缓存，而改库的时间一般会远大于设缓存的耗时。

 

如何同步

上面列的4种方案理论上都有概率出现不同步的场景，那要如何保证数据库与缓存的一致性呢？

答案是双删法。

在上述  3.先删缓存，再改库和与 4.先改库，再删缓存 的基础上，延伸出

5.先删缓存，再改库，延迟N秒后，再删缓存

6.先删缓存，再改库，延迟N秒后，再删缓存

 

N需根据业务时间及系统对不同步的容忍度设置

但如果延迟N秒后的删缓存失败，依旧会有小概率出现不同步场景。

如果系统对不同步场景的容忍度很低，那么此时就需要借助mq等中间件来保证该次删除一定成功了。