MySQL与Redis的缓存一致性问题及解决办法

原因

MySQL​​：强一致性、持久化存储，保证数据的准确性和可靠性。
​​Redis​​：高性能、低延迟的缓存，追求速度而非强一致性，数据可能丢失（如未持久化或主从切换时）。

​​本质问题​​：缓存（Redis）作为加速层，无法实时同步数据库（MySQL）的所有变更，导致两者数据可能存在短暂或长期的不一致。

解决方案

首先，我们要先确认业务系统要求的一致性级别是以下哪一种：

• 强一致性
• 最终一致性
• 短暂不一致

其次，记住我们的核心原则：

​​- 优先保证 MySQL 的强一致性​​（数据持久化正确）。
​​- 接受 Redis 的最终一致性​​，通过过期时间、异步同步兜底。
​​- 根据业务容忍度选择方案​​：如支付系统需强一致性，而商品详情页可最终一致性。

最终，我们根据业务场景权衡性能与一致性确立缓存方案。

方案 1：Cache Aside（旁路缓存）—— 短暂不一致、最常用​、必知必会

核心思路：通过删除缓存而非更新缓存，避免并发写导致的脏数据。

实现方式：

• 读流程​​：

  • 先读 Redis，命中则直接返回数据。
  • 未命中则读 MySQL，并将数据写入 Redis（注意：缓存要设置合理的过期时间，避免脏数据长期存在）。

• 写流程​​：

  • 先更新 MySQL​​（保证数据持久化正确）。
  • 再删除 Redis 中的对应 key​​（避免后续读请求读取旧数据）。

优点​​：

• 实现简单，逻辑清晰。
• 通过删除缓存而非更新缓存，避免并发写导致的脏数据（如线程 A 更新 MySQL 后更新缓存，线程 B 同时更新 MySQL 并覆盖缓存）。

缺点​​：

• 短暂不一致​​：删除 Redis 后、下次读取前的窗口期内，请求可能读到旧数据（通常可接受）。
• ​​删除失败风险​​：需结合重试机制（如消息队列补偿、定时job手动补偿）。

方案 2：异步同步（Binlog/消息队列）—— 最终一致性​​、 必知必会

​​核心思路​​：通过监听 MySQL 的变更（如 Binlog），异步将数据同步到 Redis，实现最终一致性。
​​实现方式​​：

• ​​Canal 方案​​：MySQL 开启 Binlog，Canal 模拟从库拉取 Binlog，解析后更新 Redis。
• ​​消息队列方案​​：业务代码更新 MySQL 后发送消息到 Kafka/RabbitMQ，消费者监听消息并更新 Redis。

Canal 是阿里巴巴开源的一款基于 MySQL Binlog 日志解析的分布式消息队列，能够实时捕获数据库的变更事件，并将这些事件发送到下游的消息队列（如 Kafka、RabbitMQ、RocketMQ 等），供其他服务消费。

​​优点​​：

• 解耦业务逻辑与缓存同步，系统扩展性强。
• 高性能（异步操作不影响主流程）。

​​缺点​​：

• ​​短暂不一致​​：同步延迟可能导致短时间缓存与数据库不一致。
• 复杂度高​​：需维护 Binlog 监听或消息队列的可靠性（如消息堆积、消费失败重试）。

​​适用场景​​：允许最终一致性的业务（如商品详情页、排行榜）。

方案 3：读写串行化（分布式锁）—— 强一致性场景​​、必知必会

​​核心思路​​：通过分布式锁（如 Redis 的 SETNX）保证同一时间只有一个线程能操作 MySQL 和 Redis。
​​实现流程​​：

1. 线程 A 获取锁，更新 MySQL。
2. 线程 A 更新 MySQL 后，删除 Redis 缓存。
3. 线程 A 释放锁，其他线程才能继续操作。

​​优点​​：彻底避免并发竞争，保证强一致性。
​​缺点​​：

• 性能急剧下降（锁竞争成为瓶颈）。
• 不适合高并发场景（如秒杀、高频更新）。

​​适用场景​​：对一致性要求极高且并发量可控的业务（如账户余额变更）。

方案 4：延迟双删—— 缓解并发竞争​​

​​核心原理​​：通过二次删除，减少读请求在 MySQL 更新期间将旧数据回写缓存的概率。
​​流程​​：

1. 先删除 Redis 缓存。
2. 更新 MySQL 数据。
3. 延迟几百毫秒（如 500ms）后再次删除 Redis 缓存。

​​缺点​​：

• 无法完全避免不一致（若延迟期间读请求频繁，仍可能写入旧数据）。
• 需精确控制延迟时间（过长影响性能，过短效果不佳）。

​​适用场景​​：对一致性要求稍高，但无法引入复杂架构的场景（如中小型电商库存）。

总结​​

MySQL 和 Redis 的数据一致性没有“银弹”，需根据业务场景权衡性能与一致性：

• 推荐方案：使用 Cache Aside + 删除失败重试​​：写流程中若 Redis 删除失败，将 key 写入消息队列（如 RocketMQ），消费者异步重试删除。
  写流程中若 Redis 删除失败，将 key 写入消息队列（如 RocketMQ），消费者异步重试删除。
• 追求性能​​：接受最终一致性，用 Cache Aside + 异步同步（Binlog/消息队列）。
• 追求强一致​​：牺牲性能，用分布式锁+同步更新（适合低并发关键业务）。
• 兜底措施：过期时间、监控告警、重试机制，降低不一致风险。