RAFT

角色

  • Leader（领袖）
  • Follower（群众）
  • Candidate（候选人）

Raft 协议将 Server 进程分成三类，分别是 Leader，Candidate，Follower。一个 Server 进程在某一时刻，只能是其中 一种类型，但这不是固定的。不同的时刻，它可能拥有不同的类型

leader选举

  • 多数票的可以直接选出。
  • 如果每方都投给了自己，结果没有任何一方获得多数票。之后 每个参与方 随机休息（Election Timeout），然后重新发起投票。最先从 timeout 中恢复发起投票的一方可以投自己。

选出 Leader 后，Leader 通过 定期 向所有 Follower 发送 心跳信息 维持其统治。若 Follower 一段时间未收到 Leader 的 心跳，则认为 Leader 可能已经挂了，然后再次发起 选举 过程。

一致性

Raft 协议 强依赖 Leader 节点的 可用性，以确保集群 数据的一致性。数据的流向 只能从 Leader 节点向 Follower 节点转移。

  1. 当 Client 向集群 Leader 节点 提交数据 后，Leader 节点 接收到的数据 处于 未提交状态（Uncommitted）。
  2. 接着 Leader 节点会 并发地 向所有 Follower 节点 复制数据 并 等待接收响应。
  3. 集群中至少 超过半数 的节点 已接收 到数据后， Leader 再向 Client 确认数据 已接收。
  4. 一旦向 Client 发出数据接收 Ack 响应后，表明此时 数据状态 进入 已提交（Committed），Leader 节点再向 Follower 节点发通知告知该 数据状态已提交。

脑裂

网络分区 将原先的 Leader 节点和 Follower 节点分隔开，Follower 收不到 Leader 的 心跳将 重新 发起选举产生新的 Leader，这时就产生了 双Leader 现象。

  • 原先的 Leader 独自在一个区，向它提交数据不可能复制到多数节点所以永远提交不成功。向新的 Leader 提交数据可以提交成功。
  • 网络恢复 后，旧的 Leader 发现集群中有 更新任期（Term）的新 Leader ，则 自动降级 为 Follower 。如果有未提交的数据则回滚，并从新 Leader 处 同步数据 达成集群 数据一致。