导航：首页 > 服务器 >

如何理解分布式一致性Raft协议

发表于：2024-11-11 作者：千家信息网编辑

千家信息网最后更新 2024年11月11日，这篇文章主要介绍了如何理解分布式一致性Raft协议的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇如何理解分布式一致性Raft协议文章都会有所收获，下面我们一起来看看吧。什

千家信息网最后更新 2024年11月11日如何理解分布式一致性Raft协议

这篇文章主要介绍了如何理解分布式一致性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节点，进入日志更新阶段。