Redis和MySQL如何保持数据一致性
比如:休眠1秒。
2.1.3、设置缓存过期时间是关键点
1、从理论上来说,给缓存设置过期时间,是保证最终一致性的解决方案
2、所有的写操作以数据库为准,只要到达缓存过期时间,缓存删除
3、如果后面还有读请求的话,就会从数据库中读取新值然后回填缓存
2.1.4、方案缺点
结合双删策略+缓存超时设置,这样最差的情况就是:
1、在缓存过期时间内发生数据存在不一致
2、同时又增加了写请求的耗时。
2.1.5、问题
为什么要双删呢!
因为第一次删除的是还没更新前的数据,第二次删除则是因为读取的并发性导致的缓存重新写入数据出现的垃圾数据。
如果你们的删缓存失败了,怎么办?那不是还是会出现缓存和数据库不一致的情况么?比如一个写数据请求,然后写入数据库了,删缓存失败了,这会就出现不一致的情况了。
这时候我们就需要一个中间件的无私配合了,那就是使用消息来进行重试机制。
步骤:
1、业务代码去更新数据库
2、数据库的操作进行记录日志。
3、订阅程序提取出所需要的数据以及key
4、获得该信息尝试删除缓存,发现删除失败的时候,发送消息到消息队列
5、继续重试删除缓存的操作,直到删除缓存成功。
其实这个方法与分布式事务的处理方式,就是保证数据的最终一致性,而在分布式事务中,则称之为这种为最大努力通知。那么最大努力通知又是什么样的流程呢?
1、业务方把通知发送给 MQ
2、接收通知方监听 MQ
3、接收通知方接收消息,业务处理完成回应ack
4、接收通知方若没有回应ack则MQ会重复通知,MQ 按照间隔时间从短到长的方式逐步拉大通知间隔,直到达到通知要求的时间上限,比如24小时之后不再进行通知。
5、接收通知方可通过消息校对接口来校对消息的一致性
总结:
而为什么叫最大努力通知呢,实际上也很容易理解,他并没有从本质上解决问题,只是把问题数目从100 变成了 10 ,毕竟有些内容第一次没处理,第二次就可能会被处理掉。也就是说降低了这种有问题情况的发生,毕竟保证的都是最终一致性。
2.2、异步更新缓存(基于Mysql binlog的同步机制)
2.2.1、整体思路
1、涉及到更新的数据操作,利用Mysql binlog 进行增量订阅消费
2、将消息发送到消息队列
3、通过消息队列消费将增量数据更新到Redis上
4、操作情况
读取Redis缓存:热数据都在Redis上
写Mysql:增删改都是在Mysql进行操作
更新Redis数据:Mysql的数据操作都记录到binlog,通过消息队列及时更新到Redis上
2.2.2、Redis更新过程
数据操作主要分为两种:
1、一种是全量(将所有数据一次性写入Redis)
2、一种是增量(实时更新)
这里说的是增量,指的是mysql的update、insert、delate变更数据。
读取binlog后分析 ,利用消息队列,推送更新各台的redis缓存数据。
1、这样一旦MySQL中产生了新的写入、更新、删除等操作,就可以把binlog相关的消息推送至Redis
2、Redis再根据binlog中的记录,对Redis进行更新
3、其实这种机制,很类似MySQL的主从备份机制,因为MySQL的主备也是通过binlog来实现的数据一致性
这里的消息推送工具你也可以采用别的第三方:kafka、rabbitMQ等来实现推送更新Redis!
3、总结
在高并发应用场景下,如果是对数据一致性要求高的情况下,要定位好导致数据和缓存不一致的原因。
解决高并发场景下数据一致性的方案有两种,分别是延时双删策略和异步更新缓存两种方案。
也可以采用别的第三方:kafka、rabbitMQ等来实现推送更新Redis!