Redis集群主从频繁自动故障转移问题排查与配置咨询

首先，你的集群配置与部署方式存在明显的不合理之处，正是这些问题直接导致了频繁故障转移和后续的CPU异常情况，下面逐一拆解并给出修复建议：

当前配置与部署的核心问题 #

1. 极端集中的部署架构埋下单点隐患 #

你把所有4个Master实例集中在一台物理机，所有Slave集中在另一台，这相当于把整个集群的主从依赖完全绑定在两台机器之间的网络链路上。只要这条链路出现短暂抖动、丢包甚至几秒中断，所有Slave都会同时与对应Master失联，直接触发大规模自动故障转移——这就是你看到“服务器正常却频繁故障转移”的根本原因。

2. 超时配置不合理，易触发误判 #

从你的集群配置来看：

• cluster-node-timeout 设置为15秒，这个值对于跨主机集群来说偏短，网络环境稍有波动就会触发节点超时判定。
• cluster-slave-validity-factor 设为10，意味着Slave要等150秒才会确认Master真的失效，但如果网络中断刚好卡在这个时间范围内，就会反复触发故障转移的判定逻辑。
• cluster-require-full-coverage 设为yes，这个配置会让集群在任何槽位未被覆盖时直接停止对外服务，故障转移期间很容易导致客户端大面积断开连接。

3. Slave主机资源储备不足，故障转移后过载 #

原来的Slave主机仅运行Slave实例，资源占用极低；一旦故障转移发生，4个Slave瞬间切换为Master，要承担所有读写流量，还要处理可能的反向复制（原Master恢复后变为Slave，需同步新Master的数据），CPU直接被打满，自然会抛出异常导致客户端断开。

具体修复措施 #

按优先级排序，先解决最核心的问题：

1. 重构集群部署架构，消除单点风险 #

立刻调整实例分布，不要把所有Master或Slave集中在同一台机器：

• 建议两台机器各部署2个Master和2个Slave，每个Master的Slave放在另一台机器上（比如机器A放Master1、Master2、Slave3、Slave4；机器B放Master3、Master4、Slave1、Slave2）。这样即使两台机器之间网络出问题，也只会影响一半的主从对，不会触发全集群的故障转移。
• 如果有更多主机，最好把每个Master和它的Slave分散到不同的物理节点，进一步降低风险。

2. 调整集群超时配置，减少误触发 #

修改Redis集群的配置参数：

• 把cluster-node-timeout从15秒调高到30秒（cluster-node-timeout 30000），给网络抖动留出足够的缓冲时间，减少不必要的超时判定。
• 调整cluster-slave-validity-factor到5（cluster-slave-validity-factor 5），这样Slave会在150秒（30*5）后才确认Master失效，过滤掉大部分短暂的网络中断。
• 关闭cluster-require-full-coverage（cluster-require-full-coverage no），这样即使集群有部分槽位暂时不可用，其他正常的槽位仍能对外服务，避免故障转移期间全集群瘫痪。

3. 升级Slave主机资源，缓解CPU压力 #

• 检查Slave主机的CPU负载，故障转移后4个Master实例的CPU占用是否超过了主机的承载上限。如果是，要么升级主机的CPU配置，要么减少单台机器上的Redis实例数量（比如把部分实例迁移到其他主机）。
• 优化Redis实例的配置：比如调整持久化策略（减少不必要的RDB快照生成频率）、关闭一些非必要的统计功能，降低CPU消耗。

4. 排查并修复两台主机之间的网络问题 #

这是根源问题之一，一定要排查：

• 使用ping、mtr等工具持续监测两台机器之间的网络质量，看是否存在频繁丢包、延迟过高的情况。
• 联系运维团队检查网络链路、交换机或防火墙配置，修复潜在的网络故障。

5. 部署集群监控，提前预警 #

搭建Redis集群监控系统（比如用Prometheus+Grafana），实时跟踪节点状态、网络延迟、CPU使用率、槽位分布等指标，提前发现异常并处理，避免故障扩大。

内容的提问来源于stack exchange，提问作者Parth Gandhi