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订阅服务。
使用版本号或时间戳：
- 在数据模型中引入版本号或时间戳字段，每次更新时同时更新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订阅，或者在业务代码中直接同步更新的同时，辅以定期的数据校验与修复机制，以提高数据一致性的保障程度。