Redis 不提供熔断降级功能，仅可作为状态存储或信号灯辅助实现，真正的熔断决策和降级行为需由应用代码或框架（如 Resilience4j）完成。
Redis 本身不提供熔断降级功能
Redis 是一个内存数据库 / 缓存中间件，它没有内置的熔断器（circuit breaker）或自动降级逻辑。所谓“Redis 实现熔断降级”，实际是指在应用层借助 Redis 辅助完成状态记录、开关控制或兜底缓存，而真正的熔断决策和行为必须由业务代码或框架（如 Sentinel、Resilience4j、Hystrix）来执行。
常见错误现象：Connection refused 或 Timeout waiting for connection from pool 暴露后，直接在 Redis 里删 key 或改值就想“恢复服务”——这解决不了下游 DB 已雪崩的问题。
- Redis 只能当“记事本”或“信号灯”，比如用
SETNX记录某接口是否已触发熔断 - 真正拦截请求、跳过 DB 调用、返回默认值，得靠应用代码里的 if 判断或 AOP 拦截
- 如果用 Redis 做降级结果缓存（例如 DB 查询失败后把空对象或历史快照写入
cache:order:123），要注意设置合理过期时间，否则脏数据会滞留
用 Redis 存熔断开关：SETNX + EXPIRE 最简可行
想让多个实例共享熔断状态，最轻量的方式是用 Redis 的原子操作存一个带过期的开关 key。不要用 SET 直接覆盖，避免并发写入导致状态错乱。
典型使用场景：某个支付查询接口频繁超时，需要全局限流并降级为“暂不可查”。
- 写开关：
SETNX circuit:payment:query 1，成功后再EXPIRE circuit:payment:query 60（防死锁） - 读开关：
GET circuit:payment:query，非空即表示已熔断 - 别用
INCR或HSET存状态计数——没过期机制，容易堆积失效状态 - 注意 Redis 集群模式下
SETNX是分片执行的，确保 key 落在同一 slot（加{circuit}前缀）
降级数据缓存到 Redis：慎选 TTL 和更新策略
DB 不可用时，把上次成功结果或兜底值写进 Redis，能让前端至少看到“旧但可用”的数据。但这不是无脑缓存，TTL 和一致性是关键矛盾点。
常见错误现象：DB 恢复后，页面仍显示 5 分钟前的错误提示页，因为降级 key 还没过期。
- 降级缓存建议用短 TTL（如
30s），配合主动删除：DB 恢复后立刻DEL cache:product:456:degraded - 不要和正常缓存共用同一套 key 命名，明确区分，例如加
:degraded后缀，避免误读 - 如果降级内容是空对象（
null），务必用特殊标记（如"DEGRADED_NULL"）存 Redis，防止客户端把空字符串当有效值 - 高并发下大量写降级 key 可能打爆 Redis 内存，可加本地缓存（如 Caffeine）做二级保护
结合 Resilience4j + Redis 实现带持久化的熔断
Resilience4j 默认把熔断状态存在内存里，重启就丢。要跨进程保持状态，就得把它和 Redis 绑定——但不是所有状态都值得存，只同步核心字段。
使用场景：K8s 环境下 Pod 频繁滚动，需保证熔断状态不因重启归零。
- 只需持久化
state（OPEN/CLOSED/HALF_OPEN）、failureRate和lastModified，其他统计（如滑动窗口计数）仍走内存 - 每次状态变更后，用 Lua 脚本原子写入 Redis：
EVAL "redis.call('HMSET', KEYS[1], 'state', ARGV[1], 'rate', ARGV[2]); redis.call('EXPIRE', KEYS[1], 300)" 1 circuit:search - 别每秒轮询 Redis 同步状态——开销大且易超时；改为监听 Resilience4j 的
onStateTransition事件再写 - Redis 故障时，降级为纯内存模式（
fallbackToMemory），避免雪上加霜
Redis 的角色始终是辅助：存开关、缓降级、传状态。真正的熔断逻辑、超时判定、fallback 执行，都在你自己的代码里。最容易被忽略的是——没给降级 key 设过期，或者把熔断状态当成强一致数据去依赖，结果 Redis 延迟一抖，整个降级策略就失准了。
