电商大促需分层处理缓存矛盾：高时效字段用双写+分布式锁或Lua脚本原子更新；中低时效字段异步MQ同步；维度化拆key降低更新开销；多级缓存+热点识别+异步刷新保稳定；Redis故障时降级查DB、返回兜底值或CDN静态页。

电商商品详情页在大促期间面临每秒百万级请求，而价格、库存等关键数据又必须“秒级可见”，这就形成了缓存实时性与系统稳定性的根本矛盾。解决它不能靠单一策略，而是要分层处理、按数据特性区别对待。

区分数据时效等级，采用不同同步机制

商品数据不是铁板一块，得拆开看：

• 高时效字段（如库存、实时价格、销量）：必须“数据库写完 → 立即更新缓存”或“写完 → 立即删缓存”。推荐用“双写+分布式锁”保证原子性，避免并发写导致旧值回写；库存类操作直接用 Redis Lua 脚本做原子扣减，不走应用层逻辑。
• 中低时效字段（如标题、参数、图片列表、描述）：允许分钟级延迟。改用异步方式——数据库变更后发 MQ 消息，由独立的数据生产服务消费，批量拉取、校验、写入 Redis 和本地缓存，降低对主链路影响。

用维度化缓存替代全量缓存

别把整个商品详情塞进一个 key（比如 product:1001）。一旦颜色、规格、店铺信息任一维度更新，就得重刷整个大 JSON，既耗带宽又压 Redis。

• 按维度拆 key：product:1001:base（基础信息）、product:1001:specs（规格）、product:1001:stock（库存）、shop:2001:info（店铺）。
• 更新时只刷对应维度，互不影响；读取时再聚合，前端或网关层可做合并优化。

多级缓存 + 热点自动识别 + 异步保底刷新

光靠 Redis 不够扛压，得建缓冲带：

• 本地缓存（Caffeine）存 Top 1000 热点商品的基础字段，TTL 设为 5 分钟，命中率超 70% 就能大幅降低 Redis QPS。
• Redis 层对热点商品设永不过期，但配后台守护任务每 30 秒异步拉一次最新库存/价格，实现“最终一致”而非强一致。
• 冷启动或缓存穿透时，用布隆过滤器拦截非法 ID，并预热常用商品的 base + stock 维度，防雪崩。

兜底降级：缓存不可用时仍能返回可用数据

Redis 故障不能让页面白屏：

• 本地缓存失效后，降级走数据库直查，但加线程池隔离 + 熔断（如 Hystrix），避免拖垮 DB。
• 对库存等关键字段，可缓存一个“最近成功值 + 时间戳”，超时（如 2 分钟）未更新则返回带“数据可能滞后”提示的兜底值。
• Nginx 层配置 fallback 逻辑：当后端服务超时或报错，自动返回 CDN 上缓存的前一版静态结构页（含占位符），保障基本可浏览。