故障判定的时间基准
cluster-node-timeout 决定集群里多久收不到某个节点消息就认为它可疑：超过这个时长未收到对方消息，就把它标记为疑似下线，再由其他主节点确认、多数派达成一致后升级为确定下线，触发其从节点竞选。它同时参与判断某个从节点是否因为断链过久而失去被提升的资格。
基本信息
| 默认值 | 15000 毫秒 |
|---|---|
| 作用 | 故障发现节奏、以及从节点提升资格判定 |
| 相关参数 | cluster-replica-validity-factor，与超时值相乘得到从节点断链上限 |
| 生效要求 | 全集群节点取值应保持一致 |
典型使用场景
- 估算恢复时间：从节点失联到触发提升的耗时是这个值的函数
- 跨机房部署调参：链路抖动大时需要放大，避免抖动被当作故障
- 排查误切：短时间内反复发生切换，先核对本参数与链路质量
- 评估从节点资格：断链太久的从节点不会被提升，需要与数据同步能力一起看
查看与调整
查看与调整
redis-cli -p 7000 CONFIG GET cluster-node-timeout # 查看当前值（毫秒）
redis-cli -p 7000 CONFIG SET cluster-node-timeout 30000 # 跨机房时适当放大
redis-cli -p 7000 CLUSTER NODES | grep -E 'fail|pfail' # 是否有节点被标记
redis-cli -p 7000 CLUSTER INFO | grep -E 'state|slots_fail' # 集群整体状态
redis-cli -p 7000 CLUSTER FAILOVER # 需要主动切换时不必等超时取值建议
| 场景 | 取值取向 | 理由 |
|---|---|---|
| 同机房内网 | 可沿用默认 15000 | 链路抖动小，误判概率低 |
| 跨机房或跨云 | 放大到 20000 到 30000 | 容忍链路抖动与临时丢包 |
| 要求快速切换 | 谨慎调小，例如 5000 到 8000 | 切换更快但误判风险上升，需先在真实链路验证 |
| 链路质量不稳定 | 不要盲目调小 | 反复判定下线会引发无谓提升与数据回退 |
从节点能否被提升还受 cluster-replica-validity-factor 约束：它与 node-timeout 相乘，得到从节点与主库断链多久后就失去提升资格的上限，因子为 0 表示忽略这项检查、任何从节点都可参与竞选。
它与 cluster-require-full-coverage 是两个维度：前者管多久判定节点故障，后者管有槽没有归属时整个集群是否停止服务（默认停止）。排障时不要混为一谈，集群整体不可用往往查的是后者。
抖动引发的误判会带来实际损失：原主恢复后会发现自己的槽已被接管，它会清空自身数据并转为从库重新同步，期间写入的那部分数据可能永久丢失。