链块技术 03期

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

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