【链块技术 03期】共识机制:RAFT


原文链接:【链块技术 03期】共识机制:RAFT

 

Raft最初是一个用于管理复制日志的共识算法,它是一个为真实世界应用建立的协议,主要注重协议的落地性和可理解性。

Raft是在非拜占庭故障下达成共识的强一致性协议。

算法理解

RAFT核心思想很容易理解,大致就如下:

如果多个数据库初始状态一致,只要之后进行的操作一致,就能保证之后的数据一致。

过程概述

在区块链系统中,使用Raft算法实现共识记账的过程如下:首先,选举一个leader,接着赋予leader赋予完全的权力管理记账。

Leader从客户端接收记账请求,完成记账操作,生成区块,并复制到其他记账节点。

有了leader简化了记账操作的管理。leader可能失效或与其他节点失去联系,这时,系统就会选出新的leader。

问题分解

Raft将共识问题分解为三个相对独立的子问题:

1. Leader选举

现有的leader失效时,必须选出新的leader。

2. 记账

Leader接收来自客户端的交易记录项,在参与共识记账的节点中进行复制,并使其他的记账节点认可交易所对应的区块。

3. 安全

若某个记账节点对其状态机应用了某个特定的区块项,其他的服务器不能对同一个区块索引应用不同的命令。

RAFT基础

RAFT将服务器分为三种角色:Leader、Follower和Candidate,三种角色可以互相转换。

一个Raft集群至少包含5个服务器,允许系统有两个故障服务器,每个服务器处于3种角色之一。

  • Leader:正常操作状态下仅一个;处理所有的客户端请求。

  • Follower:被动的节点,对来自leader和candidate的请求做出响应(若客户端联系follower,则该follower将请求转发给leader)。

  • Candidate:该状态用来选举leader。

操作过程

1.选举Leader

Follower自增当前任期,转换为Candidate,对自己投票,并发起RequestVoteRPC,等待下面三种情形发生;

  • a) 获得超过半数服务器的投票,赢得选举,成为Leader

  • b) 另一台服务器赢得选举,并接收到对应的心跳,成为Follower

  • c) 选举超时,没有任何一台服务器赢得选举,自增当前任期,重新发起选举

2.共识记账

Leader接受客户端请求,Leader更新日志,并向所有Follower发送心跳Heatbeats,同步日志。

所有Follwer都有ElectionTimeout,如果在ElectionTimeout时间之内,没有收到Leader的Headbeats,则认为Leader失效,重新选举Leader。

3.故障处理

如果在这一过程中,发生了网络通信故障,使得当前Leader不能访问大多数follower了,那么当前leader只能更新它能正常访问的那些follower服务器。

而大多数follower服务器因为没有了leader,他们将重新选举一个候选者作为leader,然后这个新leader作为代表与外界打交道,如果外界要求其添加新的交易记录,这个新的leader就按照上数步骤通知大多数follower。

如果这时网络故障恢复了,那么原先的leader就变成follower。在失联阶段,这个老leader的任何更新都不能算确认,都回滚,接收新的leader的新的更新。

安全性保证

1.日志的流向只有Leader到Follower,并且Leader不能覆盖日志

2.日志不是最新者不能成为Candidate

RAFT应用

在超级账本的Fabric项目中,共识算法被设计成可插拔的模块,支持像PBFT、Raft等共识算法。

 

参考资料

动画:http://thesecretlivesofdata.com/raft/

官网:https://raft.github.io/

论文:https://raft.github.io/raft.pdf

 

本文作者:魏红心,链块学院执行院长,清华大学电子系博士

链块学院:专注于区块链技术研发与教育

 

 

--------------END--------------

本文完,获取更多资讯,敬请关注区块链工程师。

阅读更多

没有更多推荐了,返回首页