缓存一致性三选一：双删、延迟双删、MQ 失效，你们生产里到底在用什么

【背景】

最近帮一个业务团队看缓存问题，他们用的是最经典的「先更新 DB，再删 Redis」，但线上偶现脏数据——读到的还是旧值，窗口期大概几百毫秒到一两秒。我准备给他们换成「延迟双删」或者「DB 变更走 binlog/MQ 异步删缓存」，但动手前发现这话题在社区里说法分歧很大，想借这块地跟各位对一对。

打个比方：缓存像一面「慢半拍的镜子」，DB 是真实世界。你改了一件事，镜子要过一会儿才更新。问题不是「要不要镜子」，而是「镜子没跟上时，你愿不愿意让客人照它」。

【常见分歧 / 几种做法】

1. 更新缓存（Cache-Aside + set）：写 DB 后再 set 缓存。看似简单，但并发写容易把旧值覆盖到新值前面（经典竞态），而且 set 的 TTL 一长，脏窗口期就被放大。
2. 删除缓存（先删后写 / 先写后删）：先写后删是主流，但删和写之间有一个「读请求插进来把旧值塞回缓存」的窗口。
3. 延迟双删：写 DB → 删缓存 → sleep 200ms → 再删一次。简单粗暴，能盖住大部分插队读，但那个 200ms 是拍脑袋还是有依据？我见过有人改成 1s、有人改成 5s，没人说得清。
4. binlog/MQ 异步删缓存（Canal、Debezium、outbox）：解耦、可靠，但引入一个新组件，延迟从「毫秒级」变成「秒级」，对一致性要求极高的场景反而更糟；而且消费端挂了你都不知道。
5. TTL 兜底：所有方案最后都靠一个「不太长」的 TTL（比如 5 分钟）来收口，承认「最终一致」。

【我的倾向与理由】

我倾向于：默认走「写 DB → 删缓存 + 短 TTL 兜底」，对一致性敏感的核心字段（比如余额、库存）直接不走缓存，或者用版本号 CAS 更新。理由有三：

• 延迟双删的「第二次删」本质是赌那个插队读发生在第一次删之后、第二次删之前，这个赌局赢面高但不可控；
• binlog 异步方案组件多、链路长，故障域扩大，3 年经验告诉我「能少一个组件就少一个」；
• 真正出事故的，往往不是缓存脏了 200ms，而是业务方根本没意识到「这是最终一致」，把缓存当强一致用。

但我也知道这套说法在「高 QPS + 读远大于写」的场景下会被反驳——那种场景下 binlog 方案的吞吐和稳定性反而更优。

【想听大家聊聊】

• 你们生产里到底在用什么？延迟双删的 sleep 时长是怎么定的（拍脑袋 / 压测 / P99 读延迟）？
• 有没有踩过「binlog 消费端挂了，脏数据跑了一小时」这种坑？怎么发现的？
• 对于「余额 / 库存 / 状态机」这类强一致字段，你们是完全不走缓存，还是用版本号 CAS？
• TTL 到底设多长？你们有没有一个「TTL 与脏窗口期」的经验公式？

欢迎贴配置、贴事故、贴代码片段，越具体越好。