脚本宝典收集整理的这篇文章主要介绍了缓存一致性?get,脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。
大家好,我是老三,今天又是被算法致郁的一天,写篇文章缓一缓。
这篇文章,我们来看看缓存一致性问题。
我接下来会巴巴说一堆缓存一致性,但是——
作为一名暴躁老哥,我先把结论撂这了!
缓存和数据库的强一致性无法实现!
CAP理论了解一下,缓存适用的场景属于CAP中的AP,是非强一致性的场景。
那还扯个犊子的缓存一致性F1f;洗洗睡吧。
BASE理论接着了解一下,强一致性保证不了,那只好委屈求全,尽量保证最终一致性呗。
最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。
所以,我们追求的是尽可能保证缓存和数据库的最终一致性。
在开始之前,我们先来科普一下缓存+数据库读写,最经典的Cache Aside Pattern。
为什么是删除缓存,而不是更新缓存?
那么我们采用这种先更新数据库,再删除缓存,可能会出现什么问题呢?
假如,我们更新数据库成功,接下来还没来删除缓存,或者删除缓存失败怎么办?
那么很明显,这时候其它线程进来读的就是脏数据。
那怎么解决呢?
既然删除缓存失败会导致脏数据,那我们就想办法让它能删除成功呗。
我们可以引入一个重试机制。
如果删除缓存失败,向消息队列发送消息,把删除失败的key放进去,消费消息队列,获取要删除的key,然后去重试删除。
但是,这么干,好好的业务,咱们又引入了消息队列,对现有的业务造成了入侵,复杂度又提升了。
其实还有另外一种办法,我们可以用一个服务(比如阿里的 canal)去监听数据库的binlog,获取需要操作的数据。
然后用另外一个服务获取订阅程序传来的信息,进行缓存删除操作。
这样一来,对我们本身的业务入侵就小了很多。
我们看一下,如果先删除缓存,再更新数据库可能会带来什么问题。
在并发情况下,先删除缓存,再更新数据库,此时数据库还未更新成功,这时候有其它线程进来了,读取缓存,缓存不存在,读取数据库,读取的是旧值,这时候,缓存不一致就发生了。
就是在删除缓存,更新数据库之后,休眠一段时间后,再次删除缓存。
延时删除之后,就把缓存里缓存的旧值给删除了。
再有请求进来,就是读取数据库里的新值,再把新值保存进缓存。
当然,第二次删除也有失败的可能,怎么办呢?重试。那怎么重试呢?前面写了。
关于删除,还有一个兜底的方案——设置缓存过期时间
,这样一来,哪怕缓存了脏数据,但是脏数据总有过期的时候,不至于一直不一致。
我们来简单总结一下,首先对缓存的操作,删除优于更新,所以要删除,而不是更新。
删除缓存两种方式:
消息队列重试机制
和binlog异步删除
。延时双删
。当然,这些方案无疑都增加了系统的复杂度。
如果不是并发特别高的话,就没有必要过度设计。
简单的事情重复做,重复的事情认真做,认真的事情有创造性地做。
我是三分恶,一个努力学习中的程序员。
点赞
、关注
不迷路,咱们下期见!
参考:
[1]. 缓存与数据库一致性问题深度剖析
[2]. 数据库和缓存一致性的几种实现方式,我们来聊聊?
[3]. 面试官:缓存一致性问题怎么解决?
以上是脚本宝典为你收集整理的缓存一致性?get全部内容,希望文章能够帮你解决缓存一致性?get所遇到的问题。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。