共识机制之Raft

在区块链的共识机制中，适用于联盟链（许可链）及私有链的主要有PBFT、Raft、Paxos，今次就理解一下Raft。

历史

Raft 的出现很大程度是基于 Paxos 算法难以理解和实现。

1990年，Leslie Lamport （还记得早前我在上一篇文章讲述共识机制PBFT 中提及过的作者Leslie Lamport 吗？没错，也是他）提出了一种基于消息传递的一致性算法－Paxos，但由于当时大家都难以理解这个算法的思想和在实际中难以实现，所以大家都没太大兴趣。

1998年，Leslie Lamport 将这个算法在ACM上正式发表，同样因为太难理解和实现，亦没有得到重视，随后，作者有见及此，换了一个角度重新发表一篇论文《Paxos Made Simple》，大家才开始逐渐理解Paxos 算法，但Paxos 仍属于一种”理论”，距离实现还需要基于Paxos 做一些扩展才能在实际中应用。

就正因为 Paxos 的难以理解和实现，导致了后来 Raft 的出现。

2013年，两位Stanford University的教授发表了一篇题为《In search of an Understandable Consensus Algorithm (Extended Version)》（寻找一种易于理解的一致性算法），这被认为是一种简易版的Paxos，性能和功能都与Paxos一样，同时易于理解和实现，这就是Raft出现的原因。

定义（概念）

Raft 是用于实现分散式系统的一种容易理解的共识机制，主要用来管理日志复制的一致性。

Raft 的核心思想很简单：

试想像一下，假设把三个数据库想像成是你面前的三本账本，只要每次在第一本账本上写上了一笔记录时，同时将这笔记录同样地写在另外两本账本上，那么这三本账本的数据始终是一样的。

Raft 取代复杂难懂的Paxos算法，并且证明可以提供与Paxos相同的容错性以及性能，并且更容易应用到实际系统中。

Raft 集群中，伺服器的三种角色

而在一个Raft集群（Raft cluster）中，至少包含5个伺服器，允许系统有2个故障伺服器，在系统初始时，每个伺服器都处于追随者的状态。而每个伺服器将会是这三种角色其中一个：

领袖（Leader）：正常状态下只有一个领袖，其他都是追随者，它会负责处理所有来自外部Client的请求及进行日志复制（日志复制是单向的，即领袖发送给追随者），先就是负责”出块”的节点。

候选人（Candidate）：由追随者向领袖转换的中间状态，等待被选举为领袖。

追随者（Follower）：它是被动的节点，对来自Client和候选人的请求做出响应。如果收到外部Client的请求，就会将请求会被转发给领袖。

而这三种角色在条件满足下可以互相转换，而在正常情况下只会有一个领袖，其他都是追随者。而领袖会负责所有外部的请求。

Raft 内三个重要概念

1. Replicated State Machine 状态复制机 

而ETCD 则是将Raft 算法实作成一个Library，可以让其他应用快速地应用Raft 算法，它的目标是构建一个高可用的分散式键值（Key-Value）数据库。

优缺点

优点

1.易于理解，容易实现

Paxos 算法难以理解，Raft 将整个算法清楚分成两部份，并利用日志的连续性做了简化，从本质上来说，流程及描述清晰，比起Paxos 来说更容易实现和理解。

2. 简化Paxos，效率相同

Raft 就相当于Multi-Paxos，而且和Paxos 算法一样高效，Raft 将Leader 选举、日志复制、安全性等关键元素分离，并采用更强的一致性以减少必须考虑状态的数量。

缺点

1. Raft 只适用联盟链（许可链）或私有链

2. 无法进行拜占庭容错的缺陷

总结

Raft 共识机制相对于Paxos 来说，却是在概念上简化了不少，将集群中Leader 角色的地位强化了，而且流程和描述清晰，令大家更容易理解和实现，而且在安全性及效率可以与Paxos 相同，目前也作为市场上大部份联盟链（许可链）平台可选的共识机制之一，但缺陷却是去中心化较弱，只适用于联盟链（许可链）或私有链，不过，共识机制就是这样，没有一个能适用于所有应用场景的共识机制，需要在去中心化、安全性、出块效率之间作出取舍，没有最好，只有最适用。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。