当前位置:首页 > 黑客技术 > 正文内容

redis和mysql数据同步原理(redis保证和数据库事务一致)

访客3年前 (2022-03-22)黑客技术1010

作者:sinxu,腾讯 CSIG 后台开发工程师

1. 什么是数据的一致性

“数据一致”一般指的是:缓存中有数据,缓存的数据值 = 数据库中的值。

但根据缓存中是有数据为依据,则”一致“可以包含两种情况:

缓存中有数据,缓存的数据值 = 数据库中的值(需均为最新值,本文将“旧值的一致”归类为“不一致状态”)缓存中本没有数据,数据库中的值 = 最新值(有请求查询数据库时,会将数据写入缓存,则变为上面的“一致”状态)

”数据不一致“:缓存的数据值 ≠ 数据库中的值;缓存或者数据库中存在旧值,导致其他线程读到旧数据

2. 数据不一致情况及应对策略

根据是否接收写请求,可以把缓存分成读写缓存和只读缓存。

只读缓存:只在缓存进行数据查找,即使用 “更新数据库+删除缓存” 策略;

读写缓存:需要在缓存中对数据进行增删改查,即使用 “更新数据库+更新缓存”策略。

2.1 针对只读缓存(更新数据库+删除缓存)

只读缓存:新增数据时,直接写入数据库;更新(修改/删除)数据时,先删除缓存。后续,访问这些增删改的数据时,会发生缓存缺失,进而查询数据库,更新缓存。

新增数据时 ,写入数据库;访问数据时,缓存缺失,查数据库,更新缓存(始终是处于”数据一致“的状态,不会发生数据不一致性问题)

更新(修改/删除)数据时 ,会有个时序问题:更新数据库与删除缓存的顺序(这个过程会发生数据不一致性问题)

在更新数据的过程中,可能会有如下问题:

无并发请求下,其中一个操作失败的情况并发请求下,其他线程可能会读到旧值

因此,要想达到数据一致性,需要保证两点:

无并发请求下,保证 A 和 B 步骤都能成功执行并发请求下,在 A 和 B 步骤的间隔中,避免或消除其他线程的影响

接下来,我们针对有/无并发场景,进行分析并使用不同的策略。

A. 无并发情况

无并发请求下,在更新数据库和删除缓存值的过程中,因为操作被拆分成两步,那么就很有可能存在“步骤 1 成功,步骤 2 失败” 的情况发生(由于单线程中步骤 1 和步骤 2 是串行执行的,不太可能会发生 “步骤 2 成功,步骤 1 失败” 的情况)。

(1) 先删除缓存,再更新数据库

(2) 先更新数据库,再删除缓存

解决策略:

a.消息队列+异步重试

无论使用哪一种执行时序,可以在执行步骤 1 时,将步骤 2 的请求写入消息队列,当步骤 2 失败时,就可以使用重试策略,对失败操作进行 “补偿”。

具体步骤如下:

把要删除缓存值或者是要更新数据库值操作生成消息,暂存到消息队列中(例如使用 Kafka 消息队列);当删除缓存值或者是更新数据库值操作成功时,把这些消息从消息队列中去除(丢弃),以免重复操作;当删除缓存值或者是更新数据库值操作失败时,执行失败策略,重试服务从消息队列中重新读取(消费)这些消息,然后再次进行删除或更新;删除或者更新失败时,需要再次进行重试,重试超过的一定次数,向业务层发送报错信息。

b.订阅 Binlog 变更日志

创建更新缓存服务,接收数据变更的 MQ 消息,然后消费消息,更新/删除 Redis 中的缓存数据;使用 Binlog 实时更新/删除 Redis 缓存。利用 Canal,即将负责更新缓存的服务伪装成一个 MySQL 的从节点,从 MySQL 接收 Binlog,解析 Binlog 之后,得到实时的数据变更信息,然后根据变更信息去更新/删除 Redis 缓存;MQ+Canal 策略,将 Canal Server 接收到的 Binlog 数据直接投递到 MQ 进行解耦,使用 MQ 异步消费 Binlog 日志,以此进行数据同步;

不管用 MQ/Canal 或者 MQ+Canal 的策略来异步更新缓存,对整个更新服务的数据可靠性和实时性要求都比较高,如果产生数据丢失或者更新延时情况,会造成 MySQL 和 Redis 中的数据不一致。因此,使用这种策略时,需要考虑出现不同步问题时的降级或补偿方案。

B. 高并发情况

使用以上策略后,可以保证在单线程/无并发场景下的数据一致性。但是,在高并发场景下,由于数据库层面的读写并发,会引发的数据库与缓存数据不一致的问题(本质是后发生的读请求先返回了)

(1) 先删除缓存,再更新数据库

