Hands-On Hyperledger Fabric——Raft共识算法

文章目录

  • 分布式系统的Raft算法
    • 选举过程
    • 数据同步过程

本文参考Raft算法实现动画。

在fabric1.4.1的版本中,提供了基于raft共识的raft排序服务。raft的模型可以容忍奔溃,如果有节点故障掉线可以正常运行。前提是要有大多数存活,也就是要保证1/2以上的节点个数正常运行。raft共识是“主从模型”,主节点通过动态选举决定,从节点是主节点的复制。raft排序服务比kafka排序服务易于设置和管理。并且raft的设计允许不同的组织贡献节点来共同组成排序服务。

kafka和zookeeper的设计不适用于大型网络。它们的设计是CFT模型,但局限于运行的比较紧密的主机上。也就是说,需要有一个组织专门运行kafka集群如果使用raft,每个组织可以贡献排序节点,共同组成排序服务,可以更好的去中心化

分布式系统的Raft算法

过去, Paxos一直是分布式协议的标准,但是Paxos难于理解,更难以实现,Google的分布式锁系统Chubby作为Paxos实现曾经遭遇到很多坑。

来自Stanford的新的分布式协议研究称为Raft,它是一个为真实世界应用建立的协议,主要注重协议的落地性和可理解性。

为了以容错方式达成一致,我们不可能要求所有服务器100%都达成一致状态,只要超过半数的大多数服务器达成一致就可以了,假设有N台服务器,N/2 +1 就超过半数,代表大多数了。

Paxos和Raft都是为了实现一致性共识这个目标,这个过程如同选举一样,参选者需要说服大多数选民(服务器)投票给他,一旦选定后就跟随其操作。Paxos和Raft的区别在于选举的具体过程不同。

在Raft中,任何时候一个服务器可以扮演下面角色之一:

  • Leader: 处理所有客户端交互,日志复制等,一般一次只有一个Leader。
  • Follower: 类似选民,完全被动。
  • Candidate: 候选者,可以被选为一个新的领导人。

Raft阶段分为两个首先是选举过程然后是数据同步过程(在选举出来的领导人带领进行正常操作,比如日志复制等)。

选举过程

下面用图示展示这个过程:

  1. 任何一个服务器都可以成为一个候选者Candidate,它向其他服务器Follower发出要求选举自己的请求
    Hands-On Hyperledger Fabric——Raft共识算法_第1张图片2. 其他服务器同意了,发出OK。
    Hands-On Hyperledger Fabric——Raft共识算法_第2张图片
    注意如果在这个过程中,有一个Follower当机,没有收到请求选举的要求,因此候选者可以自己选自己,只要达到N/2 + 1 的大多数票,候选人还是可以成为Leader的。

  2. 这样这个候选者就成为了Leader领导人,它可以向选民也就是Follower们发出指令,比如进行日志复制。

Hands-On Hyperledger Fabric——Raft共识算法_第3张图片

  1. 以后通过心跳进行日志复制的通知

Hands-On Hyperledger Fabric——Raft共识算法_第4张图片

  1. 如果一旦这个Leader当机崩溃了,那么Follower中有一个成为候选者,发出邀票选举。
    Hands-On Hyperledger Fabric——Raft共识算法_第5张图片

  2. Follower同意后,其成为Leader,继续承担日志复制等指导工作:

Hands-On Hyperledger Fabric——Raft共识算法_第6张图片

值得注意的是,整个选举过程是有一个时间限制的,如下图:

Hands-On Hyperledger Fabric——Raft共识算法_第7张图片

Splite Vote是因为如果同时有两个候选人向大家邀票,这时通过类似加时赛来解决,两个候选者在一段timeout比如300ms互相不服气的等待以后,因为双方得到的票数是一样的,一半对一半,那么在300ms以后,再由这两个候选者发出邀票,这时同时的概率大大降低,那么首先发出邀票的的候选者得到了大多数同意,成为领导者Leader,而另外一个候选者后来发出邀票时,那些Follower选民已经投票给第一个候选者,不能再投票给它,它就成为落选者了,最后这个落选者也成为普通Follower一员了。

数据同步过程

下面以日志复制为例子说明Raft算法,假设Leader领导人已经选出,这时客户端发出增加一个日志的要求,比如日志是"sally":
Hands-On Hyperledger Fabric——Raft共识算法_第8张图片

  1. Leader要求Follower遵从他的指令,都将这个新的日志内容追加到他们各自日志中:

Hands-On Hyperledger Fabric——Raft共识算法_第9张图片

  1. 大多数follower服务器将日志写入磁盘文件后,确认追加成功,发出Commited Ok:

Hands-On Hyperledger Fabric——Raft共识算法_第10张图片

  1. 在下一个心跳heartbeat中,Leader会通知所有Follwer更新commited 项目。

对于每个新的日志记录,重复上述过程。

如果在这一过程中,发生了网络分区或者网络通信故障,使得Leader不能访问大多数Follwers了,那么Leader只能正常更新它能访问的那些Follower服务器,而大多数的服务器Follower因为没有了Leader,他们重新选举一个候选者作为Leader,然后这个Leader作为代表于外界打交道,如果外界要求其添加新的日志,这个新的Leader就按上述步骤通知大多数Followers,如果这时网络故障修复了,那么原先的Leader就变成Follower,在失联阶段这个老Leader的任何更新都不能算commit,都回滚,接受新的Leader的新的更新。

你可能感兴趣的:(Fabric)