3节点Redis集群持续发生主节点切换问题该如何排查解决？

从提供的Sentinel日志可观测到集群故障切换频率极高（epoch已达3741），存在多次节点主观下线（+sdown）、客观下线（+odown）记录，核心原因可分为四类：

• 网络间歇性异常：日志明确记录IP1节点先进入主观下线状态，1分钟左右又退出主观下线，后续IP3节点也被判定为主观下线并快速升级为客观下线，说明Sentinel与Redis节点之间的网络存在丢包、抖动或者延迟突增的情况，心跳包无法按时送达触发下线判定。
• Sentinel阈值配置不合理：默认的down-after-milliseconds心跳超时阈值设置过小，轻微的网络波动就会触发节点下线判定；若failover-timeout配置过小也会导致故障转移操作频繁重试。
• Redis节点性能阻塞：主节点CPU、内存、磁盘IO资源占用过高，或者执行耗时命令、触发持久化操作时出现进程阻塞，无法及时响应Sentinel的心跳探测，被误判为下线。
• 节点时间不同步：多台服务器系统时间偏差过大，会干扰Sentinel的心跳计时逻辑，导致下线判定出现偏差。

• 排查修复网络问题：使用ping、mtr、tcpdump工具对Sentinel和Redis节点之间的内网链路进行长时间检测，定位丢包、延迟过高的根因并修复，确保节点之间内网延迟稳定在1ms以内，无持续丢包。
• 优化Sentinel配置参数：
  • 适当调大down-after-milliseconds参数，建议设置为10000_{30000（即10}30秒），降低网络波动带来的误判概率
  • 3节点Sentinel集群的quorum参数保持为2即可，兼顾可用性和判定准确性
  • 调大failover-timeout参数至60000（即60秒），避免频繁触发重复的故障转移操作
• 优化Redis节点运行性能：
  • 持续监控Redis节点的CPU、内存、磁盘IO使用率，避免节点所在服务器资源过载
  • 合理配置持久化策略，性能不足的主节点可关闭RDB/AOF持久化，统一由从节点执行持久化
  • 避免在线上环境执行keys *、大规模hgetall等耗时命令，防止Redis进程阻塞无法响应心跳
• 同步节点系统时间：所有Redis、Sentinel节点配置NTP时间同步服务，确保节点之间的系统时间偏差小于1秒。
• 开启Sentinel debug日志：调整Sentinel日志级别为debug，采集更详细的探测、判定日志，方便后续定位潜在异常。

内容的提问来源于stack exchange，提问作者Nitesh Kumar