redis pub/sub 无法恢复消息，因其纯内存、无状态，未消费消息立即丢失；应剥离核心链路，改用哨兵/集群架构+客户端重连重订阅，并在业务层保障可靠性。
Redis 发布订阅（Pub/Sub）本身不提供持久化和故障恢复能力，系统崩溃后未消费的消息直接丢失；它不是消息队列，不能替代 Kafka 或 RabbitMQ。要“快速恢复”，关键不是修复 Pub/Sub 本身，而是把发布订阅逻辑从核心链路中剥离，改用具备高可用保障的主从 + 哨兵（Sentinel）或集群（Cluster）架构承载数据存储与状态同步，再配合客户端重连、重订阅机制。
Redis Pub/Sub 崩溃后为什么无法“恢复消息”
Pub/Sub 是纯内存、无状态的通信模式：PUBLISH 命令发出后，若此时没有活跃的 SUBSCRIBE 客户端，消息立即丢弃，不会写入任何持久化文件或复制到从节点。哨兵或集群切换时，新主节点上也没有历史 Pub/Sub 消息缓存。
常见错误现象包括：
- 服务重启后，消费者收不到断连期间发布的消息
- 主节点故障转移期间，
SUBSCRIBE连接被强制断开，但客户端未重连或未重新SUBSCRIBE - 误以为开启
appendonly yes就能让 Pub/Sub 消息落盘——实际 AOF/RDB 完全不记录 Pub/Sub 操作
用 Sentinel 架构支撑 Pub/Sub 的最小可行配置
虽然 Pub/Sub 消息本身不可恢复，但你可以让整个 Redis 服务在崩溃后秒级自动切主，缩短中断窗口。Sentinel 是目前对中小规模最实用的选择，3 节点部署即可规避单点风险。
实操建议：
- 至少部署
3个哨兵进程（跨机器），避免哨兵自身成为单点；sentinel monitor mymaster 127.0.0.1 6379 2中的2表示需 2 个哨兵达成共识才触发故障转移 - 主节点必须配置
requirepass，所有哨兵配置里都要加sentinel auth-pass mymaster your_password，否则切换后新主节点拒绝认证，客户端连不上 - 从节点启用
replica-read-only yes，防止人为误操作写入脏数据，影响后续故障转移判断 - 客户端连接必须使用哨兵发现机制（如 Jedis 的
JedisSentinelPool或 redis-py 的SentinelConnectionPool），而非硬编码主节点地址
客户端如何应对 Pub/Sub 连接闪断
即使后端 Redis 已高可用，网络抖动或主从切换仍会导致 SUBSCRIBE 连接断开。此时靠服务端“恢复”没用，必须由客户端主动兜底。
关键动作：
- 监听连接断开事件（如 redis-py 的
ConnectionError或 Jedis 的JedisConnectionException），触发重连逻辑，不要依赖超时自动重试 - 重连成功后，必须重新执行
SUBSCRIBE，不能假设订阅关系被保留——Redis 不维护订阅状态的跨连接持久性 - 对关键业务消息，考虑在
PUBLISH前先写入一个带 TTL 的SET或LPUSH到主从同步的数据结构中，让消费者在重连后主动拉取“漏掉”的消息范围 - 避免在单个连接上混用
SUBSCRIBE和普通命令；推荐专用连接做 Pub/Sub，普通读写走另一套连接池
什么时候该放弃 Pub/Sub，改用 Cluster 或外部 MQ
如果你的需求包含以下任意一条，就说明 Pub/Sub 已超出其设计边界：
- 要求消息至少送达一次（at-least-once）
- 需要按时间回溯历史消息（如重放某类事件）
- 消费者上线延迟 > 几秒，且不能接受消息丢失
- 单节点内存扛不住全部 topic 的吞吐，需要水平扩展
这时应切换方案：
- 数据量不大但需可靠：改用 Redis Stream（
XADD/XREADGROUP），它支持消费者组、ACK、消息持久化和失败重试，且天然兼容主从+哨兵 - 数据量大、需严格顺序与堆积能力：直接上 Kafka 或 Pulsar，Redis 不适合当主力消息中间件
- 已用 Cluster 且不愿引入新组件：Stream 在 Cluster 模式下有限制（key 必须落在同一 slot），需用
{...}tag 强制路由，或改用客户端分片
真正容易被忽略的点是：很多人花大量时间调优哨兵参数，却没意识到 Pub/Sub 本身就不该承载可靠性要求。把“消息不丢”的责任从通信机制转移到业务层（比如发消息前先记日志、消费后更新状态），往往比强行给 Pub/Sub 加高可用更简单有效。
