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--------------
