Redis Sentinel故障转移期间客户端重连的配置方法

Redis Sentinel 故障转移时，客户端重连的关键不是把端口改成某个“新主节点”，而是始终使用多个 Sentinel 和同一个 master-name 重新发现当前主节点。连接池负责重新建连，退避策略负责控制节奏，业务层则要单独判断请求能不能安全重试。

Redis Sentinel先解决地址发现，再谈客户端重连

Sentinel 通过服务名返回当前 master 的地址。故障转移完成后，原副本可能被提升为 master，客户端如果仍持有旧连接，就会遇到断开、只读或连接失败。Redis 官方 Sentinel client spec 要求客户端在超时、套接字错误或主动重连后再次解析 master 地址；因此，应用配置应保存 Sentinel 节点列表和 mymaster，而不是保存 6379 节点作为唯一入口。

生产环境通常放置三个相互独立的 Sentinel，并确认客户端能访问它们的 26379 端口。quorum 影响故障判定，不能替代客户端重连；Sentinel 还需要多数节点授权才能真正执行故障转移。

用 Sentinel 连接池跟随被提升的主节点

下面以 redis-py 的 Sentinel 客户端为例。示例中的超时只是起点，实际值要结合业务接口的耗时预算调整。每次从连接池取连接时，客户端会根据服务名找到当前 master；断线后重建连接也应继续走 Sentinel。

from redis.sentinel import Sentinel
from redis.exceptions import ConnectionError, TimeoutError

# 使用多个 Sentinel 入口，避免单个发现节点故障
sentinel = Sentinel(
    [("redis-sentinel-a", 26379), ("redis-sentinel-b", 26379), ("redis-sentinel-c", 26379)],
    socket_timeout=0.2,
    sentinel_kwargs={"socket_connect_timeout": 0.5},
)

# master_for 绑定服务名，不把当前主节点地址写死
master = sentinel.master_for(
    "mymaster",
    socket_connect_timeout=0.5,
    socket_timeout=1.0,
    decode_responses=True,
)

try:
    master.set("health:probe", "ok", ex=30)  # 只示范连接可用性，生产写入要确认幂等性
except (ConnectionError, TimeoutError):
    # 连接层失败交给有限退避；不要在这里无限重放业务写入
    raise

socket_connect_timeout 控制建立 TCP 连接的等待时间，socket_timeout 控制一次读写等待。Sentinel 自身的认证参数放在 sentinel_kwargs，Redis 主节点的认证参数则放在连接池参数中，不能因为 Sentinel 可访问就假定数据节点也已认证成功。

重连配置要把超时、退避和重试边界拆开

故障切换期间建议采用“重新发现—短暂退避—有限重试”的顺序。退避可以从 100 毫秒开始，按 2 倍递增并设置 2 秒上限，同时加入少量随机抖动；这只是避免大量实例同时敲击 Sentinel 的工程参数，不代表 Sentinel 的故障转移耗时。

特别要注意，客户端连上了一个尚未更新配置的 Sentinel，并不等于发现结果永久错误。Sentinel client spec 描述了通过 ROLE 检查发现过期信息并重新尝试的机制。应用侧应记录重连次数、最后一次发现地址和恢复耗时，便于区分“还在切换”与“网络或权限配置错误”。

故障转移后的检查清单与常见问题

• 检查所有 Sentinel 是否能互通，客户端是否配置了至少两个发现入口。
• 确认服务名完全一致，不能把 mymaster 写成数据节点主机名。
• 压测断线恢复时，分别记录 Sentinel 查询失败、Redis 连接失败和业务操作失败。
• 不要把超时错误直接等同于写入失败；对非幂等写入先查询业务结果或使用请求幂等键。

Sentinel 故障转移时要不要手动修改客户端主机地址？

不需要。客户端应重新向 Sentinel 查询同一个服务名，手工修改地址会把服务发现退化成单节点配置。

为什么已经连上 Sentinel，业务连接仍然失败？

Sentinel 连接和 Redis 数据节点连接是两条连接，可能分别需要认证、TLS 和不同的超时参数，需分开排查。

连接重试次数越多越好吗？

不是。连接层可以有限重试，业务层必须按幂等性决定是否重放；无限重试只会延长请求占用并放大故障。