2.2、RAFT选举算法

算法逻辑

raft 集群中的每个节点都可以根据集群运行的情况在三种状态间切换：follower, candidate 与 leader。Leader负责和客户端通信，然后向follower同步日志，follower 只从 leader 处获取日志。

在节点初始启动时，节点的 raft 状态机将处于 follower 状态并被设定一个 election timeout，如果在这一时间周期内没有收到来自 leader 的 heartbeat，节点将发起选举：节点在将自己的状态切换为 candidate 之后，向集群中其它 follower 节点发送请求，询问其是否选举自己成为 leader。当收到来自集群中过半数节点的接受投票后，节点即成为 leader，开始接收保存 client 的数据并向其它的 follower 节点同步日志。leader 节点依靠定时向 follower 发送 heartbeat 来保持其地位。任何时候如果其它 follower 在 election timeout 期间都没有收到来自 leader 的 heartbeat，同样会将自己的状态切换为 candidate 并发起选举。每成功选举一次，新 leader 的步进数都会比之前 leader 的步进数大1。

Raft一致性算法处理日志复制以保证强一致性。

---

follower 节点不可用

follower 节点不可用的情况相对容易解决。因为集群中的日志内容始终是从 leader 节点同步的，只要这一节点再次加入集群时重新从 leader 节点处复制日志即可。

---

leader 不可用

一般情况下，leader 节点定时发送 heartbeat 到 follower 节点。

由于某些异常导致 leader 不再发送 heartbeat ，或 follower 无法收到 heartbeat 。

当某一 follower 发生 election timeout 时，其状态变更为 candidate，并向其他 follower 发起投票。

当超过半数的 follower 接受投票后，这一节点将成为新的 leader，leader 的步进数加1并开始向 follower 同步日志。

当一段时间之后，如果之前的 leader 再次加入集群（脑裂），则两个 leader 比较彼此的步进数，步进数低的 leader 将切换自己的状态为 follower。

较早前 leader 中不一致的日志将被清除，并与现有 leader 中的日志保持一致。

 

转载自：https://www.backendcloud.cn/2017/11/12/raft-gossip/