目录

• 六、Raft
  • 单个 Candidate 的竞选
  • 多个 Candidate 竞选
  • 数据同步
• 参考

六、Raft

Raft 也是分布式一致性协议，主要是用来竞选主节点。

• Raft: Understandable Distributed Consensus

单个 Candidate 的竞选

有三种节点：Follower、Candidate 和 Leader。Leader 会周期性的发送心跳包给 Follower。每个 Follower 都设置了一个随机的竞选超时时间，一般为 150ms~300ms，如果在这个时间内没有收到 Leader 的心跳包，就会变成 Candidate，进入竞选阶段。

• 下图展示一个分布式系统的最初阶段，此时只有 Follower 没有 Leader。Node A 等待一个随机的竞选超时时间之后，没收到 Leader 发来的心跳包，因此进入竞选阶段。

• 此时 Node A 发送投票请求给其它所有节点。

• 其它节点会对请求进行回复，如果超过一半的节点回复了，那么该 Candidate 就会变成 Leader。

• 之后 Leader 会周期性地发送心跳包给 Follower，Follower 接收到心跳包，会重新开始计时。

多个 Candidate 竞选

• 如果有多个 Follower 成为 Candidate，并且所获得票数相同，那么就需要重新开始投票。例如下图中 Node B 和 Node D 都获得两票，需要重新开始投票。

• 由于每个节点设置的随机竞选超时时间不同，因此下一次再次出现多个 Candidate 并获得同样票数的概率很低。

数据同步

• 来自客户端的修改都会被传入 Leader。注意该修改还未被提交，只是写入日志中。

• Leader 会把修改复制到所有 Follower。

• Leader 会等待大多数的 Follower 也进行了修改，然后才将修改提交。

• 此时 Leader 会通知的所有 Follower 让它们也提交修改，此时所有节点的值达成一致。

参考

• 倪超. 从 Paxos 到 ZooKeeper : 分布式一致性原理与实践 [M]. 电子工业出版社, 2015.
• Distributed locks with Redis
• 浅谈分布式锁
• 基于 Zookeeper 的分布式锁
• 聊聊分布式事务，再说说解决方案
• 分布式系统的事务处理
• 深入理解分布式事务
• What is CAP theorem in distributed database system?
• NEAT ALGORITHMS - PAXOS
• Paxos By Example