面试官最爱问的Redis缓存三兄弟：雪崩、穿透、击穿，我用外卖订单场景给你讲明白
外卖系统高并发实战：Redis缓存三兄弟的解决方案
中午12点，某外卖平台的订单量突然激增，系统开始出现响应延迟。用户反复刷新页面却看到"网络开小差"的提示，而商家后台则不断弹出"订单查询失败"的报警。这熟悉的场景背后，往往隐藏着Redis缓存使用中的三大经典问题：雪崩、穿透和击穿。作为后端开发者，如果不能透彻理解这三种异常情况，就像厨师不知道火候控制一样危险。
1. 缓存雪崩：当所有活动同时失效
想象一下，外卖平台正在举行"全城五折日"，数万商家同时参与促销活动。技术团队为每个店铺的促销信息设置了缓存，并统一设置为2小时过期。当缓存集体失效的那一刻，数据库瞬间收到了超过平时50倍的查询请求——这就是典型的缓存雪崩。
雪崩问题的核心在于大量缓存同时失效导致请求直接穿透到数据库。在外卖系统中，这类问题常出现在：
- 店铺营业状态缓存（所有店铺状态同时更新）
- 全局促销活动缓存
- 区域运力配置缓存
解决方案对比表：
| 方案类型 | 具体实现 | 适用场景 | 优缺点 |
|---|---|---|---|
| 过期时间随机化 | 基础过期时间+随机偏移量（如300秒±随机60秒） | 批量缓存初始化场景 | 实现简单，但无法应对缓存全量崩溃 |
| 多级缓存 | LocalCache+Redis+DB三级回源 | 极端高并发场景 | 架构复杂，维护成本高 |
| 热点数据永不过期 | 异步线程定期更新缓存 | 极热点数据（如头部商家） | 可能产生脏读，需要版本控制 |
// Spring Boot中实现随机过期时间的配置示例 @Bean public RedisCacheManagerBuilderCustomizer redisCacheManagerBuilderCustomizer() { return (builder) -> builder .withCacheConfiguration("shopStatus", RedisCacheConfiguration.defaultCacheConfig() .entryTtl(Duration.ofSeconds(300 + new Random().nextInt(120)))); }在实际项目中，我们采用了组合方案：对普通店铺使用随机过期时间，对头部Top100商家采用多级缓存策略。某次大促期间，这种混合方案成功将数据库QPS从峰值2万+稳定控制在5000以下。
关键提示：雪崩防护的重点不是完全避免缓存失效，而是控制失效的节奏和影响范围。就像高峰期的地铁限流，需要错峰而不是阻断。
2. 缓存穿透：恶意请求的完美风暴
凌晨3点，监控系统突然报警显示数据库CPU使用率达到100%。排查发现，有大量请求在查询不存在的店铺ID："shop_999999"。这就是缓存穿透——查询根本不存在的数据，导致每次请求都直达数据库。
外卖系统中的典型穿透场景：
- 恶意爬虫遍历店铺ID
- 用户输入非法ID尝试获取数据
- 已下架商品被持续请求
防御方案四重奏：
入口校验：在Controller层对参数进行强校验
@GetMapping("/shops/{id}") public ResponseEntity<ShopInfo> getShopInfo(@PathVariable @Min(1) Long id) { // 业务逻辑 }布隆过滤器：使用RedisBloom模块预先存储所有合法ID
# 使用Redisson实现的布隆过滤器 RBloomFilter<Long> bloomFilter = redisson.getBloomFilter("shopIds"); bloomFilter.tryInit(1000000L, 0.03); if(!bloomFilter.contains(shopId)) { return Result.error("店铺不存在"); }空值缓存：对不存在的key也进行短时间缓存
SET shop:999999 "NULL" EX 60风控系统：识别异常请求模式并自动封禁
在某次安全审计中，我们发现一个脚本正在以每秒200次的频率扫描店铺ID。通过部署布隆过滤器+空值缓存组合方案，成功将这类无效请求的数据库穿透率降低到0.1%以下。
3. 缓存击穿：爆款菜品的秒杀危机
晚上6点，某网红餐厅的招牌菜品突然被1万用户同时点击，恰巧该菜品缓存刚刚过期。瞬间爆发的请求全部落到数据库，这就是缓存击穿——单个热点key失效引发的系统风暴。
外卖业务中的击穿高发区：
- 爆款菜品详情页
- 限时秒杀活动
- 头部商家主页
互斥锁实现方案对比：
| 实现方式 | 代码示例 | 适用场景 | 注意事项 |
|---|---|---|---|
| Redis SETNX | SET lock_key 1 EX 10 NX | 简单分布式场景 | 需处理锁续期问题 |
| Redisson锁 | RLock lock = redisson.getLock(); | 复杂分布式系统 | 支持可重入、看门狗机制 |
| 本地锁+Redis | synchronized+Redis | 混合架构 | 要注意本地锁的范围 |
public Shop getShopWithMutex(Long id) { String cacheKey = "shop:" + id; // 尝试从缓存获取 Shop shop = redisTemplate.opsForValue().get(cacheKey); if (shop != null) { return shop; } // 获取分布式锁 String lockKey = "lock:shop:" + id; try { boolean locked = redisTemplate.opsForValue() .setIfAbsent(lockKey, "1", 30, TimeUnit.SECONDS); if (locked) { // 二次检查缓存 shop = redisTemplate.opsForValue().get(cacheKey); if (shop != null) { return shop; } // 查询数据库 shop = shopMapper.selectById(id); redisTemplate.opsForValue().set(cacheKey, shop, 1, TimeUnit.HOURS); return shop; } else { // 未获取到锁，短暂休眠后重试 Thread.sleep(100); return getShopWithMutex(id); } } finally { redisTemplate.delete(lockKey); } }在实战中，我们发现单纯的互斥锁在高并发下会导致大量线程阻塞。最终方案是结合互斥锁与本地缓存，将数据库查询QPS从峰值8000+降至200左右。
4. 复合防御：外卖系统的缓存架构实践
真实的业务场景往往同时存在雪崩、穿透和击穿风险。某外卖平台日均订单量突破300万时，我们设计了多层次的防御体系：
缓存架构四层防护：
前端限流：滑动窗口算法控制API调用频率
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=100r/s;中间层过滤：
- 布隆过滤器拦截非法ID
- 空值缓存吸收无效请求
- 热点识别自动预热
缓存集群：
- 多AZ部署防止单点故障
- 差异化过期策略
- 熔断降级机制
数据库保护：
- 读写分离
- 连接池限流
- 慢查询优化
监控指标看板：
| 指标名称 | 预警阈值 | 监控频率 | 应对措施 |
|---|---|---|---|
| 缓存命中率 | <90% | 每分钟 | 检查热点key分布 |
| 数据库QPS | >5000 | 每秒 | 触发自动限流 |
| 慢查询比例 | >1% | 每5分钟 | SQL优化 |
| 缓存穿透率 | >5% | 实时 | 调整布隆过滤器 |
这套体系在去年双11期间经受住了考验，当时最高并发达到每秒3万订单，而数据库负载始终保持在安全水位。一个有趣的发现：约70%的缓存问题实际上源于不当的键设计，比如没有区分冷热数据。