高并发下的缓存一致性设计：如何避免“看似快，实际错”
缓存最难的问题从来不是命中率，而是一致性。本文以电商库存与价格场景为例，讲清缓存更新策略、 失效边界和应急兜底机制。
1. 问题背景
系统引入缓存后，读性能提升明显，但出现“库存已售罄仍可下单”“价格更新后页面未同步”等问题。 高峰时段由于并发放大，错误数据会在秒级传播，引发业务事故。
2. 一致性目标分层
- 强一致：支付扣减、库存冻结等核心交易环节。
- 最终一致：商品详情、推荐列表等读多写少场景。
- 可容忍短暂不一致：统计类和报表类页面。
先划分一致性等级，再决定缓存策略，避免“全都强一致”导致系统复杂度失控。
3. 方案评估
3.1 Cache Aside
应用先更新数据库，再删除缓存。实现简单，但在高并发下可能出现“旧值回填”窗口。
3.2 Write Through
写请求先写缓存，再同步数据库。读路径稳定，但缓存层复杂且易形成写热点。
3.3 延迟双删
数据库更新后删除缓存，再延迟删除一次，降低旧值回填概率。对延迟参数和重试机制要求较高。
3.4 消息驱动失效
数据库事务提交后发事件，消费者异步失效缓存。可扩展性好，但要处理消息重复与乱序。
4. 最终落地架构
- 核心交易接口采用“数据库事务 + 消息驱动缓存失效”。
- 热点 Key 配置互斥重建，防止缓存击穿。
- 缓存值带逻辑过期时间，后台异步刷新，避免雪崩。
- 价格与库存使用不同 TTL 与更新通道。
5. 防故障策略
- 对关键查询增加版本号校验，发现旧值立即降级走数据库。
- 消息消费失败写入重试队列并设置死信告警。
- 夜间批量任务前提前预热，降低冷启动冲击。
- 核心缓存集群开启分片限流，避免热点拖垮全局。
6. 监控体系
仅看命中率远远不够。我们新增一致性指标：数据版本偏差率、缓存重建耗时、消息积压量、 关键 Key 更新延迟。并建立“业务投诉 → Key 追踪 → 事件回放”的排查流程。
7. 数据结果
- 库存错读问题月均 37 次 → 3 次
- 价格同步延迟 P95：2.8s → 0.7s
- 高峰期缓存穿透告警下降 61%
- 核心交易接口稳定性提升到 99.95%
8. 实施建议
切勿一次性替换全站缓存策略。建议先选择单一高价值链路试点，打通“更新、失效、监控、回滚”闭环， 再逐步推广。每一种缓存优化都需要配套回滚开关，这是线上安全底线。
9. 一页清单
- 一致性等级定义表
- 缓存更新策略决策树
- 关键告警阈值建议
- 故障应急处理 SOP