Redis Pub/Sub不能直接用于雪崩降级，因其不持久、无重试、不保证送达；可行方案是将降级开关存Redis共享key，用Pub/Sub仅广播变更事件，各服务监听后主动GET拉取最新值，并辅以定期轮询和本地兜底。
Redis Pub/Sub 不能直接用于雪崩降级，必须配合熔断器状态广播
Pub/Sub 本身不持久、不断连重试、不保证送达，雪崩发生时 Subscriber 很可能已掉线，收不到任何通知。想靠它“发个指令让所有服务立刻降级”，基本不可行。
真正可行的路径是：把降级开关（如 cache.fallback.enabled）写入 Redis 的一个共享 key（如 config:service:cache-fallback），再用 Pub/Sub 只做“变更广播”——即当这个 key 被修改时，主动 PUBLISH config:update "cache-fallback"，各服务监听该频道后，再去 GET config:service:cache-fallback 拉取最新值。
- 避免直接在消息体里传降级逻辑（比如 JSON 包含
{"enabled":true,"strategy":"local"}），因为断连期间消息丢失就彻底失效 - 必须搭配定期轮询（如每 30 秒
GET一次），防止首次启动或网络抖动导致漏读广播 - 频道名建议带环境前缀，例如
prod:config:update，避免测试环境误触生产降级
为什么不能用 SUBSCRIBE 在 Web 层动态监听降级信号？
HTTP 请求生命周期太短，SUBSCRIBE 后连接进入订阅模式，无法执行其他命令；请求一结束，连接关闭，订阅自动取消。你根本等不到消息来。
正确做法是：在应用启动时，用独立长连接（非 Web 线程池里的 client）初始化 PubSub 客户端，并注册回调函数。以 redis-py 为例：
pubsub = redis_client.pubsub()
pubsub.subscribe('prod:config:update')
def handle_message(message):
if message['type'] == 'message':
# 这里只触发重载，不执行业务逻辑
reload_fallback_config()
pubsub.run_in_thread(sleep_time=0.01)
- 别在
handle_message里查 DB 或调远程接口——降级阶段这些很可能已不可用 -
run_in_thread要设sleep_time，否则空转吃满 CPU；但别设太大，否则消息延迟高 - 必须检查
pubsub.connection是否存活，断连后手动unsubscribe+subscribe，客户端不会自动重订频道
降级开关值存在 Redis 里，怎么防止单点写失败导致全链路失效？
如果只依赖一个 SET config:service:cache-fallback true，而 Redis 正在雪崩中响应慢或超时，这个写操作就会失败，降级指令发不出去。
必须设计 fallback 写入路径：
- 主写路径：用
SET config:service:cache-fallback true EX 300 NX，带过期和原子性，避免旧值残留 - 备写路径：同时向本地文件（如
/tmp/fallback.flag）写入时间戳，应用启动时优先读该文件加载初始状态 - 兜底行为：若 Redis 连不通，且本地文件也不存在，则默认启用保守降级（如强制走本地缓存 + 返回静态兜底数据）
注意：EX 300 是必须的——否则开关一旦写入就永久生效，下次恢复时还得人工清理，容易遗忘。
监听 config:update 频道时，PUBLISH 消息体里该传什么？
只传变更的 key 名，不要传值。例如 PUBLISH prod:config:update "config:service:cache-fallback"，而不是传完整 JSON。
理由很实际：
- Redis 不校验 message 内容，JSON 格式错误、编码不一致（如 Go 发 UTF-8，Python 收到乱码）都会导致解析失败
- 值可能很大（比如包含多组降级策略），Pub/Sub 是内存直传，大消息拖慢整个 Redis 主线程
- 各服务对同一配置的理解可能不同（如 A 服务认为
"true"表示启用，B 服务只认1），统一由各服务自己GET解析更可控
真正容易被忽略的是：每次 GET 后，必须用 PTTL 检查剩余 TTL，如果接近 0，说明配置已过期，应主动触发一次 SET 刷新——否则开关会悄无声息地失效。