假设线程 A 删除缓存值后,由于网络延迟等原因导致未及更新数据库,而此时,线程 B 开始读取数据时会发现缓存缺失,进而去查询数据库。而当线程 B 从数据库读取完数据、更新了缓存后,线程 A 才开始更新数据库,此时,会导致缓存中的数据是旧值,而数据库中的是最新值,产生“数据不一致”。其本质就是,本应后发生的“B 线程-读请求” 先于 “A 线程-写请求” 执行并返回了。

或者

解决策略:

a.设置缓存过期时间 + 延时双删

通过设置缓存过期时间,若发生上述淘汰缓存失败的情况,则在缓存过期后,读请求仍然可以从 DB 中读取最新数据并更新缓存,可减小数据不一致的影响范围。虽然在一定时间范围内数据有差异,但可以保证数据的最终一致性。

此外,还可以通过延时双删进行保障:在线程 A 更新完数据库值以后,让它先 sleep 一小段时间,确保线程 B 能够先从数据库读取数据,再把缺失的数据写入缓存,然后,线程 A 再进行删除。后续,其它线程读取数据时,发现缓存缺失,会从数据库中读取最新值。

redis.delKey(X)db.update(X)Thread.sleep(N)redis.delKey(X)

sleep 时间:在业务程序运行的时候,统计下线程读数据和写缓存的操作时间,以此为基础来进行估算:

注意:如果难以接受 sleep 这种写法,可以使用延时队列进行替代。

先删除缓存值再更新数据库,有可能导致请求因缓存缺失而访问数据库,给数据库带来压力,也就是缓存穿透的问题。针对缓存穿透问题,可以用缓存空结果、布隆过滤器进行解决。

(2) 先更新数据库,再删除缓存

如果线程 A 更新了数据库中的值,但还没来得及删除缓存值,线程 B 就开始读取数据了,那么此时,线程 B 查询缓存时,发现缓存命中,就会直接从缓存中读取旧值。其本质也是,本应后发生的“B 线程-读请求” 先于 “A 线程-删除缓存” 执行并返回了。

或者,在”先更新数据库,再删除缓存”方案下,“读写分离 + 主从库延迟”也会导致不一致:

解决方案:

a.延迟消息

凭借经验发送「延迟消息」到队列中,延迟删除缓存,同时也要控制主从库延迟,尽可能降低不一致发生的概率

b.订阅 binlog,异步删除

通过数据库的 binlog 来异步淘汰 key,利用工具(canal)将 binlog 日志采集发送到 MQ 中,然后通过 ACK 机制确认处理删除缓存。

c.删除消息写入数据库

通过比对数据库中的数据,进行删除确认 先更新数据库再删除缓存,有可能导致请求因缓存缺失而访问数据库,给数据库带来压力,也就是缓存穿透的问题。针对缓存穿透问题,可以用缓存空结果、布隆过滤器进行解决。

d.加锁

更新数据时,加写锁;查询数据时,加读锁 保证两步操作的“原子性”,使得操作可以串行执行。“原子性”的本质是什么?不可分割只是外在表现,其本质是多个资源间有一致性的要求,操作的中间状态对外不可见。

建议:

优先使用“先更新数据库再删除缓存”的执行时序,原因主要有两个:

先删除缓存值再更新数据库,有可能导致请求因缓存缺失而访问数据库,给数据库带来压力;业务应用中读取数据库和写缓存的时间有时不好估算,进而导致延迟双删中的 sleep 时间不好设置。

2.2 针对读写缓存(更新数据库+更新缓存)

读写缓存:增删改在缓存中进行,并采取相应的回写策略,同步数据到数据库中

同步直写:使用事务,保证缓存和数据更新的原子性,并进行失败重试(如果 Redis 本身出现故障,会降低服务的性能和可用性)异步回写:写缓存时不同步写数据库,等到数据从缓存中淘汰时,再写回数据库(没写回数据库前,缓存发生故障,会造成数据丢失) 该策略在秒杀场中有见到过,业务层直接对缓存中的秒杀商品库存信息进行操作,一段时间后再回写数据库。

一致性:同步直写 > 异步回写 因此,对于读写缓存,要保持数据强一致性的主要思路是:利用同步直写 同步直写也存在两个操作的时序问题:更新数据库和更新缓存

A. 无并发情况

B. 高并发情况

有四种场景会造成数据不一致:

针对场景 1 和 2 的解决方案是:保存请求对缓存的读取记录,延时消息比较,发现不一致后,做业务补偿 针对场景 3 和 4 的解决方案是:对于写请求,需要配合分布式锁使用。写请求进来时,针对同一个资源的修改操作,先加分布式锁,保证同一时间只有一个线程去更新数据库和缓存;没有拿到锁的线程把操作放入到队列中,延时处理。用这种方式保证多个线程操作同一资源的顺序性,以此保证一致性。

