必须显式调用UNSUBSCRIBE，否则服务下线后仍会接收消息但无人处理，造成静默丢消息或重复消费；Redis服务端不会在连接断开瞬间原子清理订阅关系，易产生“幽灵订阅”。
必须显式调用 UNSUBSCRIBE，否则服务下线后仍会接收消息，但无人处理，造成静默丢消息或重复消费。
为什么不能靠进程退出自动清理
Redis 服务端不会在连接断开瞬间原子清理订阅关系。若微服务在 SUBSCRIBE 后立即崩溃（如 SIGKILL），服务端可能还没来得及把该连接注册进 pubsub_channels 字典；若在高负载下清理延迟，已下线实例仍会被 PUBSUB NUMSUB 统计为活跃订阅者。这种“幽灵订阅”会导致：
- PUBLISH 消息照常投递，但客户端进程已不存在，消息被直接丢弃
- 新实例上线后若复用相同频道名，可能和旧残留订阅者形成竞争消费
- 监控看到
PUBSUB NUMSUB channel返回非零值，误判消费者存活
Go 客户端（redis/v9）的正确退出流程
关键不是 defer Close()，而是让 ReceiveContext() 能响应 context 取消信号，并在退出前发 UNSUBSCRIBE：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
context.WithCancel()创建可取消上下文，传给rdb.Subscribe(ctx, "channel") - 启动 goroutine 执行
ps.ReceiveContext(ctx)，循环中检查errors.Is(err, context.Canceled) - 收到
SIGTERM时先调ps.Unsubscribe(ctx)（v9.0+ 支持带 ctx 的退订），再调cancel() - 避免在
ps.Close()后还调ReceiveContext()—— 此时会返回redis.Nil或 panic
Python redis-py v4+ 的安全退订写法
pubsub.close() 只关连接，不退订；必须用 unsubscribe() 或原生命令：
- 推荐写法：
pubsub.unsubscribe("channel")，它内部执行UNSUBSCRIBE channel并等待服务端确认 - 若需批量退订：
pubsub.unsubscribe()（无参数）退订所有当前频道 - 避免
r.execute_command("UNSUBSCRIBE", "channel")手动发命令——它不等待响应，无法确认是否生效 - 生产环境建议加超时：
pubsub.unsubscribe("channel", timeout=3)（需客户端支持）
Spring Boot 中整合优雅下线的要点
不能只依赖 @PreDestroy 关闭 StringRedisTemplate，PubSub 是独立连接：
- 单独管理
RedisPubSubListener或自定义PubSubConnection实例，注入到 Spring 容器 - 在
@PreDestroy方法中显式调用其unsubscribe("channel")或close()（确认该方法实际发UNSUBSCRIBE） - 配合 Spring 的
SmartLifecycle，将退订逻辑放在stop()阶段，并设置isAutoStartup() = true - 务必开启
ignore_subscribe_messages=True，避免把unsubscribe自身的消息误当作业务事件处理
最易被忽略的一点：容器化部署中，Kubernetes 的 preStop hook 执行时间可能短于 UNSUBSCRIBE 网络往返耗时，必须预留缓冲——比如设置 sleep 5 或用 curl -f http://localhost:8080/actuator/shutdown 触发 Spring 的 shutdown endpoint，由它协调 PubSub 退订与 HTTP 请求 drain。
