Redis 哨兵模式在消息队列场景下切换失败，通常源于法定人数不足、网络分区或客户端重连配置不当。排查需优先确认哨兵集群状态，再检查队列客户端配置，最后验证消息一致性。

故障根因分析

Redis 哨兵模式依赖多数派原则进行故障判定。当主节点不可达时，哨兵需要足够数量的节点（quorum）确认故障才能发起切换。如果网络出现分区，部分哨兵无法互相通信，就无法达成多数派共识，导致切换流程卡住。

在消息队列场景下（如使用 List 或 Stream 结构），即使服务端切换成功，如果客户端缓存了旧的主节点 IP 且没有定期刷新，业务请求或消息消费仍会发往旧地址，表现为切换失败、消息积压或重复消费。此外，Redis 异步复制机制决定了故障切换期间可能存在少量消息丢失风险。

客户端配置示例

确保应用使用的 Redis 客户端库支持哨兵模式，并正确配置哨兵节点地址列表，而非仅配置主节点 IP。

Java (Jedis/Lettuce) 配置示例：

// Jedis Sentinel 配置
Set<String> sentinels = new HashSet<>();
sentinels.add("192.168.1.10:26379");
sentinels.add("192.168.1.11:26379");
sentinels.add("192.168.1.12:26379");
JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels, poolConfig, 3000, "password");

// Spring Boot Lettuce 配置 (application.yml)
spring:
  redis:
    sentinel:
      master: mymaster
      nodes:
        - 192.168.1.10:26379
        - 192.168.1.11:26379
        - 192.168.1.12:26379
    password: your_password
    timeout: 3000ms

Python (redis-py) 配置示例：

import redis

sentinels = [('192.168.1.10', 26379), ('192.168.1.11', 26379)]
sentinel = redis.sentinel.Sentinel(sentinels, socket_timeout=0.5)
master = sentinel.master_for('mymaster', socket_timeout=0.5, password='password')
slave = sentinel.slave_for('mymaster', socket_timeout=0.5, password='password')

部分客户端需要配置刷新拓扑的时间间隔，避免长期使用旧缓存导致连接旧主节点。

故障排查步骤

1. 检查哨兵集群状态
使用 SENTINEL masters 命令查看 flags 字段。如果显示 odown（客观下线）或 disconnected，说明哨兵认为主节点已故障。检查每个哨兵进程的 sentinel.log，搜索 +failover 或 +switch-master 关键词，确认是否有选举日志。

# 查看哨兵监控的主节点状态
redis-cli -p <sentinel-port> SENTINEL masters

# 查看特定主节点下的从节点信息
redis-cli -p <sentinel-port> SENTINEL slaves <master-name>

# 获取当前主节点地址
redis-cli -p <sentinel-port> SENTINEL get-master-addr-by-name <master-name>

2. 确认网络连通性
在每台哨兵服务器上 ping 其他哨兵 IP，确保端口（默认 26379）可达。防火墙规则或安全组配置错误是常见原因。如果存在网络分区，需优先修复网络，否则强制切换可能导致数据不一致。

3. 检查消息队列状态
切换期间需关注队列积压情况。对于 List 结构，使用 LLEN 检查长度；对于 Stream 结构，使用 XINFO STREAM 查看消费者组状态。确认消费者组是否正常切换到新主节点。

# 检查 List 队列长度
redis-cli LLEN queue_key

# 检查 Stream 消费者组信息
redis-cli XINFO STREAM stream_key
redis-cli XINFO GROUPS stream_key

4. 调整超时参数（谨慎操作）
如果网络波动频繁，可适当调整 down-after-milliseconds。默认值通常为 30000 毫秒，调小会加快判定但可能误判，调大则切换变慢。修改需在 sentinel.conf 中生效并重启哨兵进程。注意：调整前需结合监控确认网络波动情况，避免频繁误切换导致服务抖动。

切换验证与一致性检查

1. 观察主节点地址变化
执行 SENTINEL get-master-addr-by-name 命令，对比故障前后的 IP 地址是否变更。如果 IP 变了，说明服务端切换已完成。

2. 业务读写与消息消费测试
在应用侧执行写入操作，确认无报错。查看应用日志，确认没有大量连接拒绝（Connection Refused）或超时异常。对于消息队列，观察消费者是否正常拉取消息，是否有大量重试日志。

3. 消息一致性验证
切换完成后，核对消息处理状态。由于 Redis 异步复制，故障切换期间可能存在少量消息丢失。需检查业务日志确认是否有消息未处理。同时关注是否有重复消费，客户端重连机制可能导致消息被重复拉取。

常见风险与规避

1. 法定人数配置错误
如果配置了 3 个哨兵，quorum 设为 3，那么只要有 1 个哨兵宕机就无法切换。建议奇数部署，quorum 设为多数（如 3 个哨兵设 2）。

2. 客户端缓存未刷新
部分客户端在获取主节点地址后会缓存较长时间。切换后需等待缓存过期或重启应用才能连上新主节点。建议检查客户端库的拓扑刷新配置，设置合理的刷新间隔。

3. 消息丢失与重复消费
Redis 哨兵模式无法保证消息零丢失。主节点故障时，未同步到从节点的消息可能丢失。客户端重连也可能导致消息重复消费。业务侧需实现消息幂等性处理，重要场景建议配合持久化存储或事务机制。

4. 脑裂风险
在网络分区极端情况下，可能出现旧主节点恢复后与新区主节点并存。需配置 min-slaves-to-write 限制旧主写入，防止数据分裂。在消息队列场景下，脑裂可能导致消息被写入旧主而消费者连接新主，造成消息永久丢失。

参考来源

• Redis Official Documentation, "Sentinel", https://redis.io/docs/management/sentinel/
• Redis Official Documentation, "Sentinel configuration", https://redis.io/docs/management/sentinel/#sentinel-configuration