缓存与数据库的双写一致性 | Consistency between redis cache and sql database · doocs/advanced-java · Discussion #54

BigBlackSheep
Apr 3, 2019

诚如文章所说为避免数据不一致给出的思路是:先删除缓存,再更新数据库
那么如果现在有两个线程一个A更新一个B读取,当A线程在更新的时候先把缓存给删掉了然后去做更新数据库的时候,B线程来读取数据的时候发现缓存没有数据(被A给删掉了)然后去读取数据库把数据读取出来放到了缓存中,这个时候A线程再去做更新数据库的操作...那么好戏来了...数据库和缓存真的不一致了. 请问要如何解决呢?

Replies: 75 comments 32 replies

BigBlackSheep
Apr 9, 2019
Author

双写一致性校验应该可以

其实根据《Cache-Aside pattern》先更新数据库再删缓存就可以啦

1 reply

@SecondDragon

wbliubin
Apr 22, 2019

我怎么感觉先删除缓存,再更新数据库和先更新数据库再删除缓存是一样的都会有问题呢
假如是先更新数据库再删缓存,此时如果数据库还在更新中,一个线程进行了读取,不是也读取了脏数据了么

2 replies

@continuous1024

geekibli Feb 10, 2022

按道理来说,数据库已经开始执行更新了,不应该由于并发问题在把缓存设置成旧的值。
推荐一种策略是双删缓存: 删缓存修改数据库删缓存

BigBlackSheep
Apr 22, 2019
Author

更新前删缓存更新后删缓存这种应该会比较好一点~

4 replies

@SecondDragon

peter123456789 Mar 11, 2022

推荐一种策略是双删缓存: 删缓存修改数据库删缓存

这种也有比较大的问题,比如再高并发的情况下 :

1-delete cache

 ### 2-query DB

3-update DB

4-delete cache

 ### 5-set cache

134是一个线程
25是另一个线程

这种场景下不一致出现了,cache中还是旧的值,DB中是新的值。

@liao-can-jie

liao-can-jie Apr 15, 2023

所以双删策略,是不是应该更新完数据库后,删除缓存,然后为了避免删除失败,在通过MQ延迟删除兜底啊,这种才能保证最终一致性吧

有删除缓存失败的可能,就会有放入MQ失败的可能性,却增加系统的复杂度,考虑数据丢失问题

@Janche

Janche Mar 6, 2024

你没理解到延迟双删,第二次删除是发送MQ去做延迟删除,压根不会和 1 3 在同一个线程,保证了第二次删除一定是最后一步了

joyway66
May 22, 2019

先删除缓存,更新数据库,预计数据库更新需要时间t,然后在提交数据库更新t时间后再次删除缓存

1 reply

@Cloudymap1e

josephhao
May 22, 2019

不是读写分离数据库,悲观锁可以解决,但主从读写分离,就真不知怎么解决了,

...

先删除缓存,更新数据库,预计数据库更新需要时间t,然后在提交数据库更新t时间后再次删除缓存

0 replies

SJP-github
Sep 2, 2019

所以作者说先删缓存,再更新数据,然后用内存队列保证串行化,等数据库更新完再去读库就没有这么多幺蛾子了。还有同学提到的用读写锁。读写锁底层用的AQS其实也是用内存队列做的,保证顺序

1 reply

@zhutaoos

MissHuZeQuan
Dec 17, 2019

个人觉得缓存双删比较简单靠谱,而且编码不是那么复杂

1 reply

@xbzhang1994

xbzhang1994 May 7, 2021

是的,如果系统允许短时间内的数据不一致,这种方案肯定是好的,而且是简单的。但是如何要求有请求存在时redis和数据库的数据必须一致,那就只能把请求串行化了。

nethibernate
Jan 7, 2020

作者写的其实比较清楚了。

不管先删除缓存,还是先更新数据库,都会出现数据不一致问题,因为这本身就不是一个原子操作。只是作者提到,如果不在高并发的情况下,这种现象出现的可能性极低(但不代表不存在)。

其实原子操作相对于非原子操作来说,本来就是一个极其耗性能的东西,因为原子操作需要的是排他的串行操作,根据阿姆达尔定律就可以证明。

