一次缓存击穿暴露的限流降级策略短板

不少缓存故障，第一反应都以为是Redis出了状况。 接口变慢、数据库连接数飙升、应用线程池开始堆积，报警信息一条接一条。大家的第一反应通常是去查Redis：是不是宕机了？网络抖动了？还是内存满了？ 这次故障复盘之后发现，Redis本身其实一切正常。真正的问题，是一个热点key在业务高峰期过期了——缓存没能挡住流量，请求一瞬间直接打到了数据库。更要命的是，系统既没有及时限流，也没有成熟的降级方案，一个局部的小问题，最终被放大成了接口大面积超时。 ## 一、故障现象：接口突然变慢 出问题的是首页推荐接口。 这个接口读取的是热门商品和活动配置，平时访问量相当高。核心数据放在Redis里，缓存命中时，响应基本都在几十毫秒。 故障发生在业务高峰期。监控先提示接口的P95响应时间飙升，从几十毫秒直接涨到了2秒以上。紧接着，应用日志里开始出现大量超时，数据库连接池接近打满，慢SQL数量明显增加。 当时几个信号非常清晰： - Redis状态正常，没有重启、没有内存淘汰、也没有连接异常。 - 数据库CPU升高，连接数明显增加。 - 应用线程池队列开始堆积，请求等待时间变长。 - 慢SQL集中在同一张业务表。 这些线索说明，问题不像Redis整体不可用，更像是某类请求绕过了缓存，集中打到了数据库上。 ## 二、根因：热点key被击穿 顺着日志继续查，发现大量请求都在查询同一个缓存key。 这个key对应的是首页热门商品列表，过期时间设置为30分钟。正常情况下命中率很高，数据库压力很小。 问题就出在那个过期瞬间。 当这个热点key失效时，恰好有大量用户请求进来。应用的逻辑是：先查Redis，没命中就去查数据库，然后回写缓存。但因为系统没有做互斥控制，几十个请求同时发现缓存不存在，于是一起涌向数据库。 数据库原本只需要承接一次回源查询，结果被迫同时处理一大批并发查询。查询本身不算慢，但并发一上来，连接池就被占满了，其他接口也受到了影响。 这就是典型的缓存击穿。 缓存击穿和缓存雪崩不一样。雪崩是大量key同时失效，影响面更广；而击穿是某个热点key失效，流量集中打穿了一个点。 ## 三、短板一：没有互斥回源 防止缓存击穿，最直接的办法就是让回源查询变成“单线程”或“少量线程”。 缓存失效后，不应该让所有请求都去查数据库。正确的做法是：一个请求拿到锁去加载数据，其他请求短暂等待后，再去读缓存。 伪代码大致是这样： ``` 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增加了互斥回源。 - 部分热点缓存改为了逻辑过期。 - 缓存过期时间增加了随机值。 - 补充了资源级限流，限制了数据库回源的并发数。 - 增加了降级开关，支持返回默认推荐列表。 - 新增了缓存未命中率、回源次数、数据库连接池水平等监控指标。 - 发布和活动前增加了缓存预热流程。 这些改动里，最重要的不是某一段代码，而是思路上的转变：不能把缓存只当成性能优化组件，它本身就是稳定性设计的一部分。 缓存正常时系统很快，缓存异常时系统还能不能稳住——这才是真正需要验证的能力。 ## 八、写在最后 缓存击穿并不复杂，但它很容易暴露出系统里的各种短板。 热点key不能裸奔，回源路径必须受控，限流要保护关键资源，降级方案要提前设计，监控要覆盖缓存失效前后的变化。 Redis能提升性能，但不能替系统承担所有风险。真正稳定的系统，不是永远不出问题，而是在局部问题出现时，有办法把影响控制住。