电商大促期间，如何防止首页热点数据失效导致的“缓存击穿”？
在电商大促（如双11、618）期间，首页往往承载着全站最大的流量。如果首页的热点数据（如大促活动配置、爆款商品列表、轮播图等）在缓存中突然失效（过期或被淘汰），会导致瞬时海量并发请求直接打向数据库，这种现象被称为“缓存击穿”，极易导致数据库瞬间瘫痪。
针对电商大促的极端高并发场景，通常不能单纯依赖单一手段，而是需要组合拳来防止缓存击穿。以下是行业内成熟的解决方案：
一、 核心策略：缓存过期机制改造
首页热点数据的最大特点是“读多写少”且“允许短暂的最终一致性”。基于此，首选以下两种策略：
1. 逻辑过期（推荐，各大厂首页首选）
在缓存的 Value 中增加一个 expire_time（逻辑过期时间）字段，而 Redis 本身的物理过期时间设为永不过期（或设置一个极长的时间）。
- 工作流程：
- 业务线程查询缓存，发现数据已达到逻辑过期时间。
- 业务线程直接返回当前的旧数据给用户（保证首页绝对不卡顿）。
- 同时，业务线程尝试获取一个分布式互斥锁（如 Redis 的
SETNX）。 - 获取锁成功的线程，开启一个异步线程去查询数据库并更新缓存，更新完成后释放锁。
- 其他获取锁失败的线程，同样直接返回旧数据。
- 优点： 性能极高，并发情况下完全没有线程阻塞，用户体验丝滑。
- 缺点： 存在数据短暂不一致（大促首页的推荐、Banner晚几百毫秒更新完全可以接受）。
2. 热点数据“物理不过期” + 后台定时刷新
对于大促期间的核心首页数据（比如主会场导航、固定坑位商品），直接在 Redis 中取消设置过期时间（TTL = -1）。
- 工作流程： 数据更新不由前端用户的请求触发，而是由后台运营人员修改配置后，通过消息队列（MQ）或定时任务（Job）主动推送到 Redis 中（Cache Aside 的反向操作）。
- 适用场景： 强运营驱动的数据。
二、 兜底策略：并发控制
如果业务场景对数据实时性要求较高，不能使用“返回旧数据”的策略，则必须限制打向数据库的并发量。
1. 分布式互斥锁（Mutex Lock）
当缓存失效时，不让所有请求都去读数据库，而是加锁。
- 工作流程：
- 发现缓存未命中。
- 尝试获取分布式锁（
SETNX lock_key 1 EX 3）。 - 获取锁成功： 查数据库 -> 重建缓存 -> 释放锁 -> 返回数据。
- 获取锁失败： 线程休眠（如 50ms），然后重新自旋尝试查询缓存（此时大概率缓存已经被拿锁的线程建好了）。
- 优化点： 大促期间，为了防止自旋导致应用服务器 CPU 打满，通常配合“双重检查锁（Double Check Lock）”机制，并在多次重试失败后执行降级策略。
三、 架构升级：多级缓存体系
大促期间，网络带宽和 Redis 集群本身的 QPS 也可能成为瓶颈。仅仅依赖 Redis 挡不住首页数十万、数百万的并发。
1. 引入本地缓存（Local Cache）
构建 “Nginx/CDN 缓存 -> 应用本地缓存（Guava/Caffeine） -> 分布式缓存（Redis） -> 数据库” 的多级体系。
- 应用层本地缓存： 将首页最热的数据加载到 JVM 内存中。设置非常短的过期时间（例如 3~5 秒）。
- 防击穿效果： 即使 Redis 数据失效，打穿 Redis 的请求也会被应用服务器的本地缓存合并。假设有 100 台应用服务器，每秒 100万请求，打到 Redis 上的请求最多也就
100台 * 1次 = 100次，彻底消除了击穿风险。
2. 缓存预热（Pre-warming）
在大促流量洪峰到来前（如 11月10日 23:30），通过跑批任务，提前将首页所有可能用到的数据全部加载到 Redis 及本地缓存中，避免大促零点时缓存大面积冷启动。
四、 终极防御：限流、熔断与降级
哪怕做好了万全准备，也要假设缓存系统可能崩溃或发生击穿，此时必须保护数据库。
1. 接口限流
使用 Sentinel 或 Hystrix 等组件，对查询数据库的接口设置最大并发数限制（例如限制首页查询 DB 的 QPS 最大为 500）。超过部分直接抛出异常或走降级逻辑。
2. 静态数据兜底（降级方案）
在应用服务器本地提前存放一份静态的 JSON 数据（或者直接打包在代码里）。
当缓存击穿导致请求去查 DB 时，如果触发了限流，或者 DB 查询超时，直接返回本地静态 JSON 数据。
- 大促格言：“宁可给用户看旧内容，也绝不让页面报 502/空窗户，更不能让数据库挂掉。”
总结：大促首页防击穿最佳实践
针对大促首页热点数据，建议采用以下组合方案：
- 日常运营数据：采用 分布式锁 + 双重检查，兼顾一致性与安全性。
- 零点大促高优数据：采用 应用本地缓存（3秒TTL）+ Redis 逻辑过期（后台定时刷新），彻底切断前端流量直接打到数据库的路径。
- 安全底线：配置 Sentinel 数据库限流 + 本地静态 JSON 兜底，确保在任何灾难情况下首页都能展示。