redis cluster不依赖哨兵，其自动故障转移由内置gossip协议和多数派投票驱动；加哨兵反而导致误判、地址错误或脑裂。关键参数包括cluster-node-timeout、cluster-require-full-coverage和cluster-slave-validity-factor。
Redis Cluster 不依赖哨兵机制，这是关键前提。你看到的自动故障转移，完全由集群内置的 Gossip 协议和多数派投票驱动，Sentinel 在 Cluster 模式下是冗余甚至冲突的组件。
为什么加哨兵反而会坏事？
哨兵（Sentinel）和 Redis Cluster 是两套互斥的高可用方案：
– Sentinel 适用于单分片主从架构，靠外部监控节点做决策；
– Cluster 是去中心化设计，所有节点自己参与心跳、投票、升主。
如果你在 Cluster 集群里额外部署 Sentinel：
• 它无法理解哈希槽（slot）分配，对故障范围判断失真；
• 可能向客户端返回错误的主节点地址（比如指向已下线但未被 Cluster 清理的旧主）；
• Sentinel 的 failover 操作会干扰 Cluster 自身的选举流程，导致短暂脑裂或拒绝服务。
真正起作用的是哪几个配置项？
故障能否顺利转移，不看有没有哨兵，而取决于这几个核心参数是否合理：
• cluster-node-timeout：默认 15000 ms，它决定“多久没响应就怀疑挂了”。太小（如 3000）易在网络抖动时误标 PFAIL；太大（如 60000）会导致恢复延迟；生产建议设为 8000–12000，并结合跨机房 RT 调整。
• cluster-require-full-coverage：默认 yes。一旦任一哈希槽无主节点，整个集群拒绝写入（报 CLUSTERDOWN）。线上必须设为 no，否则单个分片故障会拖垮全局。
• cluster-slave-validity-factor：默认 10，配合 cluster-node-timeout 计算从节点参选资格上限（10 × timeout）。若从节点断连超该值，直接失去竞选资格——这点常被忽略，尤其在主从复制延迟高的场景。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
怎么确认故障转移真的能跑通？
别等出事才验证。日常用这几条命令摸清底数：
• redis-cli -c -p <port> cluster nodes</port>：检查是否有节点标记为 fail? 或 fail，重点关注主节点状态和其从节点的 slave-repl-offset 值；
• redis-cli -p <slave_port> info replication | grep offset</slave_port>：比对从节点 slave_repl_offset 和原主节点宕机前的 master_repl_offset（可从日志或历史 INFO replication 获取），差值超过 min-replicas-max-lag（默认 10 秒）可能被跳过；
• redis-cli -p <any_port> cluster slots</any_port>：确认所有 16384 个槽是否都被分配，且每个槽都有明确主节点（不是 null 或空行）；
• 手动模拟：停掉一个主节点后，观察 30 秒内对应从节点是否从 slave 变成 master，且 cluster nodes 中该节点角色字段更新、flags 加上 master 标识。
最常卡住的三个真实原因
故障转移失败，90% 不是协议问题，而是状态或配置堵在半路：
• 存活主节点数不足法定多数：比如 3 主集群，只剩 1 个主在线 → 无法凑够 ⌊N/2⌋+1 = 2 票，永远卡在 PFAIL；
• 从节点 replica-priority 设为 0：显式禁止升主，哪怕它数据最新；
• cluster-enabled yes 没开全：某个节点配置漏了这行，它就无法参与 Gossip，也无法被投票——这种节点在 cluster nodes 输出里会显示为 noflags 或缺少 master/slave 标识。
实际运维中，真正难的不是理解流程，而是当 cluster nodes 里一堆 fail? 却没人升主时，得快速定位是网络分区、参数阈值卡死，还是某个从节点悄悄被 replica-priority 0 给静音了。
