Raft算法

简介

        Raft 算法是一种通过对日志复制管理来达到集群节点一致性的算法。这个日志复制管理 发生在集群节点中的 Leader 与 Followers 之间。Raft 通过选举出的 Leader 节点负责管理日志 复制过程，以实现各个节点间数据的一致性。

角色、任期及角色转变

        在 Raft 中，节点有三种角色：

Leader：唯一负责处理客户端写请求的节点；也可以处理客户端读请求；同时负责日志 复制工作

Candidate：Leader 选举的候选人，其可能会成为 Leader。是一个选举中的过程角色

Follower：可以处理客户端读请求；负责同步来自于 Leader 的日志；当接收到其它 Cadidate 的投票请求后可以进行投票；当发现 Leader 挂了，其会转变为 Candidate 发起 Leader 选举。

leader 选举

（1） 我要选举

       若 follower 在心跳超时范围内没有接收到来自于 leader 的心跳，则认为 leader 挂了。此 时其首先会使其本地 term 增一。然后 follower 会完成以下步骤：

1.此时若接收到了其它 candidate 的投票请求，则会将选票投给这个 candidate

2.由 follower 转变为 candidate

3.若之前尚未投票，则向自己投一票  向其它节点发出投票请求，然后等待响应。

（2） 我要投票

follower 在接收到投票请求后，其会根据以下情况来判断是否投票：

1.发来投票请求的 candidate 的 term 不能小于我的 term

2.在我当前 term 内，我的选票还没有投出去

3.若接收到多个 candidate 的请求，我将采取 first-come-first-served 方式投票

（3） 等待响应

当一个 Candidate 发出投票请求后会等待其它节点的响应结果。这个响应结果可能有三 种情况： 1.收到过半选票，成为新的 leader。然后会将消息广播给所有其它节点，以告诉大家我是 新的 Leader 了

2.接收到别的 candidate 发来的新 leader 通知，比较了新 leader 的 term 并不比自己的 term 小，则自己转变为 follower

3.经过一段时间后，没有收到过半选票，也没有收到新 leader 通知，则重新发出选举

（4） 选举时机

 在很多时候，当 Leader 真的挂了，Follower 几乎同时会感知到，所以它们几乎同时会变 为 candidate 发起新的选举。此时就可能会出现较多 candidate 票数相同的情况，即无法选举 出 Leader。 为了防止这种情况的发生，Raft 算法其采用了 randomized election timeouts 策略来解决 这个问题。其会为这些 Follower 随机分配一个选举发起时间 election timeout，这个 timeout 在 150-300ms 范围内。只有到达了 election timeout 时间的 Follower 才能转变为 candidate， 否则等待。那么 election timeout 较小的 Follower 则会转变为 candidate 然后先发起选举，一 般情况下其会优先获取到过半选票成为新的 leader。

后续内容，关注博主私信访问~