在高可用Redis Sentinel环境下，如何配置Redis发布订阅以应对主从切换对订阅的影响？

本文共计1091个文字，预计阅读时间需要5分钟。

Redis 发布订阅（Pub/Sub）本身不支持自动重连和订阅恢复。当使用 Sentinel 触发主从切换后，原订阅连接的节点（可能是旧主节点）可能会断开或拒绝新消息。这可能是由于以下原因：

常见现象包括：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）直接决定了最大可能的消息空窗期，这个窗口内所有发布和订阅动作都处于不可靠状态。