Redis集群节点宕机如何处理？

Redis集群的故障转移并非简单依赖节点宕机即触发，而是基于严谨的多数派投票机制：仅当主节点失联且超过半数在线主节点共同确认其失效（FAIL状态）时，才会启动选举；从节点能否当选新主，不仅取决于是否率先发起请求，更关键的是复制偏移量是否足够接近原主、能否获得大多数主节点的有效投票，而整个过程高度受cluster-node-timeout和cluster-slave-validity-factor等核心参数联动影响——配置不当轻则导致转移卡在PFAIL、重则引发选举失败或写入中断，因此日常必须通过CLUSTER NODES、INFO replication及redis-cli --cluster check等命令主动验证拓扑健康度与从节点参选资格，切忌等到真实故障才暴露隐患。

Redis Cluster 故障转移靠什么触发

不是所有节点宕机都会立刻触发故障转移，关键看是不是主节点挂了，以及有没有足够多的主节点在线投票。Redis Cluster 用的是类 Raft 的多数派投票机制，但不依赖日志复制——它只对“某个主节点是否失联”这件事发起投票。

• cluster-node-timeout 是心跳超时阈值（默认 15000ms），从其他主节点视角，如果连续 cluster-node-timeout 没收到目标主节点的 PING/PONG 响应，就把它标记为 PFAIL（可能失效）
• 只有当**超过半数的主节点**（N/2 + 1，N 是当前在线主节点总数）都标记该主节点为 PFAIL，才会升级为 FAIL，并启动故障转移流程
• 注意：这里统计的是「主节点数量」，不是总节点数。比如 6 节点集群（3 主 3 从），只要 2 个主节点在线，就只需要其中 2 个都同意就能判 FAIL

从节点如何被选为新主节点

一旦原主节点被判定为 FAIL，它的从节点会尝试发起选举。能不能当选，不看谁先喊，而看谁能拿到大多数主节点的投票，且自身复制偏移量（replication offset）最接近原主节点。

• 从节点在发起选举前，会先检查自己的 slave-repl-offset 是否 >= 当前已知的最大偏移量（通过向其他节点发送 CLUSTER NODES 或 INFO replication 获取）；落后太多直接放弃
• 每个主节点在同一轮选举中只投一票，投给第一个收到合法 FAILOVER_AUTH_REQUEST 的从节点
• 选举超时由 cluster-node-timeout 控制，一般 1–2 秒内完成；失败则重试，最多尝试 cluster-slave-validity-factor × cluster-node-timeout 毫秒

为什么有时候故障转移卡住或失败

最常见的不是网络分区，而是配置或拓扑导致的“投票无法达成多数”。尤其是小规模集群或手动干预后状态混乱时。

• 集群中只剩 1 个主节点在线 → 无法凑够 N/2 + 1 票，永远卡在 PFAIL，不会升级 FAIL
• 从节点设置了 cluster-require-full-coverage no，但部分哈希槽（slot）没有主节点负责，整个集群会拒绝写入，但不影响故障转移本身
• 从节点与原主节点断连太久，slave-repl-offset 落后过多，且 cluster-slave-validity-factor 设得太小（默认 10），导致它连参选资格都没有
• 人为执行过 CLUSTER FAILOVER FORCE 或 CLUSTER FAILOVER TAKEOVER，可能让多个从节点同时发起选举，造成短暂脑裂（虽然后续能收敛）

怎么验证当前集群是否健康、能否正常故障转移

别等真挂了才查，日常用几条命令快速摸清底数。重点不是“有没有从节点”，而是“它们能不能被选上”。

• 运行 CLUSTER NODES，确认每组主从关系里，从节点状态是 slave 且 connected，并且 master 字段指向正确的主节点 ID
• 对每个从节点执行 INFO replication，检查 master_link_status:up 和 slave_repl_offset 是否持续增长
• 用 redis-cli --cluster check 检查槽分配和主从映射一致性；它会明确报出 “Not all 16384 slots are covered” 或 “Some slaves are not serving the same master” 这类硬伤
• 测试性模拟：停掉一个主节点，观察 30 秒内是否出现 fail? 变成 fail，再看对应从节点的 role 是否从 slave 变成 master

真正容易被忽略的，是 cluster-node-timeout 和 cluster-slave-validity-factor 这两个参数的联动效果：前者决定“多久算失联”，后者决定“落后多少就不能参选”。调得太激进，可能误切；太保守，又拖慢恢复。线上环境建议先在测试集群里用 DEBUG SLEEP 模拟延迟，再观察投票行为。

终于介绍完啦！小伙伴们，这篇关于《Redis集群节点宕机如何处理？》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布数据库相关知识，快来关注吧！