在分布式系统中,分布式一致性是一个非常重要的概念,它是指分布式系统的各个服务器都保持一个统一的状态(数据)。但是在分布式系统中,通常由于网络,系统状态等原因会导致某些服务不可用或者不可靠。这就需要一种分布式一致性的协议来保证系统在某些服务失败的情况下仍然整体可用。
Raft协议是受到Paxos的影响而产生的,相对于Paxos而言,Raft协议更加简单易懂。我会在后面的博客里面专门详细介绍Paxos协议的具体内容。这里我们重点讨论Raft协议。
下面举个例子:
假如我们有一个单节点的服务节点A,这个单节点的服务只是用来存储一个字母。同时我们还有一个客户端向这个服务发起更新数据的请求。
对于单节点的分布式一致性来说,服务响应客户端的更新请求即可。但是当我们有多个服务节点的情况下会怎么样呢?
Raft协议就是保证多个服务器节点数据一致性的协议。
接下来我们看看Raft是怎么工作的。
Raft协议中,一个服务器的节点可以是以下三种状态中的任意一个:
所有的节点都是从Follower状态开始的。
如果Follower在一定的时间里面没有收到选举请求或者Leader节点的回复,Follower则会转变为Candidate。
Candidate会发送选举请求给所有的其他节点,收到选举请求的其他节点会反馈回Candidate,当Candidate收到的所有响应数目大于n/2 时,Candidate会认为绝大多数节点已经选我作为Leader了,这时候Candidate就会转变为Leader。接下来所有的数据变化都会经由Leader发起。
在Raft系统中,所有的数据变化都是以日志记录的形式添加到服务节点之中。服务节点会不断的读取日志记录,并将日志记录更新到服务节点的数据中。日志记录最开始的状态是uncommited, 更新之后状态则变为commited.
为了实现所有服务节点的一致性更新,步骤如下:
在Raft 协议中,有一个term的概念。term是一个选举周期,一个term周期只会产生一个Leader,term连续递增。
在Raft协议中,为了保证选举和数据更新的顺利进行,规定了两种类型的timeout:选举timeout和心跳timeout。
值得注意的是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开始并开启新一轮的选举,只到符合条件为止。
当系统进入到日志复制阶段,Leader节点会以心跳timeout的节奏向Follower节点发送日志记录,并且需要确保所有的节点都能够接受到完整的日志记录。