Redis Sentinel 切主后客户端为何频繁重连：主观下线与连接池恢复检查

Redis Sentinel 切主后客户端短时间内频繁重连，通常不是“Redis 又挂了”这么简单。Sentinel 先对旧主做主观下线判断，再通过 +switch-master 事件通知新主地址；客户端如果没有正确更新服务发现，或者连接池还在复用旧连接，就会出现重连风暴。

先用 Sentinel 事件确认切主是否真的发生，再检查客户端是否拿到新主地址，最后处理连接池里的旧连接；不要一看到连接断开就反复重启 Redis。

先判断：这是主观下线，还是已经切主

线上最容易误判的信号是连接错误突然变多。一个 Sentinel 记录 +sdown，只能说明它自己认为被监控实例不可达；网络抖动、探针超时或 Sentinel 到 Redis 的单向断链都可能触发它。多个 Sentinel 达成共识后，才会进入故障转移流程。

先在运维窗口查询当前主地址，不要凭应用日志里最后一次连接地址下结论：

redis-cli -h sentinel-1 -p 26379 SENTINEL get-master-addr-by-name mymaster
redis-cli -h sentinel-1 -p 26379 SENTINEL masters

如果返回的地址仍是旧主，客户端此时的重连可能只是旧主短暂不可达；如果返回了新地址，则进入切主后的客户端恢复排查。

从 Sentinel 事件追到客户端地址更新

切主完成后，Sentinel 会发布 +switch-master 事件，事件里包含监控名称、旧主地址和新主地址。应用或客户端库需要订阅这个事件，重新执行 SENTINEL get-master-addr-by-name，然后把新的主地址交给连接池。

图中 +sdown 是判断信号，不应被客户端当成“已经有新主”；真正驱动地址切换的是 +switch-master。排查时把 Sentinel 日志、客户端事件回调和连接池配置放在同一条时间线上。

SUBSCRIBE +switch-master
SENTINEL get-master-addr-by-name mymaster

处理步骤：先隔离旧连接，再让新连接接管

确认新主地址后，处理顺序要固定下来。第一步暂停会继续向旧连接发请求的工作线程或连接池借出动作；第二步关闭已经收到连接重置、读写超时的旧连接；第三步用 Sentinel 查询到的新地址创建少量探测连接，确认 PING 和一笔可回滚的业务探测成功后，再逐步放开流量。

这里别急着把连接池上限调大。旧地址没有被替换时，扩容只会制造更多失败连接。客户端日志至少应保留目标地址、连接创建时间、关闭原因和重试次数，方便判断重连是否集中在旧主。

回滚路径：新主不稳定时如何收住影响

如果新主连接建立后仍持续超时，先停止扩大流量，把客户端恢复到“只保留少量探测连接”的状态。不要手工把客户端地址改回旧主，也不要直接删除 Sentinel 配置；这会让不同应用看到不同主，后续故障转移更难收敛。

回滚动作应由值班人员根据 Sentinel 当前主地址、复制偏移和应用错误率决定。若只是客户端配置发布错误，回滚客户端版本并保留 Sentinel 的切主结果；若 Sentinel 本身误判，则先恢复 Sentinel 与 Redis 之间的网络和探测，再按官方故障转移流程处理。

告警确认：重连风暴是否真的结束

恢复不是“连接数回来了”就结束。至少连续观察一段业务窗口：旧主地址上的连接错误应停止增长，新主的写入探测应成功，客户端重试次数回落，Sentinel 的主节点查询结果在多个 Sentinel 上一致，副本复制状态也要恢复到预期。

如果连接错误仍在增长，重点看两处：服务发现缓存是否还保存旧地址，连接池是否只在借出时才发现连接已失效。很多重连风暴不是 Sentinel 没切主，而是客户端迟迟没有把新地址写入自己的连接管理层。

常见问题：Sentinel 切主后的连接为什么还会失败

+sdown 出现后要立刻改客户端地址吗？

不要。+sdown 是单个 Sentinel 的主观判断，先通过 SENTINEL get-master-addr-by-name 和其他 Sentinel 的状态确认当前主地址。

客户端一定会自动跟随 +switch-master 吗？

不一定，取决于客户端库是否使用 Sentinel 模式并正确订阅事件。只配置一个固定 Redis 地址的客户端不会因为 Sentinel 发生切主就自动换地址。

为什么新主可连，业务仍然大量报错？

常见原因是连接池中的旧连接尚未淘汰，或者应用把服务发现结果缓存得过久。检查连接目标地址和连接创建时间，比单看连接池总数更有效。

复盘项：把一次重连风暴变成可验收动作

• 记录 +sdown、+switch-master、新主查询结果和客户端首个成功请求的时间。
• 明确客户端库的 Sentinel 订阅、地址刷新、旧连接淘汰和重试上限配置。
• 用故障演练验证“旧主不可达—切主—新地址—连接池恢复—业务写入”的完整链路。