3 replies

@tianxianglan

tianxianglan Jan 13, 2021

这不是原不原子操作关系不大吧,要解决的是删除缓存到更新完数据库这个时间段内其他请求又请求缓存接口导致回源的是老数据的问题吧

@fqdeng

fqdeng Jan 24, 2021

这不是原不原子操作关系不大吧,要解决的是删除缓存到更新完数据库这个时间段内其他请求又请求缓存接口导致回源的是老数据的问题吧

他文章里面忽略了一个问题, 高并发的情况下,用队列你怎么保证你版本1的更新消息一定会在版本2的更新消息之前进入队列?不还是得加悲观锁? 数据库拿到行锁然后把更新丢进队列,如果数据库不拿到行锁就去投递消息进队列队列的顺序肯定没法保证, 这个问题我之前做消息队列高并发 demo时候早就研究过,双写要保证完全一致性一定要竞争单条数据的全局锁,否则没法保证原子性。

而且双写一致性大部分时候都是一个伪命题,没有什么业务需要这么强一致性的缓存的读,而更新的话直接用数据库的行锁就能保证触发一次当前读。

@fqdeng

fqdeng Jan 24, 2021

这不是原不原子操作关系不大吧,要解决的是删除缓存到更新完数据库这个时间段内其他请求又请求缓存接口导致回源的是老数据的问题吧

而且他文章里面的队列还要去维护更新,例如后续的更新来了,要自动忽略掉前面的老版本,这个操作本身也是很费时间的。

另外还要涉及到消息路由的问题, 你是让集群里面的所有的JVM虚拟机都接受所有的读请求 ,还是要做hash分片,对部分读请求只会hash路由到特定的JVM,如果是前者,那么你需要更新数个JVM的队列,数据行的写操作的性能会急剧下降,如果是后者,你特定的JVM挂逼了,那么你服务就会缺失一大块的响应,因为特定的请求只会路由到特定的JVM实例上。

geekhoon
Jan 14, 2020

高并发下保证绝对的一致,就需要用到内存队列做异步串行化。非高并发场景,双删策略基本满足了。如果特别要求强一致性,并不适合放在redis

0 replies

BigBlackSheep
Jan 15, 2020
Author

看到各位回答很多人说:内存队列做串行化.可是这样就降低了效率.这里提供一个新思路就是.先更新数据库再删除缓存.之后使用MQ延迟队列(可以延迟个50-100毫秒)去做异步再删除.

3 replies

@tianxianglan

整个业务流程是串行的,如果删除缓存失败,就进行后续加入MQ延迟队列的步骤?
是否可以这样做: 删除缓存失败原因(缓存宕机,网络抖动,项目停止)
1、前两种通过补偿策略,加入到MQ延迟队列,或者回滚数据。
2、项目停止(优雅停止时长少于业务时间),这种不可控因素,有个补偿策略(rabbitMQ),但代价很大。
a、在第一次删除时,异步MQ(CompletableFuture里创建一临时队列,ttl 可以根据优雅停止时长)。
b、第二次删除时,根据返回的临时队列异步消费,若项目停止则加入死信队列,延迟消费。

geekhoon
Jan 15, 2020

看到各位回答很多人说:内存队列做串行化.可是这样就降低了效率.这里提供一个新思路就是.先更新数据库再删除缓存.之后使用MQ延迟队列(可以延迟个50-100毫秒)去做异步再删除.

首先我认为肯定要先删缓存,再更新数据库,这二者的顺序是不能换的,否则更新完成,缓存未删除,查到的数据那势必不一致。
使用MQ异步删除,并不能保证一致性
内存队列做串行化是考虑具体场景的,并不适用所有情况。有强一致性要求的才考虑这种做法。否则双删即可

0 replies

BigBlackSheep
Jan 15, 2020
Author

看到各位回答很多人说:内存队列做串行化.可是这样就降低了效率.这里提供一个新思路就是.先更新数据库再删除缓存.之后使用MQ延迟队列(可以延迟个50-100毫秒)去做异步再删除.

