Redis 和 Mysql 数据库数据如何保持一致性
保持Redis和MySQL数据库数据一致性是一个常见且重要的问题,特别是在使用Redis作为MySQL数据库的缓存层时。以下是几种常用的保证二者数据一致性的策略和方法:
-
双写一致性(同步更新):
-
先更新MySQL,后更新Redis:
- 在业务代码中,首先执行对MySQL的写操作,待该操作成功后,立即更新Redis中的对应缓存数据。这种方式简单直接,但存在短暂窗口期内数据不一致的风险,即在MySQL更新后、Redis更新前,如果有请求读取缓存,可能会获取到旧数据。
-
先更新Redis,后更新MySQL:
- 反之,先更新Redis,然后更新MySQL。这种方式同样存在类似的风险,即在Redis更新后、MySQL更新前,如果有请求直接查询数据库(如缓存未命中或被主动刷新),可能会看到新缓存数据与旧数据库数据之间的不一致。
-
-
异步更新:
- 使用消息队列:
- 当MySQL数据更新时,将更新事件发送到消息队列(如RabbitMQ、Kafka等)。消费者服务监听队列,接收到消息后异步地更新Redis缓存。这种方法可以缓解同步更新时的性能压力,但增加了系统的复杂性,并且需要处理消息丢失、重复消费等问题以保证最终一致性。
- 使用消息队列:
-
基于MySQL Binlog的更新:
- 订阅Binlog:
- 利用工具(如Canal、Maxwell、Debezium等)订阅MySQL的二进制日志(Binlog),当MySQL数据发生变化时,这些工具能够实时捕获并解析Binlog事件,然后将更新信息推送到Redis,自动更新缓存。这种方法可以近乎实时地保持数据一致性,且对业务代码无侵入,但需要额外部署和维护Binlog订阅服务。
- 订阅Binlog:
-
使用版本号或时间戳:
- 在数据模型中引入版本号或时间戳字段,每次更新时同时更新MySQL和Redis中的相应字段。在读取数据时,可以通过比较版本号或时间戳来判断缓存是否过期,从而决定是否从数据库重新加载数据。这种方法有助于解决缓存与数据库数据版本冲突问题,但需要在业务逻辑中处理版本比较逻辑。
-
Redis事务:
- Redis本身支持事务(MULTI/EXEC命令),可以在一个事务中执行一系列操作,保证这些操作的原子性。对于涉及MySQL和Redis的更新操作,可以尝试将它们封装在Redis事务中执行,但需要注意的是,这并不能跨越Redis和MySQL两个不同的系统实现真正的分布式事务,只能保证Redis内部操作的原子性。
-
普通双删策略:
1、线程A先删除缓存,再更新数据库,再删除缓存
2、线程B查询缓存没有数据,在线程A更新数据库之前,查询到旧数据,此时系统时间片切换到线程A执行删除缓存,之后又轮到线程B放入缓存旧数据
3、线程C针对于线程A,查询缓存没有数据,查询到旧数据,放入缓存旧数据
都不能满足缓存和数据一致性。 -
延迟双删策略:
- 在更新MySQL后,立即删除Redis缓存,然后设置一个短时延(如几毫秒)后再次删除缓存。这样可以尽量减少在第一次删除缓存到MySQL更新生效期间,新数据被缓存的可能性。
1、线程A先删除缓存,之后更新数据库
2、线程B和线程C发现缓存没数据,查询数据库。线程B查询到的是旧数据,线程C查询到的是新数据。之后纷纷放入缓存
3、线程A延时3-5秒(时间一般要大于SQL执行时间+线程切换执行时间100ms足够),再将缓存删除。之后其他线程再查询缓存,发现没数据,再次查询数据库及放入缓存都是新数据
极端情况就是线程D,所以延时双删还是不一定能保证缓存及数据一致。
-
延迟双删策略:
1、在发现缓存没有数据后,在执行查询数据库前,对该Key进行加锁,查询数据库并放入缓存后再解锁,这样可以避免缓存击穿问题,当某个redis数据不存在时,大量线程并发查询数据库。
2、在需要执行双删前,对该Key进行加锁,之后执行删除缓存,更新数据库,放入新数据到缓存,在解锁。保证缓存和数据一致性。
3、加锁的Key都需要设置过期时间,避免因为宕机造成死锁。
综合考虑,选择哪种方法取决于具体的应用场景、数据一致性要求、系统复杂性接受程度以及运维成本等因素。实践中,常采用组合策略,如结合使用消息队列与Binlog订阅,或者在业务代码中直接同步更新的同时,辅以定期的数据校验与修复机制,以提高数据一致性的保障程度。