缓存一致性：延迟双删、订阅 binlog 与最终一致
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 2 · 缓存体系 · 第 13/49 篇 · 🚧 占位待学
上一篇：《缓存三兄弟：穿透、击穿、雪崩》
下一篇：《热点 key 与多级缓存：扛住明星结婚》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 2 · 单元 2.5
一、本文要解决的问题
数据改了，缓存什么时候改？「先删缓存还是先更新 DB」是一个经典辩论题——但重点不是背答案，而是能画出每种顺序在并发读写下 的不一致窗口，并理解为什么工业界最终都收敛到「最终一致 + 过期兜底」。
二、知识点清单
- 四种更新顺序分析：先删缓存后更 DB / 先更 DB 后删缓存 / 只更新缓存 / 只更新 DB，各自的不一致窗口
- 「先更 DB 再删缓存」仍不一致的场景：读线程 miss → 读旧 DB → 写线程删缓存 → 读线程回填旧值
- 延迟双删：删两次的时序与延迟时间的估算，治标程度
- canal 订阅 binlog 异步刷缓存：把缓存维护从业务代码剥离，最终一致的工程化
- 为什么放弃强一致：给缓存加事务的代价（性能 / 复杂度），过期时间作为最后兜底
三、动手实验（学习时必须真跑）
- 写一个「先更 DB 再删缓存」的接口，构造并发读写（写改值、读循环校验），统计不一致样本出现率
- 接入 canal（Docker 部署），订阅表变更自动删缓存，复跑实验对比不一致率
- 设置不同过期时间（1s / 60s / 1h），观察不一致窗口的自愈时间分布
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。