缓存一致性要先讲业务容忍度

缓存一致性没有一种方案适合所有业务。商品详情、账户余额、权限配置、运营活动，它们对新鲜度和错误容忍度都不一样。方案选择之前，应该先问业务能不能接受短暂不一致。

先判断数据性质

如果数据只是展示类，短暂延迟通常可以接受，重点是缓存命中和更新及时性。如果数据影响支付、权限、库存这类关键动作，就不能只依赖缓存结果做最终判断。

缓存适合加速读取，不适合承担唯一事实来源。真正可靠的数据判断，仍然要回到数据库或具备强约束的业务服务。

常见做法是先更新数据库，再删除缓存。删除比更新缓存更稳一些，因为缓存内容可能来自复杂组装，直接更新容易漏字段或带入旧数据。

但删除缓存也不是结束。删除失败、并发读写、下游延迟都会带来不一致窗口。工程上需要配合重试、消息补偿、过期时间和监控告警，而不是只写一行删除代码。

缓存故障时，系统是直接报错，还是回源数据库，还是返回降级数据，要提前决定。如果所有流量瞬间回源数据库，可能把原本的缓存问题扩大成数据库压力问题。

所以缓存设计还要包括降级策略和保护策略。比如热点数据预热、空值保护、限流兜底，都属于缓存体系的一部分。

缓存一致性不是背方案，而是先理解业务对延迟、错误和成本的容忍度。技术方案只有放到具体业务里，才知道取舍是否合理。