很多缓存事故，第一眼都像“Redis 出问题了”。
接口慢了，数据库连接数上去了，应用线程池开始堆积，报警一条接一条。大家往往先查 Redis：是不是宕机、网络抖动、内存满了？
这次故障复盘后发现，Redis 本身没有异常。真正的问题是一个热点 key 在高峰期过期，缓存没挡住流量，请求瞬间打到数据库。更麻烦的是，系统没有及时限流，也没有成熟降级方案，一个局部问题被放大成了接口超时。
一、故障现象：接口突然变慢
出问题的是首页推荐接口。
这个接口会读取热门商品和活动配置，平时访问量较高。核心数据放在 Redis，缓存命中后响应基本在几十毫秒。
故障发生在业务高峰期。监控先提示接口 P95 响应时间升高，从几十毫秒涨到 2 秒以上。随后应用日志出现大量超时，数据库连接池接近打满，慢 SQL 数量增加。
当时几个现象很明显：
Redis 状态正常，没有重启、内存淘汰或连接异常。
数据库 CPU 升高，连接数明显增加。
应用线程池队列堆积，请求等待变长。
慢 SQL 集中在同一张业务表。
这些信号说明，问题不像 Redis 整体不可用，更像某类请求绕过缓存集中打到了数据库。
二、根因：热点 key 被击穿
继续查日志后，发现大量请求都在查询同一个缓存 key。
这个 key 对应首页热门商品列表，过期时间设置为 30 分钟。正常情况下命中率很高，数据库压力很小。
问题出在过期瞬间。
当这个热点 key 失效时，刚好有大量用户请求进来。应用逻辑是先查 Redis，未命中就查数据库，再回写缓存。由于没有互斥控制，几十个请求同时发现缓存不存在，于是一起去查数据库。
数据库原本只需要承接一次回源查询，结果被迫承接一批并发查询。查询本身不算慢，但并发上来后，连接池被占用，其他接口也受到影响。
这就是典型缓存击穿。
缓存击穿和缓存雪崩不同。雪崩是大量 key 同时失效，影响面更广；击穿是某个热点 key 失效，流量集中打穿一个点。
三、短板一：没有互斥回源
防缓存击穿，最直接的办法是让回源查询变成“单线程”或“少量线程”。
缓存失效后，不应该所有请求都去查数据库，而是一个请求拿到锁去加载数据，其他请求短暂等待后再读缓存。
伪代码类似这样：
bash
代码解读
复制代码
String value = redis.get(cacheKey);
if (value != null) {
return value;
}
boolean locked = redis.setIfAbsent(lockKey, "1", 10);
if (locked) {
try {
Object data = queryDatabase();
redis.set(cacheKey, data, expireSeconds);
return data;
} finally {
redis.del(lockKey);
}
}
Thread.sleep(50);
return redis.get(cacheKey);
这里要注意几件事：
锁要有过期时间，避免服务异常后无法刷新缓存。
等待时间不能太长，否则请求线程会堆积。
拿不到锁的请求不能直接查库，否则锁没有意义。
这次故障里，系统没有互斥回源。缓存失效后，每个请求都去数据库加载数据，最后把数据库推到高水位。
四、短板二：限流没有保护回源路径
系统其实有接口限流，但规则主要在网关层，针对整体 QPS。
问题是，这次总流量没超过网关阈值。真正异常的是缓存未命中后的数据库回源流量。
这说明限流不能只看入口。
对于依赖缓存保护数据库的接口，至少要关注三类限流：
接口级限流，防止整体请求量过高。
资源级限流，限制同时访问数据库的请求数。
热点 key 限流，控制单个 key 的回源并发。
这次更需要资源级限流。比如数据库回源最多允许 5 个并发，其余请求返回旧缓存、默认数据或稍后重试提示。
限流的目标不是简单拒绝请求，而是保护核心资源。数据库、消息队列、第三方接口、搜索服务，都应该被纳入保护范围。
五、短板三：降级方案不清晰
故障处理中，大家临时讨论过是否可以返回默认推荐列表，但没有现成开关，也没人能马上确认业务是否接受。
这就是降级方案缺失的问题。
很多系统只考虑“正常返回”，很少认真考虑“依赖异常时返回什么”。等故障来了再讨论，会浪费处理时间。
对首页推荐这类接口，可以准备几种降级方式：
返回上一版缓存数据。
返回静态配置的默认列表。
减少返回字段，只保留核心内容。
关闭个性化逻辑，改成通用推荐。
尤其是热点缓存，适合做逻辑过期。缓存里同时存数据和过期时间，物理 key 不立即删除。发现逻辑过期后，由后台线程刷新，前台请求先返回旧数据。
这种方式会牺牲一点实时性，但能换来更好的稳定性。对推荐、榜单、配置、活动展示类数据，通常是可以接受的。
六、短板四：监控发现得太晚
这次报警是从接口响应时间开始的，说明用户体验已经受影响。
更理想的情况，是在缓存命中率下降、某个 key 回源次数异常、数据库连接池升高时提前发现。
缓存相关监控至少应覆盖：
Redis 命中率和未命中次数。
热点 key 访问量。
缓存回源次数和耗时。
数据库连接池活跃连接数。
慢 SQL 数量。
接口 P95、P99 响应时间。
线程池队列长度。
这里有个很实用的指标：回源次数。
如果某接口平时每分钟回源几十次，突然变成几千次，即使接口还没超时，也应该预警。因为这说明缓存保护层已经开始失效。
只看 Redis 是否存活是不够的。Redis 活着，不代表缓存体系健康。
七、修复措施
故障恢复后，团队做了几项调整：
对热点 key 增加互斥回源。
部分热点缓存改为逻辑过期。
缓存过期时间增加随机值。
补充资源级限流，限制数据库回源并发。
增加降级开关，支持返回默认推荐列表。
新增缓存未命中率、回源次数、数据库连接池水位等监控。
发布和活动前增加缓存预热流程。
这些改动里，最重要的不是某一段代码，而是思路变化：不能把缓存只当成性能优化组件，它也是稳定性设计的一部分。
缓存正常时系统很快，缓存异常时系统还能不能稳住，才是真正要验证的能力。
八、稳定性不能只靠补丁
这次缓存击穿表面是代码逻辑问题，但从运维角度看，也暴露出体系问题：监控指标不完整，限流策略不细，降级预案不清楚，应急时缺少统一判断依据。
我了解到江苏立维运维服务在做企业运维、数据库运维和 7×24 保障时，会把 Redis、数据库、应用接口、主机资源和日志告警放在一起看。比如缓存命中率下降时，不只是看 Redis 是否正常，还会结合数据库连接池、慢 SQL、接口耗时、应用线程池来判断风险是否在扩大。
对系统比较多、内部运维人手有限的企业来说，这类协同运维比较实际。一方面可以补充日常巡检和夜间值守，另一方面也能帮助团队把故障复盘沉淀成规则，比如热点 key 巡检、容量趋势分析、告警阈值优化、应急操作手册等。
写在最后
缓存击穿并不复杂，但很容易暴露系统短板。
热点 key 不能裸奔，回源路径必须受控，限流要保护关键资源，降级方案要提前设计，监控要覆盖缓存失效前后的变化。
Redis 能提升性能，但不能替系统承担所有风险。真正稳定的系统，不是永远不出问题，而是在局部问题出现时，有办法把影响控制住。
