4、双写一致性（数据库与缓存）的调试：先删缓存后更新DB vs 先更新DB后删缓存的陷阱
双写一致性是缓存与数据库协同工作时最核心的挑战。当数据发生写操作时，缓存与数据库之间的状态可能出现短暂甚至永久的不一致。本章聚焦于两种主流更新策略——先删缓存后更新DB 与 先更新DB后删缓存，通过调试视角剖析其背后的陷阱与应对方案。
4.1 两种策略的核心流程对比
| 策略 | 执行顺序 | 核心风险 | 典型不一致场景 |
|---|---|---|---|
| 先删缓存后更新DB | ① 删除缓存 → ② 更新数据库 | 读请求在写请求未完成时回填旧数据 | 写操作删除缓存后，并发读请求查询DB旧值并回填缓存，导致缓存长期为脏数据 |
| 先更新DB后删缓存 | ① 更新数据库 → ② 删除缓存 | 缓存删除失败导致缓存与DB永久不一致 | DB更新成功但缓存删除因网络/超时失败，后续读请求持续命中旧缓存 |
调试核心结论：两种策略都无法在无额外补偿机制下保证强一致性。先删缓存后更新DB的陷阱在于“并发读回填”，先更新DB后删缓存的陷阱在于“删除操作可靠性”。
4.2 陷阱一：先删缓存后更新DB —— 并发读回填
该策略的致命缺陷发生在写操作删除缓存后、数据库更新完成前的窗口期。此时若有并发读请求进入，会因缓存未命中而查询数据库，但数据库中的值仍是旧值，读请求将旧值回填到缓存。后续所有读请求都将命中这个脏缓存，直到下一次写操作再次删除它。
调试观察点：在日志中关注“缓存删除时间戳”与“数据库更新时间戳”之间的读请求回填操作。如果发现回填时间戳落在两个写操作时间戳之间，即可确认并发回填发生。
4.3 陷阱二：先更新DB后删缓存 —— 删除失败
该策略将数据库更新放在前面，理论上更安全，因为即使缓存删除失败，下一次读请求仍有机会通过缓存失效机制或过期时间纠正。但问题在于：如果缓存删除操作因网络抖动、Redis超时或服务重启而失败，且没有重试机制，缓存将永久保留旧值，所有读请求都会命中脏数据。
调试关键指标：监控缓存删除操作的失败率。如果删除失败率超过0.1%，必须引入异步重试或删除日志补偿机制。在调试日志中，重点搜索“Cache delete failed”或“Cache delete timeout”关键字。
4.4 调试工具与补偿策略
针对上述两种陷阱，调试阶段需要建立以下检测与补偿机制：
- 延迟双删（先删缓存 → 更新DB → 延迟再删缓存）： 适用于先删缓存后更新DB策略。在更新DB后，延迟几百毫秒再次删除缓存，以清除并发读回填的脏数据。
- 异步删除补偿（消息队列 + 重试）： 适用于先更新DB后删缓存策略。将删除缓存操作写入消息队列，由消费者异步执行，失败时自动重试。
- 缓存过期时间兜底： 无论采用哪种策略，都应为缓存设置合理的过期时间（如5分钟），作为最终一致性兜底。
- Binlog监听补偿： 通过监听数据库binlog变更，异步同步到缓存，作为双写策略的补充一致性保障。
调试清单：
- 在写操作前后打印缓存key的当前值、数据库当前值。
- 记录每次缓存删除操作的耗时与结果（成功/失败/超时）。
- 对并发读请求增加时间戳标记，追踪其回填的value来源。
- 使用分布式链路追踪（如Jaeger）串联写请求与并发读请求的时间线。
4.5 策略选择建议
| 业务场景 | 推荐策略 | 理由 |
|---|---|---|
| 读多写少，对短暂不一致容忍度低 | 先更新DB后删缓存 + 异步重试 | DB更新成功后，缓存最终会被删除，配合重试机制可保证最终一致性 |
| 写频繁，对缓存命中率敏感 | 先删缓存后更新DB + 延迟双删 | 减少缓存中脏数据的存活时间，延迟双删可覆盖并发回填场景 |
| 强一致性要求（如金融交易） | 分布式锁 + 缓存双删 | 写操作加锁，确保读写互斥，配合双删策略达到近乎强一致 |
调试双写一致性问题的核心在于：识别并发窗口 与 确保删除操作的可靠性。通过日志、链路追踪和补偿机制，可以将不一致的概率降到可接受范围。