Redis 与 MySQL 双删策略为何不能实现强一致性？

在高并发程序里读请求往往先走 Redis 以提高性能，但当数据库写入成功后缓存是否一定是最新值却没有确定答案。很多开发者把缓存当作数据库的副本，而不是第二个事实源。在遇到故障时需要回答：

• 旧值最多能存在多久？
• 删除失败如何补救？
• 哪些场景根本不能依赖缓存？

1️⃣ 竞态条件：最常被忽略的“写后读”问题

假设 Redis 中已存在 V1，写请求 B 将 MySQL 更新为 V2。

典型 Cache‑Aside 写法：

提交 MySQL 事务
删除 Redis key
下一次读请求从 MySQL 回源，再写入 Redis

问题出现在事务提交与缓存删除之间。若读请求 A 已经拿到了旧数据或从只读副本读取了 V1，它随后会把 V1 写回 Redis。从而导致最终状态：

MySQL = V2
Redis = V1

2️⃣ 延迟双删：解决不了所有竞态窗口

再看某些人会采用，

updateDatabase;deleteCache，sleep;deleteCache，

第二次删除可以覆盖一部分情况，但前提条件太多：

• 延迟要足够大：必须超过慢读、序列化与回填所需时间；P99 变化就会失效，
• 第二次删除可能失败：仅打日志并不会让缓存消失。
• 只读副本未跟上：即使 删除，也只是把错误窗口往后推。
• slee​p 占用业务线程：流量高时会拖慢线程池。

使用者痛点这方面，老数据被误读导致业务错误、线程被堵塞、程序恢复慢。

3️⃣ 更稳健的落地顺序建议

A. 数据库事务提交后再删缓存

不要在事务未提交时就删缓存。否则事务回滚后缓存已消失，造成抖动。保持写方法简洁：

提交 MySQL ➜ 删除 Redis ➜ 若失败进入持久重试

• #重试记录必须持久化：

B. 读请求识别“副本不新鲜”风险

• #短窗口内回主库读取

• #带最低版本号检测

C. 多入口写场景，用事件做收敛

• #消息重复控制

• #乱序保护

• #消费失败处理

• #延迟监控

使用者痛点汇总：

• - 缓存老值导致错误业务判断；老实说，- 删除操作频繁失败导致一致性漂移；- 延迟双删占用线程，吞吐下降；- 多入口更新漏掉失效导致多版本共存；- 缺乏监控难还有时发现问题。

面试答题思路

面试官问的观点是，“那到底多久删第二次？”我不会给出一个精确数字，而是先询问业务的 P99 读取时延、复制延迟还有允许的旧值窗口。接下来结合监控量化得到合适阈值，而不是随便抄粘博客里的经验。