cluster-node-timeout 是 Redis Cluster 故障检测与转移的核心参数，决定 PFAIL 判定速度、FAIL 升级效率、从节点参选资格及整体切换耗时，需全集群统一配置并结合网络环境合理设置。

cluster-node-timeout 直接决定故障转移是否及时、是否误触发，是 Redis Cluster 高可用的“心跳节拍器”。

它控制主观下线（PFAIL）的判定速度

节点之间靠定期 ping/pong 通信维持连接。如果一个节点在 cluster-node-timeout 时间内没收到目标节点的响应，就把它标记为 PFAIL（可能失效）。这个值不是心跳间隔，而是“等多久才敢怀疑对方挂了”的容忍窗口。

• 设太小（如低于 5000ms），网络抖动或瞬时延迟就容易被误判为 PFAIL，多个节点接连被标 PFAIL，很快升级为 FAIL，引发不必要的选举和切换
• 设太大（如超过 15000ms），真宕机后要等很久才被发现，业务中断时间拉长
• 局域网建议 5000–8000ms；跨机房建议 12000–15000ms；容器环境不低于 8000ms

它影响客观下线（FAIL）的达成效率

只有当**超过半数的主节点**都标记某主节点为 PFAIL，才会升级为 FAIL 并启动故障转移。而 PFAIL 的产生节奏，完全由 cluster-node-timeout 控制。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 该值不一致会导致脑裂：部分节点已 PFAIL，另一些还在等，集群状态无法收敛
• 若设得太小，PFAIL 上报太快，但 cluster-node-timeout×2 时间内又收不齐足够投票（因网络不稳定或节点离线），旧报告过期，新报告不断生成，卡在“永远差一票”的状态
• 必须全节点配置一致，且修改后需重启或 SIGUSR1 重载，CONFIG SET 只临时生效

它间接约束从节点能否参选

从节点发起选举前，会检查自己复制进度是否达标——落后不能超过 cluster-slave-validity-factor × cluster-node-timeout（默认 10 × 当前值）。

• 比如 cluster-node-timeout 设为 6000ms，那允许最大落后 60 秒数据；设为 15000ms，则允许落后 150 秒
• 值越大，对从节点数据新鲜度要求越宽松，参选门槛降低；但同时意味着故障发现更慢
• 若集群写入压力大、复制延迟波动高，盲目调小该值可能导致所有从节点都因 offset 落后被拒之门外

它和故障转移耗时强相关

整个自动故障转移流程（从 PFAIL 到新主上线）通常在 1–2 倍 cluster-node-timeout 内完成。选举超时、投票等待、状态同步都围绕它展开。

• 生产中观察到的典型切换时间：设为 8000ms → 多数情况 1.5～3 秒内完成；设为 15000ms → 可能拖到 4～8 秒
• 扩缩容前建议临时调大该值，避免操作期间因网络波动触发误切换
• 需配合 tcp-keepalive 设置，防止中间网络设备断连导致假超时