Redis集群不自带自动故障转移，高可用由Sentinel承担；哨兵通过down-after-milliseconds（默认30秒）判定主观下线，需多哨兵共识触发客观下线与故障转移。
Redis 集群本身不自带自动故障转移能力，真正扛起高可用（HA）职责的是 Redis Sentinel。集群节点间的心跳和哨兵的心跳是两套独立机制，混用或误配会导致“以为活着，其实已挂”或“频繁误判、反复切换”。
sentinel down-after-milliseconds 是主观下线阈值，不是心跳间隔
这个配置项决定一个哨兵单方面认定主节点失效的时间上限，单位毫秒。它不控制 ping 发送频率（那是固定 1 秒），只影响判断逻辑：
- 哨兵每 1 秒向主节点发一次
PING，如果连续down-after-milliseconds毫秒没收到有效响应（如PONG、LOADING、MASTERDOWN），就标记为主观下线（SDOWN） - 默认值是
30000（30 秒），对多数生产环境偏保守；压测或低延迟场景可设为5000～10000 - 不能无限制调小：网络抖动、慢查询、
fork阻塞都可能造成短暂超时，设太小会引发误切 - 多个哨兵需达成共识才会触发客观下线（
ODOWN），所以该值要配合quorum使用
cluster-node-timeout 控制 Redis 集群节点间心跳失效判定
这是纯 Redis Cluster 模式（非哨兵）下的配置，仅在启用 cluster-enabled yes 时生效：
- 它定义集群中任意两个节点（master 或 slave）之间，多久没收到 pong 就认为对方失联
- 默认
15000毫秒（15 秒），必须大于节点间实际网络往返时间（RTT）的 2～3 倍 - 若设得太小（如
3000），跨机房部署时容易频繁触发迁移或槽位重分配 - 若设得太大（如
60000），节点真实宕机后，集群感知滞后，客户端可能持续往不可达节点发请求 - 修改后需重启节点或执行
CLUSTER SETCONFIGEPOCH+CLUSTER MEET手动同步（不热生效）
哨兵与集群共存时，心跳配置必须错开层级
很多团队同时启用 Sentinel 和 Cluster，但这是反模式——两者设计目标冲突，且心跳逻辑互相干扰：
-
Sentinel的down-after-milliseconds判定主节点是否存活 -
Cluster的cluster-node-timeout判定集群内节点是否在线 - 若你用
Cluster模式，就不该再部署 Sentinel；反之亦然 - 常见错误：在集群节点上额外启动哨兵进程，结果哨兵把某个 cluster slave 当成普通 slave 监控，导致误判主从关系
真正需要混合使用的场景极少，绝大多数情况应二选一：
- 单机房、强一致性要求 → 用
Sentinel+ 主从 - 多机房、水平扩展需求 → 用
Cluster模式，靠内部 gossip 和故障迁移
故障恢复速度取决于三个时间叠加，而非单一配置
一次完整故障转移耗时 ≈down-after-milliseconds（首个哨兵 SDOWN）
- 网络传播延迟（其他哨兵同步状态）
-
failover-timeout（默认 180000ms，即 3 分钟，含选举、复制、配置广播）
-
failover-timeout不是“最长等待时间”，而是整个 failover 流程的硬性截止时间；超时未完成则中止，需人工介入 - 如果你希望 10 秒内完成切换，
down-after-milliseconds至少设为7000，同时确保quorum≥ 2 且哨兵节点数 ≥ 3 - 最容易被忽略的一点：所有哨兵的
down-after-milliseconds必须完全一致，否则投票无法收敛
配置不一致比设错值更危险。
