Redis集群节点故障处理指南

Redis集群节点宕机后的自动恢复并非“开箱即用”的简单切换，其成败取决于主从角色、在线主节点数量、从节点数据新鲜度及配置参数（如cluster-node-timeout）的精准调优；生产中常见误判、选举失败、混合部署冲突和拓扑未刷新等隐性陷阱，往往导致服务看似恢复实则部分槽位失联、写入被拒，甚至引发雪崩式延迟毛刺——真正可靠的高可用，源于对故障检测机制、参选资格逻辑与客户端协同行为的深度理解与主动验证。

Redis集群节点宕机是否自动恢复，取决于它是不是主节点、有没有足够多的主节点在线投票，以及从节点是否满足参选资格——不是所有宕机都会触发转移，更不是宕机后立刻切换。

cluster-node-timeout设太小会导致误判PFAIL

这个参数是故障检测的起点，默认 15000ms。如果网络抖动频繁或延迟高，把它调到 5000ms 以下，节点可能刚卡顿 3 秒就被标记为 PFAIL，多个主节点陆续标记后迅速升级为 FAIL，引发不必要的选举。

• 生产环境建议设为 8000–12000ms，需结合实际 RTT 和 PING/PONG 延迟测试调整
• 修改后必须重启节点（cluster-node-timeout 是启动时加载的配置，运行中不可动态改）
• 用 redis-cli -c -p 6379 cluster nodes 查看各节点标记状态，确认是否有大量 fail? 或 fail 标识

从节点无法当选新主的三个常见原因

即使主节点被判定为 FAIL，从节点也可能“有资格参选”但“没票当选”，或干脆连参选门槛都过不去。

• slave-repl-offset 落后太多：从节点会对比自己和已知最大偏移量，差值超过 cluster-slave-validity-factor × cluster-node-timeout（默认 10 × 15000 = 150 秒数据）就放弃参选
• 没收到足够投票：每个主节点每轮只投一票，且只投给第一个合法的 FAILOVER_AUTH_REQUEST；若多个从节点几乎同时发起请求，后到的直接失败
• 集群主节点数不足：比如 3 主 3 从集群，挂掉 2 个主节点后只剩 1 个主在线，无法凑够 N/2 + 1 = 2 票，故障转移卡死

Redis Sentinel 和 Redis Cluster 的故障转移不能混用

这是最容易踩的架构级坑：Sentinel 管理的是单分片主从拓扑，Cluster 自带去中心化故障转移能力。两者共存会导致行为冲突。

• 在启用 cluster-enabled yes 的节点上配 Sentinel，Sentinel 会忽略其集群角色，仍按传统主从方式尝试 SENTINEL failover，可能强制 replicaof no one 破坏集群结构
• 用 redis-cli --cluster check 能发现不一致的配置，比如某节点显示 connected 但 role=master 下标着 fail，实际却是 Sentinel 在后台偷偷切主
• 判断依据很简单：查 INFO replication 输出里有没有 role:master + cluster_enabled:1 同时存在；若有，说明你正在混合部署，必须二选一

验证故障转移是否真可用，别等宕机才试

日常巡检时，光看 CLUSTER NODES 输出里有没有 slave 不够，得确认它们能不能在秒级内顶上来。

• 手动模拟：对目标主节点执行 redis-cli -p 6380 DEBUG sleep 20（比 cluster-node-timeout 长），观察其余主节点日志是否出现 MARKASFAIL 和 failover 字样
• 检查新主是否真正接管：用 redis-cli -c -p 6379 cluster nodes 看原从节点 role 是否变成 master，且槽位（slots）已继承
• 关键但常被忽略：确认客户端连接池是否刷新了拓扑——JedisCluster 默认 60 秒拉一次 CLUSTER SLOTS，期间发往旧地址的请求会报 MOVED，不是失败，但会影响延迟毛刺

最麻烦的不是宕机本身，而是“看起来恢复了，但部分 slot 没主节点负责”，此时 cluster-require-full-coverage yes（默认）会让整个集群拒绝写入，而错误信息只在客户端抛 ClusterDownException，服务端日志里却只有零星的 Not covered 提示。

今天关于《Redis集群节点故障处理指南》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！