共识算法Raft为什么这么流行，及原理解析( 二 ) _共识算法

文章插图

文章插图

4个节点的选主过程和5个节点的类似，在选出一个新的 Leader 后，原来的 Leader 恢复了又重新加入了，这个时候怎么处理？在 Raft 里，第几轮选举是有记录的，重新加入的 Leader 是第一轮选举 (Term 1) 选出来的，而现在的 Leader 则是 Term 2，所有原来的 Leader 会自觉降级为 Follower

文章插图

2.3 多个 Candidate 情况下的选主

文章插图

假设一开始有4个节点，都还是 Follower 。

文章插图

有两个 Follower 同时 Timeout，都变成了 Candidate 开始选举，分别给一个 Follower 发送了投票请求。

文章插图

两个 Follower 分别返回了ok，这时两个 Candidate 都只有2票，要3票才能被选成 Leader 。

文章插图

两个 Candidate 会分别给另外一个还没有给自己投票的 Follower 发送投票请求。

文章插图

但是因为 Follower 在这一轮选举中，都已经投完票了，所以都拒绝了他们的请求。所以在 Term 2 没有 Leader 被选出来。

文章插图

这时，两个节点的状态是 Candidate，两个是 Follower，但是他们的倒计时器仍然在运行，最先 Timeout 的那个节点会进行发起新一轮 Term 3 的投票。

文章插图

两个 Follower 在 Term 3 还没投过票，所以返回 OK，这时 Candidate 一共有三票，被选为了 Leader 。

文章插图

如果 Leader Heartbeat 的时间晚于另外一个 Candidate timeout 的时间，另外一个 Candidate 仍然会发送选举请求。

文章插图

两个 Follower 已经投完票了，拒绝了这个 Candidate 的投票请求。

文章插图

Leader 进行 Heartbeat，Candidate 收到后状态自动转为 Follower，完成选主。
以上是 Raft 最重要活动之一选主的介绍，以及在不同情况下如何进行选主。
3. 复制日志 Log Replication3.1 正常情况下复制日志Raft 在实际应用场景中的一致性更多的是体现在不同节点之间的数据一致性，客户端发送请求到任何一个节点都能收到一致的返回，当一个节点出故障后，其他节点仍然能以已有的数据正常进行。在选主之后的复制日志就是为了达到这个目的。

文章插图

一开始，Leader 和两个 Follower 都没有任何数据。

文章插图

客户端发送请求给 Leader，储存数据 “sally”，Leader 先将数据写在本地日志，这时候数据还是 Uncommitted (还没最终确认，红色表示)

文章插图

Leader 给两个 Follower 发送 AppendEntries 请求，数据在 Follower 上没有冲突，则将数据暂时写在本地日志，Follower 的数据也还是 Uncommitted 。

文章插图

Follower 将数据写到本地后，返回 OK 。Leader 收到后成功返回，只要收到的成功的返回数量超过半数 (包含Leader)，Leader 将数据 “sally” 的状态改成 Committed 。( 这个时候 Leader 就可以返回给客户端了)

文章插图

Leader 再次给 Follower 发送 AppendEntries 请求，收到请求后，Follower 将本地日志里 Uncommitted 数据改成 Committed 。这样就完成了一整个复制日志的过程，三个节点的数据是一致的
3.2 Network Partition 情况下进行复制日志在 Network Partition 的情况下，部分节点之间没办法互相通信，Raft 也能保证在这种情况下数据的一致性。