一致性协议-RAFT简述

Posted 2021-05-25 Exception

    在一个分布式系统中通常会提到CAP定理，这里的C讲的就是线性一致性。根据不同场景通常一致性有三种描述：强一致性（线性一致性）、弱一致性、最终一致性。RAFT是强一致性的代表、而ZAB协议主要保证最终一致性，当然以上保证的都是CP特性。

01

—

Paxos

    一致性协议有很多，如ZAB、raft、multi-paxos、VR等这些被称之为Leader-based一致性协议，它们都是由经典的paxos算法优化发展而来。Paxos通过对多个提案进行表决，从中选定一个提案作为最终的共识，并且一旦这个提案被选定之后，结果不会再发生改变。参与表决的角色有Proposer（主动发起请求）与Acceptor（被动响应请求），Learner只关注表决结果，不参与表决过程。由于paxos很复杂，这里只简单说下关键的名词：

提案：每个提案[n,v]由两部分组成：

     n : 提案被提出的顺序

    v : 提案的值

角色：每个进程都能够同时担任以下角色中的一个或多个

     提议者Proposer：主动发起提案

    决策者Acceptor：对提案进行表决

    提议者Learner：被动接受表决结果

提案状态：每个提案可能处于以下3个状态之一

     提出prepare：被某个 Proposer 提出

    通过accept：被某个 Acceptor 通过

    选定chosen：被半数以上 Acceptor 通过

02

—

Raft

    Raft是一个强leader的共识性算法，是Paxos的简化。一个节点可以有以下三种角色中的一种：

追随者 Follower  ：所有节点都 以follower状态启动，如果没有收到leader的消息则会变成candidate

候选人Candidate ：主动发起投票，如果得到大部分的选票则变成leader

领导者Leader :系统的所有修改都需要经过leader

     任期(Term)：Raft算法将时间划分成任意长度的任期，用连续的数字表示，每一个任期开始代表一次选举。

     日志： Paxos叫提案，Raft叫日志。以下是一个简单的过程描述 ：

    1）每个更改都作为一个entry添加到节点的日志中。当leader收到一个修改请求，日志的entry为未提交状态，不会更新节点的值，要提交则该节点必须将其复制到follower；

    2）leader开始等待到当大部分节点都写入entry，entry被提交到leader节点，该节点状态变更；

    3）然后leader通知followers该entry已提交；

    4）集群中的节点现在已经对系统状态达成共识；

     下面是官网对选举和日志拷贝过程的一些描述。

选举

在Raft中有两个控制选举的超时时间。前面我们说到最开始所有节点都以follower启动，当启动等待一定时间(150~300ms)后节点A会变成candidate(term+1)；

首先该候选人A会给自己投票，然后会向其他节点(B、C)发起投票请求；

如果其他节点还未投票(自己的term<=候选人的term)，会投票给候选人A(term+1);

候选人A获得大多数投票(N/2+1)便成为leader；

此后leader就可以给followers发送Append Entries等指令；

leader通过心跳方式进行日志复制通知，followers响应每一个Append Entries；

     

这个选举的任期将持续到当A节点不可用，某一个follower停止接受心跳并成为下一个候选人；

如此往复，以上是leader选举过程。

日志拷贝

当leader收到客户端对系统更改的请求，leader通过心跳使用相同的Append Entries消息来完成；

首先，leader记录该变更到自己节点的日志中，然后在下次心跳将更改发送给followers；

当一个entry被过半节点认可，该变更会被提交并响应给客户端；

以上是一个变更通过日志拷贝的方式同步到其他节点。

    当然，选举和日志拷贝远没那么简单。还涉及到如何保证安全性、选举限制、延迟提交、脑裂、状态机复制等，Raft又是如何规定和解决的呢？

---

(图文来源于网络搜集，如有侵权请联系小编删除。)