Redis Sentinel读取主从切换后的服务发现结果的实现方法

Redis 主从切换后，应用不应该继续使用配置文件里的旧主节点地址。正确做法是把 Sentinel 监控名当作稳定的服务标识，客户端连接失败或收到切换信号时，重新向 Sentinel 查询当前主节点，再建立新的 Redis 连接。Sentinel 的职责是监控、故障转移和为客户端提供配置来源。

官方地址：https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/

先把 Sentinel 服务名和可达地址固定下来

客户端配置里要保存的是 Sentinel 节点列表与监控名，例如 mymaster，而不是 6379 对应的某个固定 IP。下面的配置只表达监控关系，副本由 Sentinel 自动发现：

sentinel monitor mymaster 10.20.0.11 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

其中最后的 2 是故障检测所需的 quorum，不等于一定能完成切换；真正执行故障转移还需要 Sentinel 多数派授权。生产部署应让三个 Sentinel 分布在独立故障域，并确保客户端能访问 Sentinel 的 26379 端口。

用服务名读取切换后的主节点地址

确认 Sentinel 已经运行后，可以先用命令验证返回结果。返回值是两项数组：第一项为当前主节点地址，第二项为端口。

# 用任意可达的 Sentinel 查询当前主节点地址
redis-cli -h 10.20.0.21 -p 26379 \\
  SENTINEL get-master-addr-by-name mymaster

如果当前主节点是 10.20.0.11:6379，命令会返回这两个值。应用代码应把它们视为一次服务发现结果，并设置合理的缓存时间；不要把返回值永久写回固定配置。

连接断开时，处理顺序建议是：先关闭旧连接，再从 Sentinel 地址列表中选择一个可达节点查询；查询成功后按返回的 IP 和端口重连；查询失败则切换下一个 Sentinel，并使用退避避免故障期间形成请求风暴。

客户端重建连接时要保留哪些边界

Sentinel 只负责告诉客户端当前角色地址，不会替应用处理连接池中的旧连接。连接池需要让旧连接失效，重连逻辑也要避免多个请求同时创建大量新连接。伪代码可以按下面的边界组织：

func discoverMaster(ctx context.Context, sentinels []string, name string) (string, error) {
    for _, addr := range sentinels {
        // 每次查询都使用短超时，避免单个 Sentinel 拖住整个重连窗口。
        queryCtx, cancel := context.WithTimeout(ctx, 800*time.Millisecond)
        host, port, err := querySentinel(queryCtx, addr, name)
        cancel()
        if err == nil {
            // 返回一次服务发现结果，由上层负责创建新的 Redis 连接。
            return net.JoinHostPort(host, strconv.Itoa(port)), nil
        }
    }
    return "", errors.New("no reachable sentinel returned master")
}

真实客户端库的 API 名称可能不同，但边界相同：Sentinel 地址列表要可轮换，查询和 Redis 业务连接要分别设置超时，重连过程要有单飞或锁，防止切换时每个请求各自建连接。

发布前检查端口映射、权限和数据风险

如果应用运行在 Docker 或 NAT 后面，应重点检查 Sentinel 宣告的地址。Redis 官方文档明确指出，端口重映射会影响 Sentinel 发现其他 Sentinel 和副本；必要时配置 sentinel announce-ip 与 sentinel announce-port，或者使用一一对应的网络模式。切换演练至少要记录旧主停止、Sentinel 返回新地址、应用连接池恢复三个时间点。

相关问题

Sentinel 的 quorum 设置越大越安全吗？

quorum 影响故障检测所需的同意数，切换执行还受 Sentinel 多数派影响。应结合 Sentinel 总数和故障域设置，不能只追求更大的数字。

为什么查询结果正确但应用仍连接旧主？

通常是连接池仍保留旧连接，或应用只在启动时查询一次。让连接错误、切换通知或定时刷新触发重新发现，并清理旧连接。

Sentinel 能保证已确认写入不丢吗？

不能。Redis 主从复制是异步的，故障时已确认但尚未复制到新主的写入可能丢失；需要结合业务幂等、写入确认策略和演练结果评估。