Redis与MySQL双写一致性如何保证?
1、 3 4 5
前言
谈谈一致性
-
强一致性:这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但实现起来往往对系统的性能影响大 -
弱一致性:这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不承诺多久之后数据能够达到一致,但会尽可能地保证到某个时间级别(比如秒级别)后,数据能够达到一致状态 -
最终一致性:最终一致性是弱一致性的一个特例,系统会保证在一定时间内,能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型
三个经典的缓存模式
-
Cache-Aside Pattern -
Read-Through/Write-through -
Write-behind
Cache-Aside Pattern
Cache-Aside读流程
-
读的时候,先读缓存,缓存命中的话,直接返回数据 -
缓存没有命中的话,就去读数据库,从数据库取出数据,放入缓存后,同时返回响应。
Cache-Aside 写流程
Read-Through/Write-Through(读写穿透)
Read-Through
-
从缓存读取数据,读到直接返回 -
如果读取不到的话,从数据库加载,写入缓存后,再返回响应。
Write-Through
Write-behind (异步缓存写入)
操作缓存的时候,到底是删除缓存呢,还是更新缓存?
-
线程A先发起一个写操作,第一步先更新数据库 -
线程B再发起一个写操作,第二步更新了数据库 -
由于网络等原因,线程B先更新了缓存 -
线程A更新缓存。
-
如果你写入的缓存值,是经过复杂计算才得到的话。更新缓存频率高的话,就浪费性能啦。 -
在写数据库场景多,读数据场景少的情况下,数据很多时候还没被读取到,又被更新了,这也浪费了性能呢(实际上,写多的场景,用缓存也不是很划算的,哈哈)
双写的情况下,先操作数据库还是先操作缓存?
Cache-Aside
缓存模式中,有些小伙伴还是会有疑问,在写请求过来的时候,为什么是先操作数据库呢?为什么不先操作缓存呢?
-
线程A发起一个写操作,第一步del cache -
此时线程B发起一个读操作,cache miss -
线程B继续读DB,读出来一个老数据 -
然后线程B把老数据设置入cache -
线程A写入DB最新的数据
-
个别小伙伴可能会问,先操作数据库再操作缓存,不一样也会导致数据不一致嘛?它俩又不是原子性操作的。这个是会的,但是这种方式,一般因为删除缓存失败等原因,才会导致脏数据,这个概率就很低。小伙伴们可以画下操作流程图,自己先分析下哈。接下来我们再来分析这种删除缓存失败的情况,如何保证一致性。
数据库和缓存数据保持强一致,可以嘛?
-
加锁可以嘛?并发写期间加锁,任何读操作不写入缓存? -
缓存及数据库封装CAS乐观锁,更新缓存时通过lua脚本? -
分布式事务,3PC?TCC?
3种方案保证数据库与缓存的一致性
缓存延时双删
-
先删除缓存 -
再更新数据库 -
休眠一会(比如1秒),再次删除缓存。
删除缓存重试机制
-
写请求更新数据库 -
缓存因为某些原因,删除失败 -
把删除失败的key放到消息队列 -
消费消息队列的消息,获取要删除的key -
重试删除缓存操作
读取biglog异步删除缓存
-
可以使用阿里的canal将binlog日志采集发送到MQ队列里面然后通过ACK机制确认处理这条更新消息,删除缓存,保证数据缓存一致性
往期热门文章:
1、
2、
3、 4、
5、 6、 7 8、
9 10、