缓存失效与并发写入交织时，如何避免旧值回填并保障业务一致性？

今天只问：更新库后删缓存，能彻底消除并发不一致吗？不能。只定边界：哪些必须正确，哪些可容忍陈旧。
客户只感知快和准。退款页面不许慢，金额和权限必须准。如果每次读都回源，体验崩了，业务不买。
工单里最气人的是：刚退款又显示待处理。客户不管理论，只看到状态倒退。异常时序必须在一线闭环。
公开案例和故障复盘显示，删除缓存后的旧值回填是高频事故，不是个案。多个团队在版本水位上线后压住了比例。
别把全站缓存都升级。一期只圈三个场景：退款金额、权限校验、工单状态。帮助文档保持删缓存加TTL。
候选A：双写加分布式锁，延迟高、锁失效难查。候选B：删缓存加版本水位加Outbox，再加TTL兜底。B更稳。
B最怕删除失败和重复消费。Outbox要本地事务写入，消费幂等；回填用Lua原子比较版本，否则旧值照样覆盖。
先量基线：现在过期读取比例多少、最大陈旧多久、回源失败率多少。没有基线，上线后说变好都是感觉。
帮助文档走搜索流量，允许秒级陈旧。但页面要标最后更新时间，schema同步，避免用户看到版本冲突。
这期不投广告。支付转化事件还没埋全，CAC算不准。预算先留零，等退款页稳定后再测，ROAS才有意义。
版本水位、Outbox、CDC都要钱。新增月成本上限一万二，超出砍非关键场景。三个月工单降三成才继续。
退款金额和权限不能信缓存，出事必须能审计。合同写清最终一致窗口不超过三秒，回源校验留日志。
第一轮结论：关键路径走版本水位加可靠失效，文档走TTL。下一步每人领一个交付物，不能停在观点。
我接受不全站回源。退款页允许三秒内最终一致，但按钮必须禁用重复提交，客户不能看到金额跳变。
三秒窗口可以，但工单状态不能倒退。版本水位必须让客服看到最新状态，异常时一键强制回源，否则投诉不会降。
同类系统里，版本水位能挡住旧值回填，但CDC延迟仍会造成短窗口。我的置信度七成，必须用TTL和回源兜底。
范围最终冻结：退款金额、权限校验、工单状态做版本水位；帮助文档只加短TTL。其他缓存不改造。
最终取舍：牺牲全站统一低延迟，换来关键路径正确性。方案B落地：Outbox加版本水位加TTL，半年内不引分布式事务。
实现路径：本地事务写Outbox，CDC重试幂等；回填前Lua查水位，旧版本拒绝并计数。删除失败进死信，人工补偿。
成功线：过期读取低于千分之一，最大陈旧三秒内。停止线：回源失败超百分之二，就降级回短TTL并告警。
文档页继续吃搜索流量，但加最后更新时间和版本号。验证指标：文档页跳出率不升，搜索点击率不掉。
本期不投，原因明确：退款页转化事件未埋全，CAC无法归因。等T+30埋点稳定，再用每日五百元测ROAS。
最终预算：新增月成本不超一万二，只批关键路径。ROI门槛：三个月工单下降三成。达不到，砍Outbox只留TTL。
合规门槛过了：退款和权限每次写审计日志，最终一致窗口写进SLA。谁绕过回源校验，谁承担事故责任。
执行清单：Bob出架构T+7；Alex写Outbox和Lua，T+14；David埋指标T+10；Emma验收范围，T+30全量验收。
拍板：上方案B。关键路径版本水位加可靠失效，文档短TTL；不做全站强一致。T+30看指标，过期读取超千分之一回退。