cluster-node-timeout应设为网络p95延迟的2～3倍：局域网5000～8000ms，跨机房12000～15000ms，kubernetes环境不低于8000ms；须全节点配置一致，config set仅内存生效，持久化需改redis.conf并重启或发sigusr1。
cluster-node-timeout 设多少才算不误判也不迟钝
它不是心跳间隔，而是节点被标记为 pfail（主观下线）前的等待时长。设太小，网络抖动就触发误判；设太大，真挂了还得等很久才切换。默认 15000 毫秒在局域网里偏保守，实际应按真实网络延迟来定：
- 先用
redis-cli -c -h nodeA -p 6379 cluster nodes查各节点的ping-sent和pong-recv时间差，取 P95 延迟最高的那个值 - 再乘以 2～3 倍作为起点：局域网常见
5000～8000；跨机房建议12000～15000；Kubernetes 环境不低于8000 - 容器或 Service Mesh 场景下，别信“本地延迟低”，要测集群总线（
bus-port）的真实 RTT
CONFIG SET cluster-node-timeout 为什么改了像没改
因为 CONFIG SET 只改当前节点内存值，重启即丢。线上调参必须同步两件事：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 所有节点的
redis.conf中显式写入cluster-node-timeout 6000（不能只靠CONFIG REWRITE） - 逐节点执行
redis-cli -h x.x.x.x -p 6379 CONFIG SET cluster-node-timeout 6000，再立刻CONFIG GET cluster-node-timeout确认返回值 - 最终必须发
SIGUSR1或重启进程，否则旧nodes.conf仍含错误拓扑信息，集群状态会卡住
cluster-node-timeout 和客户端超时怎么配才不打架
两者错位是集群超时误报的隐形推手。比如 cluster-node-timeout 是 15000，但 Spring Boot 的 spring.redis.timeout 只有 2000，结果节点刚进 pfail 状态，客户端已经抛 RedisCommandTimeoutException 了。
- 客户端超时建议 ≥
cluster-node-timeout× 1.2，留出故障检测+重定向时间 - Lettuce 必须开自适应刷新：
spring.redis.lettuce.cluster.refresh.adaptive=true，否则 MOVED 重定向失败后还在死连旧地址 - 拓扑刷新周期别设太长：
spring.redis.lettuce.cluster.refresh.period=30000（30 秒），太长会导致切主后长期连错
扩缩容前 cluster-node-timeout 必须临时调大
扩容加节点、缩容删节点、或做 slot 迁移时，集群内部消息量激增，ping/pong 延迟容易毛刺。此时若 cluster-node-timeout 还卡在平时值，极易批量进入 fail? 状态，甚至引发脑裂。
- 操作前统一调高到原值的 1.5～2 倍（如从
6000改成10000），操作完成后再调回 - 同时检查
tcp-keepalive：确保内核net.ipv4.tcp_keepalive_time≥cluster-node-timeout，否则连接可能被中间设备静默断开 - 别忘了验证
cluster-announce-ip是真实出口 IP——如果这里还是127.0.0.1，再调 timeout 也没用
cluster-node-timeout 就只是个自我安慰的数字。
