缓存与物化视图的失效策略：主动失效、TTL、懒刷新，到底该按什么锚点选？

背景

我做了 10 年大数据平台，最近半年在两个团队里反复撞见同一个"建完之后才暴露"的问题：物化视图、Redis 缓存、StarRocks 物化表都建好了，P99 从 3s 降到 30ms，看起来很完美；结果运营第二天来问"昨天 14:00 的 GMV 怎么比上一版少了 200 万"，开发查了一圈发现缓存是 10 分钟前刷新的，上游对账补数还没跑完。

这个坑的本质不是"缓存该不该建"（社区里已经有几篇讨论过现算/物化/实时流的取舍），而是缓存建好之后，"什么时候让旧值失效"这件事，大家往往是拍脑袋定的——有人选主动失效（binlog 触发删缓存）、有人选 TTL（固定 5min）、有人选懒刷新（读到脏值才重新算），三种策略都能跑，但出错时的形态完全不同。

常见分歧 / 三种做法的取舍

1. 主动失效（写后删）：一致性最好，但依赖上游变更通知的可靠性。binlog 消费延迟、消息丢失、跨库跨服务失效信号乱序，都会让"删了但还没重算"出现一个短暂窗口，读到空值或旧值。适合"值只增不减"的累计型指标（如累计 GMV），因为即使读到旧值，误差方向是确定的、偏小，业务可以接受。
2. TTL 定时过期：实现最简单，但过期时间是个"魔法数字"——设短了刷新压力大、设长了脏窗口长。适合"误差容忍度可以量化"的场景，比如运营看板"5 分钟内的偏差 < 0.5% 可接受"，那 TTL=5min 就是合理的。
3. 懒刷新（读时校验）：读路径上多一次"这值还新吗"的判断，写路径零成本。适合"读远多于写、且脏值不会导致决策错误"的场景，比如历史留存率（值只增不减，读到 10 分钟前的值，误差是单调偏小的）。

我的倾向与理由

我倾向于把决策锚点从"刷新频率"换成"误差容忍度 × 误差方向"这两个量，而不是凭直觉选 TTL。理由有三：

• 累计型指标（GMV、累计活跃）误差方向是确定的（偏小），业务方心里有数，懒刷新 + 短 TTL 就够；
• 存量型指标（库存、余额、在线人数）误差方向是不确定的（可能偏大也可能偏小），必须用主动失效，否则一个"看着合理"的脏值会直接导致超卖或错账；
• 比率型指标（转化率、留存率）误差方向取决于分子分母谁更新更快，最麻烦，往往需要"双写校验 + 异步对账"兜底，而不是单靠任何一种失效策略。

这个框架的好处是：它把"选哪种失效策略"从"凭经验"变成了"先量化业务能容忍多大的、什么方向的误差"，然后再倒推技术选型。

想听大家在什么场景下怎么选

特别想收集两类经验：

1. 你们团队是怎么**量化"误差容忍度"**的？是有明确的 SLO（如"看板数据延迟 ≤ 2 分钟，偏差 ≤ 0.5%"），还是靠业务方口头拍板？如果是后者，你们是怎么把"拍脑袋"变成"可度量"的？
2. 在"存量型指标"（库存、余额）场景下，主动失效的失效信号如果丢了，你们的兜底是什么？是定期全量对账，还是读写分离 + 写后校验？有没有踩过"删了缓存但重算又失败，结果读到空值"的坑？

欢迎带具体场景来聊，越具体越好。