Redis Sentinel主从切换会导致Pub/Sub订阅连接硬中断，客户端须监听断连事件、通过SENTINEL获取新主地址、重建PubSub实例并重订阅；Pub/Sub不保证消息持久化，高可靠场景应改用Redis Stream。
Redis Sentinel环境下订阅连接会断开，必须重连并重新订阅
Redis 发布订阅（Pub/Sub）本身不支持自动重连和订阅恢复。当 Sentinel 触发主从切换后，原订阅连接所连的节点（可能是旧主或从）会断连或拒绝新消息，PSUBSCRIBE 或 SUBSCRIBE 连接直接失效——这不是超时或延迟问题，而是 TCP 连接被对端关闭或 AUTH 失败导致的硬中断。
常见现象包括：Connection closed by server、READONLY You can't write against a read only replica（误连到只读从库）、或静默收不到消息但连接看似“活着”（实为半开连接）。
- 客户端必须监听连接断开事件（如 Python 的
ConnectionError、Node.js 的error/close事件） - 重连前需通过 Sentinel 获取当前主节点地址：
SENTINEL get-master-addr-by-name <master-name> - 重连成功后，必须重新执行
SUBSCRIBE或PSUBSCRIBE，订阅关系不会继承 - 避免在重连间隙丢消息：Pub/Sub 本身不保证消息持久化，若需可靠性，应配合 Redis Stream 或外部队列
Python redis-py 客户端如何安全处理 Sentinel 切换后的订阅
redis-py 的 StrictRedis 和 Redis 类本身不管理 Pub/Sub 的自动恢复；其 Sentinel 类可获取主节点地址，但 PubSub 实例是独立对象，不感知 Sentinel 状态变化。
正确做法是封装一个带重试和重订阅逻辑的循环：
from redis.sentinel import Sentinel
import time
<p>sentinel = Sentinel([('localhost', 26379)], socket_timeout=0.1)
pubsub = None</p><p>def get_fresh_pubsub():
master = sentinel.master_for('mymaster', socket_timeout=0.1)
return master.pubsub()</p><p>while True:
try:
if pubsub is None:
pubsub = get_fresh_pubsub()
pubsub.subscribe('channel:log')
for msg in pubsub.listen(): # 阻塞式监听
print(msg)
except (ConnectionError, TimeoutError):
print("Pub/Sub connection lost, reconnecting...")
if pubsub:
pubsub.close()
pubsub = None
time.sleep(0.5) # 避免密集重连
- 不要复用旧
PubSub实例：它绑定的是已失效连接，close()后必须重建 -
socket_timeout设小值（如 0.1s），让listen()能及时响应断连而非卡死 - 避免在
subscribe()前未检查连接可用性——某些版本 redis-py 在连接失败时会静默跳过订阅
为什么不能用普通 Redis 连接池替代 Pub/Sub 连接
Redis 连接池（如 ConnectionPool）适用于命令请求（GET/SET/LPUSH 等），但 Pub/Sub 的 listen() 是长生命周期阻塞调用，会独占连接、阻塞整个连接池线程——这与连接池“复用+短时占用”的设计目标冲突。
- 一个
PubSub实例必须持有专属连接，不能从通用连接池中借出 - 使用连接池 +
pubsub()方法返回的实例，底层仍会新建专用连接，池本身不参与管理 - 若强行把 Pub/Sub 连接放池里，会导致其他命令等待、超时，甚至触发连接泄漏（因
listen()不返回）
主从切换期间消息是否丢失？取决于发布方行为
Pub/Sub 消息仅存在于内存中，且只转发给当前在线订阅者。切换瞬间若发布者仍往旧主发消息，而新主尚未完成数据同步或订阅连接未重建，这部分消息必然丢失。
- 发布方也应通过 Sentinel 获取主节点再
PUBLISH，避免写入旧主（旧主降级后可能拒绝写入，抛READONLY错误） - 没有机制能让新主“回溯”旧主未发出的 Pub/Sub 消息——它不是复制流的一部分
- 若业务不能容忍丢失，必须放弃纯 Pub/Sub，改用
XRANGE+XADD（Stream）并配合消费者组，由客户端自行管理读取偏移
最易被忽略的一点：Sentinel 的故障转移时间（down-after-milliseconds + failover-timeout）直接决定了最大可能的消息空窗期，这个窗口内所有发布和订阅动作都处于不可靠状态。
