Redis 和数据库双写一致性问题如何解决？
Redis 和数据库双写一致性问题如何解决？
在高并发场景下，Redis 常被用作数据库的“前置缓存”以提升读取性能。但当数据需要更新时（写操作），如何保证 Redis 缓存与数据库中的数据最终一致（甚至强一致），就成了经典的“双写一致性”难题。
一、问题根源：先操作缓存还是先操作数据库？
很多同学会本能地想到“先更新数据库，再更新缓存”或“先删除缓存，再更新数据库”。但这两种方式都存在竞态条件风险：
| 操作顺序 | 可能的问题 |
|---|---|
| 先更新缓存，再更新数据库 | 缓存更新成功，数据库更新失败 → 数据不一致 |
| 先更新数据库，再更新缓存 | 更新数据库期间，有读请求将旧数据载入缓存 → 脏数据 |
| 先删除缓存，再更新数据库 | 删除缓存后、更新数据库前，有读请求将旧数据写回缓存 → 脏数据 |
| 先更新数据库，再删除缓存 | 相对安全，但删除缓存失败 → 缓存一直是旧数据 |
所以业界主流思路是“先更新数据库，再删除缓存”（Cache Aside Pattern）。而你提供的三种方案，正是围绕“如何可靠地删除/更新缓存”展开的。
二、方案详解（优化与完善）
方案一：先更新数据库，再删除缓存 + 重试 + 过期兜底
这是最简单、最直接的做法，核心流程如下：
优化点：
- 删除失败后的重试不能无限进行，建议设置最大重试次数（如3次）。
- 重试间隔可以采用指数退避（2秒、4秒、8秒），避免对 Redis 造成压力。
- 一定要给缓存设置合理的过期时间（如30分钟），作为最后的“兜底策略”，保证即使所有删除都失败，数据最终也会因过期而重新从 DB 加载。
优点：实现简单，无需引入额外组件。
缺点：重试过程可能短暂影响一致性；高并发下仍有极小概率读到旧数据（在删除缓存之前有读请求）。
方案二：先更新数据库，再发 MQ 消息，由消费者删除/更新缓存
将“删除缓存”这一操作从主线程剥离，通过消息队列（RabbitMQ、RocketMQ、Kafka 等）异步执行。流程如下：
优化点：
- 消息体建议携带：
cache_key、operation（delete/update）、timestamp、retry_count。 - 消费者需要保证幂等（多次删除同一 key 无害）。
- 如果业务需要“更新缓存”而非删除，需谨慎：更新缓存时可能拿到旧值，建议还是以删除为主，让读请求主动加载最新数据。
- 可以结合 RocketMQ 的事务消息，保证数据库更新和消息发送的原子性（避免数据库成功但消息未发）。
优点：解耦，删除失败不影响主流程；可通过 MQ 的重试机制保证最终一致。
缺点：引入 MQ 增加系统复杂度和延迟。
方案三：监听 MySQL Binlog，异步解析并修改缓存
这是一种“无入侵”的最终一致性方案，利用 Canal、Debezium 等组件伪装成 MySQL slave，解析 binlog 并推送到消息队列或直接更新缓存。
时序图（以 Canal 为例）：
优化点：
- binlog 是顺序的，可以保证消息的顺序性，避免并发更新导致的乱序问题。
- 建议只监听需要的表，减少无用解析。
- 如果更新操作频繁，可以批量处理（例如每100条 binlog 事件执行一次缓存更新）。
- 缓存更新策略：删除优于更新，因为更新需要知道新值，而新值从 binlog 中可以直接拿到（Canal 会输出变更后的整行数据），此时可直接执行 SET，但要考虑缓存与数据库数据格式转换问题。
优点：对业务代码零侵入；天然保证数据库变更一定会被处理；适合异构系统同步。
缺点：延迟相对较高（毫秒~秒级）；组件多，运维复杂。
三、其他补充方案（横向对比）
除了你提到的三种，实际工程中还有以下常见方案：
3.1 延迟双删（先删缓存，再更新 DB，再删一次）
# 伪代码redis.delete(key)db.update(data)time.sleep(0.1)# 等待可能存在的并发读请求将旧数据写回缓存redis.delete(key)适用场景：对一致性要求中等，且无法忍受“先更新 DB 再删缓存”导致的短暂不一致（读旧数据）。
注意：sleep 时间需根据业务读耗时估算（通常 100~200ms），过大会影响写性能。
3.2 分布式读写锁（强一致性）
使用 Redisson 等工具对 key 加读写锁：
- 读请求加读锁，写请求加写锁。
- 写锁会阻塞所有读锁，保证写期间无读操作，从而避免脏数据。
优点：强一致性。
缺点：性能差，吞吐量下降严重，一般不用于高并发缓存场景。
3.3 对比总结表
| 方案 | 一致性强度 | 性能影响 | 实现复杂度 | 是否需要额外组件 |
|---|---|---|---|---|
| 删除+重试+过期 | 最终一致（弱） | 低 | 低 | 无 |
| MQ异步删除 | 最终一致 | 中 | 中 | MQ |
| Binlog同步 | 最终一致（顺序保证） | 低（业务无感） | 高 | Canal+MQ |
| 延迟双删 | 最终一致（时间窗口更窄） | 低 | 低 | 无 |
| 读写锁 | 强一致 | 极高 | 中 | 分布式锁（如Redisson） |
四、选型建议
- 并发量低、一致性要求不苛刻：方案一（删除+重试+过期）足够，代码简单。
- 要求高可用，不能容忍缓存删除失败：方案二（MQ 异步删除），同时给缓存加过期时间作为兜底。
- 已有异构数据同步需求，或希望业务无感：方案三（binlog 监听），适合数据中台、CQRS 场景。
- 对短期不一致零容忍（如金融、库存扣减）：考虑分布式锁或直接读数据库，放弃缓存。
五、总结
Redis 与数据库的双写一致性问题没有“银弹”，需要在一致性、性能、复杂度之间做权衡。你提出的三种方案涵盖了从简单到复杂的演进路径：
- 同步删除 + 重试 + 过期兜底——入门级，大部分场景够用。
- MQ 异步删除——解耦 + 可靠，适合对删除成功率要求高的场景。
- Binlog 监听——终极解耦，适合大规模分布式系统。
最后记住一条核心原则：缓存只是加速，数据库才是真相。无论采用何种方案，务必为缓存设置合理的过期时间，给数据一致性留一条最后的退路。
📌附：常见问题
- Q：先更新数据库再删缓存，如果删除失败怎么办？
A：重试 + MQ + 过期兜底。- Q：为什么不先删缓存再更新数据库？
A：会导致并发读请求将旧数据写回缓存，产生脏数据。- Q：Canal 监听 binlog 会不会有重复消费？
A：会，需要消费者做幂等设计（如使用唯一事件 ID 或 version 字段）。