Redis本身不提供熔断能力，熔断降级需在应用层实现；应结合缓存空值+随机TTL、连接池治理及按业务维度隔离的熔断器协同防御缓存击穿。
缓存击穿发生时，Redis 本身不提供熔断能力
Redis 是一个内存数据库，它没有内置的熔断器、限流器或降级开关。所谓“Redis 实现熔断降级”，本质是应用层在发现缓存击穿（大量请求穿透到 DB）后，主动拦截后续请求、返回兜底数据或错误，避免 DB 被打垮。SETNX、GET、EXPIRE 这些命令只是工具，不能自动触发熔断逻辑。
典型错误是以为加个 SETNX key lock 10 EX 就万事大吉——锁失效时间设短了会频繁重建，设长了又导致雪崩期间长时间不可用；更关键的是，锁只解决“重建缓存”并发问题，不解决“重建失败后反复冲击 DB”的问题。
用 Resilience4j 或 Hystrix 在应用侧做请求级熔断
真正起作用的是业务代码里的熔断器。比如 Java 项目中用 Resilience4j 包裹查 DB 的方法：
Decorators.ofSupplier(() -> userDao.findById(id)) .withCircuitBreaker(circuitBreaker) .withFallback((throwable) -> User.defaultUser()) .get();
关键配置项包括：failureRateThreshold（失败率阈值，默认 50%）、waitDurationInOpenState（熔断打开后保持时间）、minimumNumberOfCalls（触发统计的最小调用数）。这些参数必须结合你 DB 的实际错误率和恢复时间来调，不是套模板就能用。
- DB 查询超时或抛出
SQLException算失败，但CacheException（如 Redis 连接失败）不应计入熔断统计，否则 Redis 暂时抖动会导致误熔断 - 熔断器状态（OPEN / HALF_OPEN / CLOSED）建议暴露为 Prometheus 指标，方便告警
- 不要对所有缓存 key 共享同一个熔断器——高频 key 和低频 key 的失败特征差异很大，应按业务维度（如 user:*, order:*）分组隔离
缓存空值 + 随机过期时间，比硬熔断更轻量有效
对大多数读多写少、key 空间有限的场景（如商品详情、用户资料），提前防御比事后熔断更可靠。核心是两件事：GET 返回 null 后，写入一个带短 TTL 的空对象；且这个 TTL 加上随机偏移（比如 60–120 秒），避免空值集体过期引发二次击穿。
示例伪代码：
String cacheKey = "user:" + id;
String value = redis.get(cacheKey);
if (value != null) return parse(value);
// 查 DB
User user = db.selectById(id);
if (user == null) {
// 写空值，TTL 随机化
int ttl = 60 + ThreadLocalRandom.current().nextInt(61);
redis.setex(cacheKey, ttl, "null");
return User.empty();
}
redis.setex(cacheKey, 3600, toJson(user));
return user;
注意："null" 字符串不能直接当业务对象反序列化，应用层要显式识别并跳过；另外空值键名建议加前缀（如 empty:user:123），便于批量清理或监控。
Redis 连接池耗尽是熔断失效的隐藏诱因
当缓存击穿发生，大量请求走 DB 同时还在抢 Redis 锁、写空值、刷新缓存，容易把连接池打满。此时即使熔断器处于 CLOSED 状态，Jedis.getResource() 或 LettuceConnection 获取连接也会阻塞或超时，导致整个请求链路 hang 住，反而掩盖了真实问题。
必须检查：
-
maxTotal（Jedis）或maxResources（Lettuce）是否足够支撑峰值 QPS × 平均耗时（秒） - 是否设置了合理的
maxWaitMillis，避免线程无限等待连接 - Redis 命令是否用了 pipeline 或 batch，减少往返次数；尤其避免在循环里反复
GET/SET
连接池打满时，日志里常见 JedisConnectionException: Could not get a resource from the pool，这不是 Redis 故障，而是客户端没管好资源。
复杂点在于：熔断、降级、缓存空值、连接池治理这四件事必须协同设计。单独做任何一项，都可能在高并发下被绕过或放大问题。