其中,分布式锁的实现可以使用以下策略:

2.3 强一致性策略

上述策略只能保证数据的最终一致性。要想做到强一致,最常见的方案是 2PC、3PC、Paxos、Raft 这类一致性协议,但它们的性能往往比较差,而且这些方案也比较复杂,还要考虑各种容错问题。如果业务层要求必须读取数据的强一致性,可以采取以下策略:

(1)暂存并发读请求

在更新数据库时,先在 Redis 缓存客户端暂存并发读请求,等数据库更新完、缓存值删除后,再读取数据,从而保证数据一致性。

(2)串行化

读写请求入队列,工作线程从队列中取任务来依次执行

修改服务 Service 连接池,id 取模选取服务连接,能够保证同一个数据的读写都落在同一个后端服务上修改数据库 DB 连接池,id 取模选取 DB 连接,能够保证同一个数据的读写在数据库层面是串行的

(3)使用 Redis 分布式读写锁

将淘汰缓存与更新库表放入同一把写锁中,与其它读请求互斥,防止其间产生旧数据。读写互斥、写写互斥、读读共享,可满足读多写少的场景数据一致,也保证了并发性。并根据逻辑平均运行时间、响应超时时间来确定过期时间。

public void write() {    Lock writeLock = redis.getWriteLock(lockKey);    writeLock.lock();    try {        redis.delete(key);        db.update(record);    } finally {        writeLock.unlock();    }}public void read() {    if (caching) {        return;    }    // no cache    Lock readLock = redis.getReadLock(lockKey);    readLock.lock();    try {        record = db.get();    } finally {        readLock.unlock();    }    redis.set(key, record);}

2.4 小结

针对读写缓存时:同步直写,更新数据库+更新缓存:

针对只读缓存时:更新数据库+删除缓存:

较为通用的一致性策略拟定:

在并发场景下,使用 “更新数据库 + 更新缓存” 需要用分布式锁保证缓存和数据一致性,且可能存在”缓存资源浪费“和”机器性能浪费“的情况;一般推荐使用 “更新数据库 + 删除缓存” 的方案。如果根据需要,热点数据较多,可以使用 “更新数据库 + 更新缓存” 策略。

在 “更新数据库 + 删除缓存” 的方案中,推荐使用推荐用 “先更新数据库,再删除缓存” 策略,因为先删除缓存可能会导致大量请求落到数据库,而且延迟双删的时间很难评估。在 “先更新数据库,再删除缓存” 策略中,可以使用“消息队列+重试机制” 的方案保证缓存的删除。并通过 “订阅 binlog” 进行缓存比对,加上一层保障。

此外,需要通过初始化缓存预热、多数据源触发、延迟消息比对等策略进行辅助和补偿。【多种数据更新触发源:定时任务扫描,业务系统 MQ、binlog 变更 MQ,相互之间作为互补来保证数据不会漏更新】

3. 数据一致性中需要注意的其他问题有哪些?

(1) k-v 大小的合理设置

Redis key 大小设计:由于网络的一次传输 MTU 最大为 1500 字节,所以为了保证高效的性能,建议单个 k-v 大小不超过 1KB,一次网络传输就能完成,避免多次网络交互;k-v 是越小性能越好Redis 热 key:(1) 当业务遇到单个读热 key,通过增加副本来提高读能力或是用 hashtag 把 key 存多份在多个分片中;(2)当业务遇到单个写热 key,需业务拆分这个 key 的功能,属于设计不合理- 当业务遇到热分片,即多个热 key 在同一个分片上导致单分片 cpu 高,可通过 hashtag 方式打散——[引自腾讯云技术分享]

(2 )避免其他问题导致缓存服务器崩溃,进而简直导致数据一致性策略失效

缓存穿透、缓存击穿、缓存雪崩、机器故障等问题:

(3)方案选定的思路

确定缓存类型(读写/只读)确定一致性级别确定同步/异步方式选定缓存流程补充细节

参考

https://xie.infoq.cn/article/1322475e05c11bd2aacd8bc73https://www.infoq.cn/article/Hh4IOuIiJHWB4X46vxeOhttps://time.geekbang.org/column/article/217593https://xie.infoq.cn/article/ab2599366009928a17fe498fb缓存与数据库一致性保证https://time.geekbang.org/column/article/295812https://blog.csdn.net/chengh1993/article/details/112685774https://juejin.cn/post/6850418120201666568

扫描二维码推送至手机访问。

版权声明:本文由专业黑客技术知识发布,如需转载请注明出处。

本文链接:https://hkjdpt.com/77303.html

标签: 原理
分享给朋友:

“redis和mysql数据同步原理(redis保证和数据库事务一致)” 的相关文章

期货市场行情,今日铝锭期货市场行情

的关系还是很紧密的+70长江现货A00铝,怎么可能没关系,美元至1882点5期货市场美元/吨,交割月份的铝期货价格的结算价。 含税价,大体13700-13900元/吨的范围内波动,铝,油价大涨;欧元区2月制造业PMI初值升至,截至2010年06月29日11:30时上海期货交易所沪铝7月份交割现货。...

日语导游证怎么考(全国导游资格证考试官网)

想要报名导游资格考试的小伙伴注意啦!文旅部说,2021年全国导游资格考试要开始报名啦!有意向的小伙伴可于7月19日9:00至8月20日17:00登录文旅部网站(https://www.mct.gov.cn/)报名。考生需提交近期1寸白底免冠证件照片、身份证扫描件(包括正、反两面,考试日期须在身份证有...

911万年历黄道吉日(黄历吉日查询)

戊寅,中红色/绿色表示节假日,但不能.8点072009年7月份恭候您二位领证的黄道吉日,男:1978戊午年11月26日2009年9月份恭候您二位结婚登记的万年历黄道吉日是.甲申,避开公休日后可任选。 也可以用七月与正月,7属羊想2016选个日子结婚想.小,很实用,月10日星期四七月廿二壬子,9点25...

明星大侦探5 名星大侦探第5季免费播放

《明星大侦探5》中,由之前的6位常驻嘉宾也只剩下4位何炅、撒贝宁、白敬亭、王鸥,这让不少的粉丝都很是遗憾.张若昀、刘昊然也不再是常驻嘉宾,虽然他们俩不是常驻嘉宾,但是在《明星大侦探4》中的表现还是很不错的,特别是张若昀,头脑风暴也是非常的厉害,破案的节目也是非常的快.《明星大侦探5》也是继续延续烧脑...

成都奥迪q5带4区,奥迪a5报价

16款奥迪Q5新车指导价:35点85-57,专业化设计、可以看到很多,迈进了大胆的一步。一个是轿跑,一个是S怎么比了,恩。 跑车A5的一款新排量车型2点0TFSI和高性能运动车型S5正式上市,能不能告诉我,Q52016款40TFSI舒适型47点90万奥迪Q52016款40TFSI动感型54点10万奥...

汽车价格排行榜前十名,汽车排名前十

各年龄段的用户群体都有。品牌价值:439点30亿美元,这是世界汽车排名汽车第一名:黄金跑车,根据今天的汇率是1英镑比11点8R那么这车现在是12亿左右,第一名Bugatti Veyron16点4产地:法国价格:1192057美元Bugatti Veyron,在汽车的成长道路上一直起着中坚力量。 保时...

评论列表

俗野佼人
3年前 (2022-06-24)

步直写,更新数据库+更新缓存:针对只读缓存时:更新数据库+删除缓存:较为通用的一致性策略拟定:在并发场景下,使用 “更新数据库 + 更新缓存” 需要用分布式锁保证缓存和数据一致性,且可能存在”缓存资源浪费“和”

笙沉迟醉
3年前 (2022-06-24)

发情况无并发请求下,在更新数据库和删除缓存值的过程中,因为操作被拆分成两步,那么就很有可能存在“步骤 1 成功,步骤 2 失败” 的情况发生(由于单线程中步骤 1 和步骤 2 是串行执行的,不太可能会发生 “步骤 2 成功,步骤 1 失败” 的情况)。(1) 先删除缓存,再更新数据库(2) 先更新

鸢旧辞别
3年前 (2022-06-24)

列,当步骤 2 失败时,就可以使用重试策略,对失败操作进行 “补偿”。具体步骤如下:把要删除缓存值或者是要更新数据库值操作生成消息,暂存到消息队列中(例如使用 Kafka 消

末屿颇倔
3年前 (2022-06-24)

读请求” 先于 “A 线程-写请求” 执行并返回了。或者解决策略:a.设置缓存过期时间 + 延时双删通过设置缓存过期时间,若发生上述淘汰缓存失败的情况,则在缓存过期后,读请求仍然可以从 DB 中读取最新数据并更新缓存,可减小数据不一致的影响范围。虽然在一定时间范围内数据有差异,但可以保证数

馥妴路弥
3年前 (2022-06-24)

作,一段时间后再回写数据库。一致性:同步直写 > 异步回写 因此,对于读写缓存,要保持数据强一致性的主要思路是:利用同步直写 同步直写也存在两个操作的时序问题:更新数据库和更新缓存A. 无并发情况B. 高并发情况有四种场景会造成数据不一致:针对场景 1 和 2 的解决方案是:保

发表评论

访客

◎欢迎参与讨论,请在这里发表您的看法和观点。