PUB/SUB在Redis高可用架构中不参与主从切换、不保证消息不丢失，仅作轻量广播通道；其消息不走复制流，主节点PUBLISH后从节点无消息历史，切换后无消息继承，客户端需主动重连并重订阅。
PUB/SUB 在 Redis 高可用架构中不参与主从切换决策，也不保证消息不丢失——它只是个轻量广播通道，和主从复制、哨兵故障转移完全解耦。
PUB/SUB 的消息不走复制流
Redis 的主从复制只同步写命令（如 SET、LPUSH），而 PUBLISH 命令本身不会被传播到从节点。也就是说：
- 主节点执行
PUBLISH channel1 "msg"，仅当前节点的订阅者能收到 - 从节点即使已同步完 RDB 或 AOF，也没有该频道的任何消息历史
- 切换发生时，新主节点上没有任何“未消费消息”可继承
常见错误现象：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 主节点宕机前发布的消息，在哨兵选主完成后，原订阅客户端重连新主，却收不到那条消息
- 客户端在切换窗口期（比如 2–3 秒）内调用
SUBSCRIBE，可能错过正在广播的消息
哨兵模式下 SUBSCRIBE 连接要主动重试
SUBSCRIBE 是长连接，底层 TCP 一旦断开（比如主节点挂掉、网络抖动、哨兵强制 failover），客户端必须自己重建连接并重新 SUBSCRIBE。Redis 服务端不会自动续订或回溯。
- 不要依赖客户端库的“自动重连”功能来恢复订阅状态——多数库只重连，不重订频道
- 必须监听连接断开事件，并在重连后显式执行
SUBSCRIBE（或PSUBSCRIBE） - 若使用多个频道，需确保所有频道都重新注册，否则部分消息会静默丢失
主从切换期间 PUB/SUB 出现“黑洞期”是设计使然
腾讯云实测数据指出，主备切换平均造成 2–3 秒消息黑洞期，这不是 bug，而是 PUB/SUB 的固有局限：
- 切换过程中，旧主停止服务，新主尚未完成选举或尚未接受新连接
- 订阅者连接可能卡在半关闭状态，
PUBLISH请求被丢弃（无 ACK，无重试） - 即使你用哨兵 +
SENTINEL GET-MASTER-ADDR-BY-NAME动态获取新主地址，DNS 缓存、TCP TIME_WAIT、客户端连接池冷启动都会引入延迟
真正容易被忽略的一点：PUB/SUB 的可靠性边界非常窄——它只承诺“发出去”，不承诺“谁收到”“什么时候收到”“收到几次”。如果你的业务逻辑依赖某条发布消息必达（比如订单状态变更通知），就不要把它放在 PUB/SUB 上，改用带 ACK 的队列（如 Redis Streams + XREADGROUP）或外部消息中间件。
