之前我们在学习“主从架构”时，为了实现故障转移，不得不额外引入了一套“哨兵 (Sentinel) 集群”。但是，当你搭建完分片集群后，你会惊讶地发现：分片集群不需要部署哨兵！
为什么它能“去中心化”地完成故障转移？在面试中，把这个过程讲清楚，绝对能让面试官对你刮目相看。
📚 高级篇 16. 分布式缓存 - 分片集群故障转移 (Failover)
一、 核心震撼：为什么分片集群不需要哨兵？
在 Redis Cluster 中，所有的 Master 节点本身就兼职了“哨兵”的工作。
集群采用了一种极其著名的去中心化网络协议——Gossip (流言) 协议。
你可以把它想象成办公室里的“八卦传播”。每个节点都会周期性地随机挑选几个其他节点，向它们发送 PING 消息，交流自己所知道的集群状态信息（谁还活着，谁的槽位变了，谁好像挂了）。一传十，十传百，整个集群的状态很快就能达成一致。
二、 自动故障转移：大哥“驾崩”的四个阶段
当某个 Master（比如节点 A）因为断电突然宕机时，集群内部会发生极其严密的四步排查与选主流程。你会发现，这个逻辑和我们之前学的哨兵机制非常相似，只是执行者变了：
1. 疑似宕机 (PFAIL - 主观下线)
- 节点 B 定期给节点 A 发送
PING，但过了设定的超时时间（cluster-node-timeout），节点 A 都没有回复PONG。 - 节点 B 会在自己的小本本上把节点 A 标记为
PFAIL(Possible Fail，疑似下线) 。
2. 确诊宕机 (FAIL - 客观下线) ⚡共识机制
- 节点 B 通过 Gossip 协议，把“A 好像挂了”这个八卦告诉了集群里的其他 Master（比如节点 C 和 D）。
- 如果集群中超过半数的 Master 都回复说：“我也连不上 A，我也把它标记为
PFAIL了”。 - 此时，大家达成共识！节点 A 的状态会被正式升级为
FAIL(确定下线) ，并且这个消息会瞬间广播给整个集群。
3. 小弟暴动 (发起选举)
- 节点 A 的几个 Slave 小弟收到了大哥
FAIL的广播，意识到自己该上位了。 - 防冲突机制（休眠等待）： 为了防止所有小弟同时跳出来抢皇位，每个小弟会根据自己的数据新鲜度（
offset偏移量）计算一个随机的延迟时间。offset越大的小弟（数据最新），延迟时间越短，就能越早跳出来拉票。 - 最先醒来的小弟，会向集群中所有的存活 Master 发起拉票请求。
4. 登基新皇 (接管哈希槽)
- 存活的 Master 们（B, C, D）收到拉票请求后，会进行投票。只要这个小弟获得了超过半数 Master 的同意票，选举成功！
- 接管权力： 新当选的小弟会立刻执行
slaveof no one变成 Master，并且无缝继承老大哥留下的所有哈希槽。 - 昭告天下： 新 Master 会向全网广播一条
PONG消息，宣告：“时代变了，现在这部分哈希槽归我管了！”
三、 高阶实操：手动故障转移 (平滑演练)
自动故障转移通常是被动的（机器坏了）。但在真实的运维场景中，我们经常需要主动进行故障转移。
场景： 节点 A 是 Master，它的物理服务器硬盘老化了，你需要把它下线维修。如果你直接强制关机，会触发上面的自动转移流程，在此期间（发现宕机 -> 选举 -> 切换），这部分哈希槽的服务会短暂中断。
为了实现用户零感知的平滑切换，Redis 提供了手动转移命令：
操作步骤：
- 登录到节点 A 的某个从节点（比如节点 A-Slave）的终端里。
- 执行命令：
CLUSTER FAILOVER。
底层平滑逻辑（面试亮点）：
- 收到命令后，A-Slave 会立刻告诉老大哥 A：“停止接收任何客户端的写请求！ ”
- A-Slave 开始疯狂拉取大哥 A 此时此刻最新的数据（对齐
offset），确保连 1 个字节的误差都没有。 - 数据完全一致后，A-Slave 华丽转身变成 Master，接管哈希槽。老大哥 A 降级变成 Slave。
- 新 Master 开始接收客户端的请求。
总结： 手动
FAILOVER是极其安全的，它通过短暂阻塞老节点的写操作，确保了数据 100% 零丢失 且转移过程极其平滑。
学习总结
至此，你已经完全看透了分片集群高可用运作的本质。
通过 Gossip 协议代替哨兵进行心跳监控，通过半数投票机制防止脑裂，通过 cluster failover 实现极其优雅的平滑维护。这是目前缓存领域最顶级的容灾架构设计。
