缓存与数据库的一致性：你们团队到底选了哪种姿势，又为什么？

背景

在数据工程和后端高并发领域，"缓存和数据库不一致"几乎是每个团队都撞过的墙。但每次聊起来，发现大家的做法差异非常大，而且往往跟业务场景、团队规模、运维能力强相关——没有银弹，只有取舍。我做了 10 年数据工程，见过从"纯 TTL 兜底"到"Canal + MQ + 幂等消费"一整套的方案，也见过方案很重但业务其实只需要"别让我看到超过 5 秒的脏数据"的情况。

常见分歧与几种做法

1. Cache-Aside + TTL 过期：写库后删缓存，靠 TTL 兜底。大多数团队的第一选择。但"删缓存"还是"更新缓存"的争论从来没停过——删缓存简单但有短暂空窗，更新缓存要处理并发写覆盖。
2. 延迟双删：写完库后延迟 N 毫秒再删一次缓存，防止"读请求先于写请求到达缓存"导致的脏数据。问题是 N 到底设多少？500ms？1s？有没有人根据 RT P99 动态算过？
3. Canal / binlog 订阅：监听 binlog 异步更新或删除缓存，解耦业务逻辑和缓存维护。但引入了额外组件（Canal Server、消费者），binlog 延迟本身又是个新变量，运维成本不低。
4. 事件驱动（MQ）：写库后发 Kafka / RocketMQ 消息，消费者负责更新缓存。好处是解耦，坏处是多了一跳、多了顺序性和幂等问题——我见过消费端重复消费导致缓存被旧值覆盖的事故。
5. 纯 TTL，不主动删：适合读多写少、数据时效性要求不高的场景（比如商品基础信息、配置项）。简单、少一个故障点，但脏数据窗口 = TTL 长度。

我的倾向与理由

我习惯从问题现象倒推根因。"缓存不一致"这个现象背后，根因往往不是缓存策略选错了，而是业务对"一致性"的定义从来没被认真问过。

我见过太多团队一上来就讨论"用 Canal 还是用 MQ"，但产品其实只要求"用户改完地址后，3 秒内别让他看到旧地址"。这种情况下，延迟双删（N=500ms）+ 合理 TTL 就够了，上 Canal 纯属过度设计。

所以我倾向于先定 SLA，再选策略：

• 能接受分钟级延迟 → TTL 就够了，别引入额外组件
• 需要秒级（1~3s）→ 延迟双删 + 合理的 N 值（建议取写库 RT 的 P99 × 2）
• 需要准实时且不能容忍脏读 → 事件驱动 + 幂等消费（用版本号或乐观锁防旧值覆盖）
• 真正强一致（金融、账务）→ 别用缓存，直接读库；如果 QPS 扛不住，用读写分离 + 主库读

想听大家

1. 你们团队在什么场景下用了哪种策略？踩过什么坑？
2. "延迟双删"的延迟时间你们怎么定的？有没有根据 RT 动态调整的经验？固定值还是 P99 × 系数？
3. Canal / binlog 方案的运维成本，你们觉得值不值？什么量级以上的 QPS 才值得上？
4. 有没有遇到过"缓存策略对了但还是不一致"的情况？根因是什么？（我猜大概率是并发写覆盖或者 binlog 延迟）
5. 你们怎么向产品/业务方解释"强一致"和"最终一致"的区别？他们能接受"3 秒延迟"吗？

欢迎贴你们的实际配置、参数、踩坑经历，越具体越好。