共计 2299 个字符，预计需要花费 6 分钟才能阅读完成。
这篇文章主要介绍了如何理解分布式一致性 Raft 协议的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇如何理解分布式一致性 Raft 协议文章都会有所收获，下面我们一起来看看吧。
什么是分布式一致性
下面举个例子：
假如我们有一个单节点的服务节点 A，这个单节点的服务只是用来存储一个字母。同时我们还有一个客户端向这个服务发起更新数据的请求。
对于单节点的分布式一致性来说，服务响应客户端的更新请求即可。但是当我们有多个服务节点的情况下会怎么样呢？
Raft 协议就是保证多个服务器节点数据一致性的协议。
接下来我们看看 Raft 是怎么工作的。
Raft 协议中，一个服务器的节点可以是以下三种状态中的任意一个：
Follower 状态：跟随者，被动接收数据。我们用实心圆表示。
Candidate 状态：候选人，可以被选做 Leader。我们用实心圆 + 虚线边框表示。
Leader 状态：领导者，处理所有客户端交互，日志复制等，一般一次只有一个 Leader. 我们用实心圆 + 实线边框表示。
Leader 选举
所有的节点都是从 Follower 状态开始的。
如果 Follower 在一定的时间里面没有收到选举请求或者 Leader 节点的回复，Follower 则会转变为 Candidate。
Candidate 会发送选举请求给所有的其他节点，收到选举请求的其他节点会反馈回 Candidate，当 Candidate 收到的所有响应数目大于 n /2 时，Candidate 会认为绝大多数节点已经选我作为 Leader 了，这时候 Candidate 就会转变为 Leader。接下来所有的数据变化都会经由 Leader 发起。
日志复制流程
在 Raft 系统中，所有的数据变化都是以日志记录的形式添加到服务节点之中。服务节点会不断的读取日志记录，并将日志记录更新到服务节点的数据中。日志记录最开始的状态是 uncommited, 更新之后状态则变为 commited.
为了实现所有服务节点的一致性更新，步骤如下：
client 发送数据更改请求到 Leader
Leader 复制日志记录到 Follower 节点
Leader 等待大多数节点完成复制日志记录。
Leader 节点 commit 当前日志记录，并更新 Leader 节点的数据。
image.png
Leader 通知 Follower 节点该日志记录已经 commit.
Follower 节点 commit 该日志记录。
整个分布式系统实现了数据一致性。
term 选举周期
在 Raft 协议中，有一个 term 的概念。term 是一个选举周期，一个 term 周期只会产生一个 Leader，term 连续递增。
timeout
在 Raft 协议中，为了保证选举和数据更新的顺利进行，规定了两种类型的 timeout:
选举 timeout 和心跳 timeout。
选举和选举 timeout
每个 term 开始时，会重置选举 timeout。在一个 term 中，Follower 会等待 timeout 的时间，如果超出这个时间还没有得到其他节点的选举请求，Follower 会主动转变为 Candidate，并且 term+1，意味着开启了新的选举周期。
选举 timeout 是 150ms-300ms 之间的一个随机数，之所以随机产生 timeout，是为了避免同时产生多个 Candidate 的情况。
当 Follower 转变为 Candidate 之后，term 加 1，然后开始新一轮的选举。Candidate 首先会将自己的 Vote Count 加 1，然后发送请求选举的消息给其他节点。
接收节点首先会比较 term 的大小，如果自己的 term 小于 Candidate 的 term，则更新自己的 term 和 Candidate 的 term 保持一致，并重置 timeout。如果接收节点在这个 term 中还没有做任何选举，则会返回选举响应消息给 Candidate 节点。
Candidate 节点收到大部分节点的选举响应之后，会变成 Leader 节点。
一个选举周期完成，接下来 Leader 发送更新日志给 Follower 节点，进入日志更新阶段。
选举分裂
值得注意的是 Candidate 只有得到超出 n / 2 个节点的选举响应才能变为 Leader 节点。如果两个 Follower 节点同时变成 Candidate 节点，则会产生选举分裂的问题。
现在假设我们总共有 4 个节点，其中两个节点同时变成 Candidate 节点，并向其余两个节点发送选举请求：
节点 B，C 成为 Candidate 节点并行向节点 A，D 发送选举请求。
节点 A，D 分别响应节点 B，C 的请求，这时候两个 Candidate 节点由于得到的 Vote 都是 2，不满足大于 n / 2 的条件，则其不能转变为 Leader 节点，继续等待 timeout 至新的 term 开始并开启新一轮的选举，只到符合条件为止。
日志复制和心跳 timeout
当系统进入到日志复制阶段，Leader 节点会以心跳 timeout 的节奏向 Follower 节点发送日志记录，并且需要确保所有的节点都能够接受到完整的日志记录。
客户发送 set 5 给 Leader，在下一个心跳 timeout，Leader 将 set 5 的日志记录发给 Follower。
Leader 收到大部分节点的 ack 响应之后，commit 该日志记录。
Leader 通知 Client 已经提交该日志记录，同时通知 Follower 提交该日志记录。
关于“如何理解分布式一致性 Raft 协议”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“如何理解分布式一致性 Raft 协议”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道。
