关于redis的延迟双删策略总结
redis延迟双删策略
1、什么是延迟双删?
延迟双删策略是分布式系统中数据库存储和缓存数据保持一致性的常用策略,但它不是强一致。其实不管哪种方案,都避免不了Redis存在脏数据的问题,只能减轻这个问题,要想彻底解决,得要用到同步锁和对应的业务逻辑层面解决。
2、为什么要进行延迟双删?
一般我们在更新数据库数据时,需要同步redis中缓存的数据
所以存在两种方法:
- 第一种方案:先执行update操作,再执行缓存清除。
- 第二种方案:先执行缓存清除,再执行update操作。
这两种方案的弊端是当存在并发请求时
很容易出现以下问题:
- 第一种方案:当请求1执行update操作后,还未来得及进行缓存清除,此时请求2查询到并使用了redis中的旧数据。
- 第二种方案:当请求1执行清除缓存后,还未进行update操作,此时请求2进行查询到了旧数据并写入了redis。
3、如何实现延迟双删?
所以此时我们需要使用第三种方案:先进行缓存清除,再执行update,最后(延迟N秒)再执行缓存清除。
4、需要注意的点
上述中(延迟N秒)的时间要大于一次写操作的时间,一般为3-5秒。
原因:如果延迟时间小于写入redis的时间,会导致请求1清除了缓存,但是请求2缓存还未写入的尴尬。。。
ps:一般写入的时间会远小于5秒
5、小结
延迟双删用比较简洁的方式实现 mysql 和 redis 数据最终一致性,但它不是强一致。
延迟,是因为 mysql 和 redis 主从节点数据同步不是实时的,所以需要等待一段时间,去增强它们的数据一致性。
延迟是指当前请求逻辑处理延时,而不是当前线程或进程睡眠延迟。
mysql 和 redis 数据一致性是一个复杂的课题,通常是多种策略同时使用,例如:延迟双删、redis 过期淘汰、通过路由策略串行处理同类型数据、分布式锁等等。
redis为什么要延时双删
首先,删除缓存是为了让其他事务读取数据的时候不会读到旧事务,而更新数据库前清除缓存和更新数据库后清除缓存解决的是不同时期的脏数据问题
只先删缓存的话,当我们在清除缓存和更新数据库间有事务查询缓存,此时没有缓存,数据库还没更新,所以缓存又更新为旧数据了
只后删缓存的话,在删除缓存之前读到的数据都是旧数据
那我们将两者综合起来的话,在更新前和更新后都进行删除,就可以很大程度上避免读到脏数据
那为什么要延时双删呢?我们考虑这样一种情况,在我们两次删除缓存之间更新数据库之前,B事务读到了数据库中的脏数据,但是他的时间片耗尽了,结果更新数据库的A事务进行了第二次清空缓存,时间片轮转回B时,B就会将旧数据缓存写进缓存当中去。此时我们使用延时双删策略,延后第二次删除缓存的时间,保证第二次删除缓存在所有的旧缓存之后,就可以确保不会有旧数据出现了
但是我们思考延时双删策略,此策略只能保证最终一致性,保证了第二次删除缓存之后的数据均为新数据,那第二次删除缓存之前还是能够读到旧数据的,如果对于数据没有强一致性要求的话延时双删已经足够了,但是如果对于数据有强一致性要求延时双删显然就不满足条件了,这个时候我们进一步优化的话可以考虑加锁操作,在写更新时阻塞读操作,带来的影响就是可以保证强一致性,但是吞吐量会下降
以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341