首先我认为肯定要先删缓存,再更新数据库,这二者的顺序是不能换的,否则更新完成,缓存未删除,查到的数据那势必不一致。
使用MQ异步删除,并不能保证一致性
内存队列做串行化是考虑具体场景的,并不适用所有情况。有强一致性要求的才考虑这种做法。否则双删即可

对这个是我说错了要先删缓存,再更新数据库,这二者的顺序是不能换的.使用MQ做异步删除为什么能保证一致性呢可以展开说一下嘛.

0 replies

geekhoon
Jan 15, 2020

看到各位回答很多人说:内存队列做串行化.可是这样就降低了效率.这里提供一个新思路就是.先更新数据库再删除缓存.之后使用MQ延迟队列(可以延迟个50-100毫秒)去做异步再删除.

首先我认为肯定要先删缓存,再更新数据库,这二者的顺序是不能换的,否则更新完成,缓存未删除,查到的数据那势必不一致。
使用MQ异步删除,并不能保证一致性
内存队列做串行化是考虑具体场景的,并不适用所有情况。有强一致性要求的才考虑这种做法。否则双删即可

对这个是我说错了要先删缓存,再更新数据库,这二者的顺序是不能换的.使用MQ做异步删除为什么能保证一致性呢可以展开说一下嘛.

比如说你先删缓存,现在去修改数据库,修改的过程中有查询操作去查了数据库,又把旧数据添加到了缓存,你现在数据库更新完了,用mq去延迟删除缓存,那这个延迟期间,所有的查询查的还是旧数据

0 replies

MissHuZeQuan
Jan 15, 2020

保证了最终一致性,你要是要求强一致性,那在考虑别的方法

...

------------------------------------------------------------------ 发件人:geekhoon <notifications@github.com> 发送时间:2020年1月15日(星期三) 16:44 收件人:doocs/advanced-java <advanced-java@noreply.github.com> 抄送:MissHuZeQuan <huzequan1109@dingtalk.com>; Comment <comment@noreply.github.com> 主题:Re: [doocs/advanced-java] 缓存与数据库的双写一致性 | Consistency between redis cache and sql database (#54) 看到各位回答很多人说:内存队列做串行化.可是这样就降低了效率.这里提供一个新思路就是.先更新数据库再删除缓存.之后使用MQ延迟队列(可以延迟个50-100毫秒)去做异步再删除. 首先我认为肯定要先删缓存,再更新数据库,这二者的顺序是不能换的,否则更新完成,缓存未删除,查到的数据那势必不一致。使用MQ异步删除,并不能保证一致性内存队列做串行化是考虑具体场景的,并不适用所有情况。有强一致性要求的才考虑这种做法。否则双删即可对这个是我说错了要先删缓存,再更新数据库,这二者的顺序是不能换的.使用MQ做异步删除为什么能保证一致性呢可以展开说一下嘛. 比如说你先删缓存,现在去修改数据库,修改的过程中有查询操作去查了数据库,又把旧数据添加到了缓存,你现在数据库更新完了,用mq去延迟删除缓存,那这个延迟期间,所有的查询查的还是旧数据 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

0 replies

更新DB
插入redisB
删除redisA
另起一个线程将新数据插入到redisA+删除redisB

读线程2的操作:

读redisA,若有值,直接返回(这里可能读取的是旧的值,因为redisA还没有被删除)
如果没有,则说明有更新,新的值在redisB,直接去reidsB读

对比延迟双删:

更新DB
删除redis
延迟删除redis

以空间换时间,减少了数据不一致的时间,另外,读线程不会读取到数据库的旧值,然后更新到redis,不知道这种想法,大家觉得咋样,多多批评指正

0 replies

Uh oh!

缓存与数据库的双写一致性 | Consistency between redis cache and sql database #54

Uh oh!

Replies: 75 comments · 32 replies

Uh oh!

Uh oh!

BigBlackSheep Apr 9, 2019 Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

BigBlackSheep Apr 22, 2019 Author

Uh oh!

Uh oh!

Uh oh!

1-delete cache

3-update DB

4-delete cache

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

BigBlackSheep Jan 15, 2020 Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Replies: 75 comments 32 replies

BigBlackSheep
Apr 9, 2019
Author

BigBlackSheep
Apr 22, 2019
Author

BigBlackSheep
Jan 15, 2020
Author