Redis Sentinel故障转移后客户端连接未自动重定向的问题

问题现象

应用通过Redis Sentinel集群连接Redis。当主节点（Master）发生故障并由Sentinel完成故障转移（Failover）后，应用仍尝试连接旧的、已失效的主节点IP和端口，导致连接超时或失败。新主节点的地址未能自动更新到客户端。

根本原因

问题的核心在于对架构的误解。你的应用客户端连接的并不是Redis的主从节点，而是Sentinel集群。Sentinel的角色是监控、通知和指挥，它本身不处理数据请求。客户端需要向Sentinel集群询问：“谁现在是主节点？”，然后根据返回的地址去连接真正的主节点。故障转移后，客户端必须重新向Sentinel查询才能获得新主节点的地址。

解决方案：配置客户端连接管理器

主流语言的Redis客户端库都提供了专门的“Sentinel”连接模式。你只需正确配置，客户端库会自动处理与Sentinel的通信、获取主节点地址以及在故障转移后进行自动切换。

步骤一：确认你的客户端库支持Sentinel模式

选择一个成熟的、支持Sentinel的客户端库。以下是常见语言的推荐库：

步骤二：配置连接代码（核心步骤）

你需要在代码中提供Sentinel集群的地址列表和一个“服务名称”（在Sentinel配置中定义，通常是mymaster），而不是直接提供Redis主节点的地址。

1. 准备Sentinel信息。
   收集你所有的Sentinel节点地址（IP和端口），例如：

   • sentinel1.example.com:26379
   • sentinel2.example.com:26379
   • sentinel3.example.com:26379

2. 修改连接配置。
   以 ioredis (Node.js) 为例，正确的配置方式如下：

   const Redis = require('ioredis');
   
   // 错误的直连主节点方式（故障转移后会失效）
   // const client = new Redis(6379, 'old-master.example.com');
   
   // 正确的Sentinel模式连接方式
   const client = new Redis({
     sentinels: [
       { host: 'sentinel1.example.com', port: 26379 },
       { host: 'sentinel2.example.com', port: 26379 },
       { host: 'sentinel3.example.com', port: 26379 }
     ],
     // 在Sentinel配置中定义的服务名，用于识别监控的主节点组
     name: 'mymaster',
     // 可选：Sentinel也设置了密码
     sentinelPassword: 'your-sentinel-password',
     // 可选：连接Redis主节点/从节点时需要的密码
     password: 'your-redis-password'
   });
   
   client.on('error', (err) => console.error('Redis Client Error', err));

3. 其他语言配置示例。

   • redis-py (Python):

     from redis.sentinel import Sentinel
     
     # 创建Sentinel实例
     sentinel = Sentinel(
         [('sentinel1.example.com', 26379),
          ('sentinel2.example.com', 26379),
          ('sentinel3.example.com', 26379)],
         socket_timeout=0.1
     )
     
     # 获取主节点连接（自动故障转移）
     master = sentinel.master_for('mymaster', socket_timeout=0.1)
     
     # 使用主节点连接进行写操作
     master.set('mykey', 'myvalue')
     
     # 获取从节点连接（用于读）
     slave = sentinel.slave_for('mymaster', socket_timeout=0.1)
     value = slave.get('mykey')

   • Jedis (Java):

     import redis.clients.jedis.Jedis;
     import redis.clients.jedis.JedisSentinelPool;
     
     // 定义Sentinel节点集合
     Set<String> sentinels = new HashSet<String>();
     sentinels.add("sentinel1.example.com:26379");
     sentinels.add("sentinel2.example.com:26379");
     sentinels.add("sentinel3.example.com:26379");
     
     // 创建Sentinel连接池
     JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels);
     
     // 从池中获取一个连接（指向当前主节点）
     Jedis jedis = pool.getResource();
     
     // 使用jedis进行操作...
     jedis.set("key", "value");
     
     // 用完归还连接
     jedis.close();
     // 程序结束时关闭连接池
     pool.close();

步骤三：验证故障转移行为

部署修改后的代码后，手动触发一次故障转移进行验证。

1. 登录到任意一台Sentinel。

   redis-cli -p 26379

2. 查看当前主节点信息。

   127.0.0.1:26379> SENTINEL GET-MASTER-ADDR-BY-NAME mymaster
   1) "192.168.1.100"
   2) "6379"

   记下输出的IP和端口，这就是当前的主节点。

3. 模拟故障转移。

   127.0.0.1:26379> SENTINEL FAILOVER mymaster
   OK

4. 再次查询主节点地址。

   127.0.0.1:26379> SENTINEL GET-MASTER-ADDR-BY-NAME mymaster
   1) "192.168.1.101"
   2) "6379"

   地址应该已经改变。

5. 检查应用日志和连接状态。
   在你的应用日志中，观察客户端库是否输出了类似“主节点切换”、“连接重定向”或“重新连接”的日志。此时，应用的所有读写操作应已经无缝切换到了新主节点 192.168.1.101:6379 上，业务不应感知到中断。

常见问题排查

1. 连接超时或拒绝：

   • 检查应用服务器到三台Sentinel服务器的 26379 端口网络是否通畅。
   • 确认Sentinel配置文件 redis-sentinel.conf 中的 sentinel monitor 项里的服务名称（如 mymaster）与代码中的 name 参数完全一致。

2. 客户端库报错“无法找到主节点”：

   • 确认Sentinel集群自身状态健康。使用 redis-cli -p 26379 SENTINEL MASTERS 命令查看，确保所有Sentinel达成一致。
   • 检查Sentinel监控的主节点是否真实存在。如果整个主从集群都宕机了，客户端自然无法获取地址。

3. 故障转移后，应用短暂不可用：
   这是正常现象。故障转移过程需要时间（通常几秒到几十秒）。在此期间，客户端库会轮询Sentinel集群直到获取到新主节点地址。你可以调低客户端的连接超时和重试间隔参数来优化体验，但无法完全消除这段短暂中断。