Raft 协议 - Fabric

Raft 服务排序

1. 交易流程

Peer 节点构成了区块链网络的基础，托管账本，应用程序可以通过智能合约查询和更新这些账本。具体来说，更新账本的应用程序涉及到三个阶段，该过程确保区块链网络中的所有节点保持它们的账本彼此一致。

阶段一：提案

在第一阶段，客户端应用程序将交易提案发送给一组节点，这些节点将调用智能合约来生成一个账本更新提案，然后背书该结果。背书节点此时不将提案中的更新应用于其账本副本。相反，背书节点将向客户端应用程序返回一个提案响应。已背书的交易提案最终将在第二阶段经过排序生成区块，然后在第三阶段分发给所有节点进行最终验证和提交。

阶段二：将交易排序并打包到区块中

在此阶段，应用程序客户端把包含已背书交易提案响应的交易提交到排序服务节点。排序服务创建交易区块，这些交易区块最终将分发给通道上的所有 Peer 节点，以便在第三阶段进行最终验证和提交。

排序服务节点同时接收来自许多不同应用程序客户端的交易。这些排序服务节点一起工作，共同组成排序服务。它的工作是将提交的交易按定义好的顺序安排成批次，并将它们打包成区块。然后将这些区块保存到排序节点的账本中，并分发给已经加入通道的所有节点。如果此时恰好有一个 Peer 节点关闭，或者稍后加入通道，它将在重新连接到排序服务节点或与另一个 Peer 节点通信之后接收到这些区块。我们将在第三阶段看到节点如何处理这个区块。

在第二阶段的最后，我们看到排序节点负责一些简单但重要的过程，包括收集已提案的交易更新、排序并将它们打包成区块、准备分发。

阶段三：验证和提交

交易工作流的第三个阶段涉及到从排序节点到 Peer 节点的区块的分发和随后的验证，这些区块可能会被提交到账本中。

第三阶段排序节点将区块分发给连接到它的所有 Peer 节点开始。同样值得注意的是，并不是每个 Peer 节点都需要连接到一个排序节点，Peer 节点可以使用 gossip 协议将区块关联到其他节点。

每个节点将独立地以确定的方式验证区块，以确保账本保持一致。具体来说，通道中每个节点都将验证区块中的每个交易，以确保得到了所需组织的节点背书，也就是节点的背书和背书策略相匹配，并且不会因最初认可该事务时可能正在运行的其他最近提交的事务而失效。无效的交易仍然保留在排序节点创建的区块中，但是节点将它们标记为无效，并且不更新账本的状态。

总之，第三阶段看到的是由排序服务生成的区块一致地应用于账本。将交易严格地按区块排序，允许每个节点验证交易更新是否在整个区块链网络上一致地应用。

2. 排序服务实现

虽然当前可用的每个排序服务都以相同的方式处理交易和配置更新，但是仍然有几种不同的实现可以在排序服务节点之间就严格的交易排序达成共识。

• Raft (推荐)

  作为 v1.4.1 的新特性，Raft 是一种基于 etcd 中 Raft 协议实现的崩溃容错（Crash Fault Tolerant，CFT）排序服务。Raft 遵循“领导者跟随者”模型，这个模型中，在每个通道上选举领导者节点，其决策被跟随者复制。Raft 排序服务会比基于 Kafka 的排序服务更容易设置和管理，它的设计允许不同的组织为分布式排序服务贡献节点。

• Kafka (在 v2.0 中被弃用)

  和基于 Raft 的排序类似，Apache Kafka 是一个 CFT 的实现，它使用“领导者和跟随者”节点配置。Kafka 利用一个 ZooKeeper 进行管理。基于 Kafka 的排序服务从 Fabric v1.0 开始就可以使用，但许多用户可能会发现管理 Kafka 集群的额外管理开销令人生畏或不受欢迎。

• Solo (在 v2.0 中被弃用)

  排序服务的 Solo 实现仅仅是为了测试，并且只包含了一个单一的排序节点。它已经被弃用了，可能会在将来的版本中被完全移除。既存的 Solo 用户应该迁移到一个单一节点的 Raft 网络获得同样的功能。

3. Raft 概念

分布式存储系统通常通过维护多个副本来提高系统的可用性，带来的代价就是分布式存储系统的核心问题之一：维护多个副本的数据一致性，也就是 Fabric 网络中排序节点遇到的问题。

Raft 就是一种实现分布式共识的协议，去实现维护多个副本的数据一致性。

Raft 被称为“崩溃容错”是因为系统可以承受节点的损失，包括领导者节点；前提是要剩余大量的排序节点（称为“法定人数(quorum)”）。换句话说，如果一个通道中有三个节点，它可以承受一个节点的丢失（剩下两个节点）。如果一个通道中有五个节点，则可以丢失两个节点（剩下三个节点）。

raft算法支持最大的容错故障节点是（N-1）/2，其中N为集群中总的节点数量。

对于将用于生产网络的排序服务，Fabric 实现了使用 “领导者跟随者” 模型的 Raft 协议，领导者是在一个通道的排序节点集合中动态选择的（这个排序节点集合称为 “共识者集合(consenter set)”），领导者将信息复制到跟随者节点。

虽然 Raft 提供了许多与 Kafka 相同的功能（尽管它是一个简单易用的软件包）但它与 Kafka 的功能却大不相同，它向 Fabric 引入了许多新的概念，或改变了现有的概念。

• 日志条目（Log entry）

  Raft 排序服务中的主要工作单元是一个 “日志条目”，该项的完整序列称为 “日志”。

  如果大多数成员（换句话说是一个法定人数）同意条目及其顺序，则我们认为条目是一致的，然后将日志复制到不同排序节点上。

• 共识者集合（Consenter set）

  主动参与给定通道的共识机制并接收该通道的日志副本的排序节点。

  这可以是所有可用的节点（在单个集群中或在多个集群中为系统通道提供服务），也可以是这些节点的一个子集。

• 有限状态机（Finite-State Machine，FSM）

  Raft 中的每个排序节点都有一个 FSM，它们共同用于确保各个排序节点中的日志序列是确定的（以相同的顺序编写）。

• 法定人数（Quorum）

  描述需要确认提案的最小同意人数。对于每个共识者集合，这是大多数节点。

  在具有五个节点的集群中，必须有三个节点可用，才能有法定人数。如果节点的法定人数因任何原因无法达到，则排序服务集群对于通道上的读和写操作都不可用，并且不能提交任何新日志。

• 领导者（Leader）

  这并不是一个新概念，Kafka 也使用了领导者，但是在任何给定的时间，通道的共识者集合都选择一个节点作为领导者，这一点非常重要。

  领导者负责接收新的日志条目，将它们复制到跟随者的排序节点，并在认为提交了某个条目时进行管理。

  这不是一种特殊类型的排序节点。它只是排序节点在某些时候可能扮演的角色，而不是由客观环境决定的其他角色。

• 跟随者（Follower）

  同样地，这也不是一个新概念。理解跟随者的关键是，跟随者从领导者那里接收日志并复制它们，从而确保日志保持一致。

  我们将在关于领导者选举的部分中看到，跟随者也会收到来自领导者的 “心跳” 消息。如果领导者在一段可配置的时间内停止发送这些消息，跟随者将发起一次领导者选举，它们中的一个将当选为新的领导者。

4. Raft 运行流程

节点总是处于以下三种状态之一：跟随者（follower），候选人（candidate）和领导者（leader）。集群中的一个节点在某一时刻只能是这三种状态的其中一种，这三种角色是可以随着时间和条件的变化而互相转换的。

Raft 算法主要有两个过程：一个过程是领导者选举，另一个过程是日志复制，其中日志复制过程会分记录日志和提交数据两个阶段。

4.1 领导者选举

在 Raft 中有两个控制选举的超时设置：选举超时，心跳超时。

选举超时 election timeout

所有节点最初都是作为跟随者开始的。在这种状态下，他们可以接受来自领导者的日志条目（如果其中一个已经当选），或者为领导者投票。

如果跟随者在一段时间内没有接收到消息，即选举超时（随机150ms - 300ms），节点将自己提升到候选状态，开始新一轮的选举。

• 在候选状态中，候选人会先给自己投票，并向其他节点发送“投票请求(Request Vote)”消息。如果有候选人获得法定人数的选票，那么他就成为领导者；如果出现分裂投票（平票），则发起投票的候选人们进入禁止发起投票一段时间。一般禁止发起投票时间长于选举超时，所以其他跟随者可能成为候选人，开启新一轮选举。

如果跟随者在选举超时时间内收到消息，则会回复消息并重置选举超时时间。

• 收到日志条目，还会复制日志条目；收到投票请求，则会返回投票结果。

心跳超时 hearbeat timeout

接下来，系统的所有改变（添加日志记录）都需要经过领导者，即它将开始向跟随者发送“追加记录(Append Entries)”的消息。这些消息按照心跳超时指定的时间间隔发送，而跟随者会回复每一条“追加记录”消息，如此往复。这次的选举会一直持续直到某个跟随者不再接收到心跳，从而变成候选人。

这个过程就是领导者选举（Leader Election）。

4.2 日志复制

一旦我们选出了领导者，我们就需要将系统的所有改变复制到所有节点上。这是通过使用与用于心跳的相同的“追加记录”消息来完成的。

首先，客户端向领导者发送一个改变。这个改变追加到领导者的日志上，为了提交记录，在下一心跳时，领导者会将改变（日志）发给跟随者，即让跟随者复制日志记录。

如果日志记录是未提交的，它是不会更新到更新到节点上的，即真正地执行。当大多数跟随者返回消息并承认，则条目在领导者就会被提交（执行），数据被更新。

然后领导者会返回回应给客户端，并随着心跳发送消息给跟随者，让它们也提交。

集群现在已经就系统状态达成了共识。这个过程就是日志复制。

在这个过程中只需要领导者发送消息给跟随者节点，跟随者节点返回消息给领导者节点即可完成，跟随者节点之间是无需沟通的。

所以如果集群总节点数为 n，对于日志记录阶段，通信次数为n-1，对于提交数据阶段，通信次数也为n-1，总通信次数为2n-2，因此raft算法复杂度为O(n)。

4.3 分区网络的一致性

Raft 甚至可以在面对网络分区时保持一致性。分区指将节点分为不同的区域，不同区域的节点之间没有通信。

当对原有网络进行分区，没有领导者的分区会自行产生新的领导者，进行正常的运行。

当对分区后的网络重新恢复，之前选举的领导者在接收到后来选举的领导者的消息后，会成为它的跟随者。同时之前的领导者和其跟随者，都将回滚其未提交的条目并匹配新领导者的日志。

我们的日志现在在集群中是一致的。

5. 快照

如果一个排序节点宕机，它如何在重新启动时获得它丢失的日志？

虽然可以无限期地保留所有日志，但是为了节省磁盘空间，Raft 使用了一个称为 “快照” 的过程，在这个过程中，用户可以定义日志中要保留多少字节的数据。这个数据量将决定区块的数量（这取决于区块中的数据量。注意，快照中只存储完整的区块）。

例如，假设滞后副本 R1 刚刚重新连接到网络。它最新的区块是 100。领导者 L 位于第 196 块，并被配置为快照 20 个区块。R1 因此将从 L 接收区块 180，然后为区块 101 到 180 区块分发请求。然后 180 到 196 的区块将通过正常 Raft 协议复制到 R1。

---

论文分析

摘要

针对分布式 Fabric raft区块链网络，通过量化分析，对区块大小、背书策略、代理 orderer节点与区块链交易性能之间的定量关系进行了研究 。

针对区块链性能的特点，提出一个名为区块生成速率 BLKPS的性能指标 。

针对产生区块的时间条件，提出超时前最大交易次数 MaxTBT 这一性质，并发现，随着区块大小的增大，区块链交易性能提高，并在区块大小达到超时前最大交易次数后趋于稳定 。

背书策略为 AND 与背书策略为 OR 相比，平均响应时间延长20%，区块生成速率与 每秒交易数均降低约 10%。

代理 orderer节点是 raft 的 follower节点与 leader节点相比，平均响应时间延长约16%，区块生成速率与每秒交易数均降低约 7%。

1 引言

随着 Fabric 的不断发展，应用形式也更加多元化 ，但区块链的性能短板也不容忽视 。区块链的 性能在一定程度上限制了其发展与应用，若要将基 于 Fabric区块链的应用进一步推广，务必要掌握其 性能特性 。raft共识协议是 Fabric网络中容错性最 强的共识协议之一。 因此对于使用 raft 共识协议的 Fabric 区块链的性能探究具有非常重要的现 实意义。

王旭等通过建立区块链性能的数学模型，研究区块大小、区块生成速率以及网络传输速率等因素与区块链性能和安全性之间的定量关系。Noah Weston 等对移动网络仿真中的以太坊区块链进行了实验，探索了移动网络环境中区块链技术的性能。Mohamed El Ghazouani等提出了一种MultiA-gent 系统，以操纵重复数据删除技术，该技术可以减少数据量，从而减少存储开销。但现有的研究成果缺少针对分布式 Fabric raft 网络性能影响因素的研究，其性能也表现得比较复杂。因此本文针对Hyperledger Fabric 网络架构，使用四台主机构建分布式区块链，采用raft共识协议，构建双机构，四个peer节点，三个orderer节点，以每秒交易数、平均响应时间、区块生成速率为性能指标进行测试，研究单用户操作单信道的Fabric raft网络性能。通过改变区块大小、背书策略、代理orderer节点对区块链的性能进行检测与分析，探究不同性能影响因素对性能的影响并深入分析。

2 测试网络架构与方法

2.1 测试网络架构

本文采用分布式Fabric raft区块链。在raft集群中有leader、follower、candidate三种角色。最初所有节点都是follower，当超时后开始选举，所有节点变成candidate。在经过投票后，获得大多数选票的candidate成为leader。如果leader故障或在一定时间内没有对follower节点发送心跳，将重新选举产生leader。因此，raft的leader节点并不是固定的，而是动态的。

共使用四台主机，在主机上的节点部署情况如表1。在主机A上运行测试程序。

表1 网络节点分布

主机名	IP地址	节点	主机信息	主频
主机 A	192.168.1.170	orderer.example.com peer0.org1.example.com ca.org1.example.com	64G 内存 40个核	2.40GHz x 40
主机 B	192.168.1.154	orderer2.example.com peer0.org2.example.com ca.org2.example.com	16G 内存 8个核	3.40GHz x 8
主机 C	192.168.1.177	orderer3.example.com peer1.org1.example.com	8G 内存 4个核	3.20GHz x 4
主机 D	192.168.1.113	peer1.org2.example.com ca.org1.example.com	16G 内存 8个核	3.40GHz x 8

2.2 性能测试方法

Fabric区块链性能表现非常复杂。比如执行1次交易的响应时间在2.1s～2.8s内，并发执行99次交易的响应时间也大致相同。但并发执行100次也许只需1.4s～1.37s。

本文中采用一种类似负载测试的方法，针对一个方法或函数，一次性加载500个并发调用，然后记录每个调用的完成时间作为响应时间，以最后完成时间作为500个调用完成时间，以此来计算平均响应时间、每秒交易数、区块生成速率等各项性能指标。一次负载测试可分三个阶段。

1. 加载、吞入阶段。从开始到最后一个调用完成加载，并记录开始时间与各调用的开始时间；
2. 承载、消化阶段。从加载完成到第1个调用完成，此阶段网络承载并发工作量；
3. 减载、吐出阶段。从第1个调用完成到最后1个调用完成，此阶段负载逐步减少，记录各调用完成时间。

3 性能测试指标与影响因素

3.1 性能测试指标

本文中采用的测试性能指标主要为每秒交易数、平均响应时间、区块生成速率。

每秒交易数TPS(Transaction Per Second)：每秒完成的交易数量。用完成的交易数量除以所需时间求得。记t₀为开始提交交易的时刻（s)，t₁为所有交易均完成的时刻（s)，n为完成的总交易数量（个）。

平均响应时间ART(Average Response Time)：每次交易的平均响应时间，记RT_i为第i个交易的响应时间（s)，n为完成的交易总数量（个）。

区块生成速率BLKPS(Block Per Second)：每秒产生的区块个数。记t₀为开始提交交易的时刻（s)，t₁为所有交易均完成的时刻（s)，b为在一次测试中产生的区块个数（个）。

3.2 性能影响因素

Fabric网络是一个分布式多节点密切协作的复杂系统，影响交易性能的因素非常多。在本文中选取区块大小、背书策略、代理orderer节点作为性能影响因素进行分析。

3.2.1 区块大小

区块大小指每个区块中能够包含的最大交易数目。当至少满足以下三个条件之一时，便会产生一个区块。

1. 该区块中从首个交易到达开始，等待时间超过2s；
2. 该区块中已接收的交易个数达到区块大小；
3. 该区块中字节大小达到512KB。

实验结果预测假设：

针对不同大小的区块，在相同并发数量的情况下，生成的区块数目不同。以并发数为100为例。当区块大小为10时，将生成10个区块；区块大小为50时，将产生两个区块。因此预测，随着区块大小的增大，每秒交易数增大，平均响应时间降低，区块生成速率降低，并且都将趋于稳定。

3.2.2 背书策略

节点通过背书策略来确定一个交易是否被正确背书。本文网络中含有两个机构，org1与org2。对于双机构网络，背书策略可选取单背书OR，双背书AND。

1. 单背书OR：org1或org2中任何一个peer节点背书成功即可。
2. 双背书AND：org1与org2机构中均至少一个peer节点背书成功。

实验结果预测假设：

背书策略为AND时与背书策略是OR时相比较，安全性更强，但需要的背书节点也更多。因此预测，每秒交易数降低，平均响应时间增大，区块生成速率降低。

3.2.3 代理orderer节点

代理orderer节点是raft网络中的接受请求节点，raft网络的leader节点是处理请求的节点，如果两者不是同一节点，代理orderer节点需要将请求转发至raft的leader节点进行处理，如果二者是同一节点，则无需转发，可直接处理。

实验结果预测假设：

代理orderer节点是raft网络中的follower节点时与是leader节点时相比较，需要一个交易转发的过程。因此预测，每秒交易数降低，平均响应时间增大，区块生成速率降低。

4 实验与数据分析

4.1 基准性能测试

首先进行基准性能实验，计算每秒交易数、平均响应时间、区块生成速率。相关参数配置如表2。设置并发数为500，进行3次测试取平均值作为结果。

最终得到的基准性能测试数据为每秒交易数为118.24，平均响应时间2.68s，区块生成速率为2.36块每秒。

后续实验相较于基准性能测试，将每次改动一种参数，得到新的实验结果并进行比较分析。

表2 基准性能实验参数

参数	值
区块大小	50
背书策略	OR
代理orderer节点	不是raft网络的leader节点

4.2 改变区块大小

对比基准测试，只更改区块大小。分别测试区块大小为5、20、50（基准测试）、100、150、200、250、300、350、400、450、500时的性能，得到的测试结果如下图所示。

图1 BLKPS随着区块大小的变化

图2 TPS与ART随着区块大小的变化

区块生成速率随区块大小的变化曲线如图1，平均响应时间和每秒交易数随区块大小的变化曲线如图2。

现象分析：根据图中的曲线变化，随着区块大小的增加，

• 区块生成速率(BPS)逐步下降，当区块大小达到200后，趋于稳定，并在0.85块每秒上下波动。
• 平均响应时间(ART)也逐步下降，并在区块数量达到50后趋于稳定，在2.5s左右波动。
• 每秒交易数(TPS)逐步增大，在区块大小达到200后，在135个每秒左右波动。

原因分析：

• 在跟踪区块数据后发现，当区块大小大于等于200后，500次交易均产生3个区块，分别含有183、183、134个交易，这是由于当等待时间超过2s或未封装的交易总大小达到区块能容纳的数据大小（512KB）时，也会产生区块。由于测试数据大小较小，总大小不可能超出512KB，因此，网络中从区块中首个交易到达开始，等待时间（2s）内最多接收的交易为183个，当区块大小超过183个交易时，增加区块大小对于提升Fabric网络性能已无意义。

  综上，提出超时前最大交易次数这一性质，并定义如下。

  超时前最大交易次数Max TBT(Maximum transactions before Timeout）：在区块中字节数不超过区块最大字节数的前提下，未超时的时间内能完成的最大交易数目。

---

检验假设：

• 实验中当区块大小达到200后网络虽有波动，但整体性能趋于稳定。符合3.2.1小节提出的假设，但当区块大小为150时，出现假设之外的情况。

• 图2中可观察到当区块大小设置为150时，数据波动较大。在查看具体区块后发现，实验中的500个并发交易共产生四个区块，每个区块内的交易数量分别为150、150、150、50个。

  最后一个区块只有50个交易，同时区块内数据量不会超过512KB，此时只有等待时间超过2s时，才会产生区块，即等待时间需达到2s，所以当区块大小设置为150时，每秒交易数会骤降。

  观察表3，可看出生成的4个区块中，前三个区块交易的平均响应时间增长率稳定在17%上下，但第四个区块相比于第三个区块的增长率为27.71%，增长率提高了63%，与推论一致。

当区块大小达到未超时最大交易次数时，再增大区块大小也不会增加区块内的实际交易数量，性能趋于稳定。但当区块大小小于未超时最大交易次数时，随着区块大小的增加，每秒交易数增加，平均响应时间减少，区块生成速率降低，同时也会受到负载并发数的影响。若并发负载数不是区块大小的整数倍，最后一个区块内的实际交易数量将小于设置的区块大小，因此需要等待时间达到2s，才能产生区块。

表3 区块大小为150时所生成区块的ART

区块序号	ART( s )	相较前一个区块的ART增长率
1	2.41
2	2.85	18.26%
3	3.32	16.49%
4	4.24	27.71%

4.3 改变背书策略

对比基准测试，只更改背书策略为AND。比较背书策略为OR时（基准测试）与背书策略为AND时网络性能的不同，得到结果如表4。

表4 应用不同背书策略时的性能

背书策略	TPS( 个 / s )	BLKPS( 块 / s )	ART( s )
AND	105.85	2.12	3.21
OR	118.24	2.36	2.68

现象分析：

• 从表4中数据可以得出，背书策略为AND时与背书策略为OR时比较，平均响应时间延长了20%，区块生成速率降低约10%，每秒交易数降低约10%。

检验假设：

• 由实验结果可知，当背书策略为OR时性能总体优于背书策略为AND的性能，这也是背书策略为AND高安全性的代价。实验结果符合3.2.2小节中提出的假设。

4.4 改变代理orderer节点

对比基准测试，将代理orderer节点更改为raft网络中的leader节点。比较代理orderer节点是raft网络中的follower节点时（基准测试）与代理orderer节点是raft网络中的leader节点时网络性能的不同，得到结果如表5所示。

表5 应用不同代理orderer节点时的性能

代理orderer节点	TPS( 个 / s )	BLKPS( 块 / s )	ART( s )
leader节点	118.24	2.36	2.68
follower节点	109.49	2.19	3.12

现象分析：

• 从表5中可以得出，代理orderer节点是raft网络中的follower节点时与代理节点是raft网络中的leader节点时比较，平均响应时间延长了约16%，区块生成速率与每秒交易数均降低了约7%。

检验假设：

• 由实验结果可知，当代理orderer节点是raft网络的leader节点时，性能优于代理orderer节点是raft网络的follower节点时的网络性能。但raft的leader节点是动态的，根据选举选出，所以很难实时跟踪leader节点。实验结果符合3.2.3小节中提出的假设。

5 结语

本文对Fabric的raft网络进行性能测试，主要以性能指标中的每秒交易数、区块生成速率和平均响应时间作为主要测试指标，分析基本性能。然后针对区块大小、背书策略、代理orderer节点三种性能因素设计实验，测试对比并进行了原因分析。对于测试过程中出现的异常现象也给出了合理的分析解释。

本研究结果发现，当区块内的最大交易数量已经超过未超时最大交易数时，区块链性能将趋于稳定。当小于区块分割等待时间所能完成的最大交易数量时，网络性能受到区块大小与并发负载量的影响，区块大小越大，并发负载量是区块大小的整数倍时网络性能越好。背书策略为AND时与背书策略为OR时比较，平均响应时间延长20%，区块生成速率缩短到原有的90%，每秒交易数降低约10%。当代理orderer节点为变量实验时代理orderer节点是raft网络中的follower节点时时，平均响应时间延长了约16%，区块生成速率与每秒交易数均降低约7%。

本研究对于单用户单信道的Fabric raft网络性能的深入探究，有助于进一步开发高性能的区块链网络。在后续区块链实际应用的开发以及推广中，其性能问题必然是有待进一步解决的重点难点。希望本文中对于分布式区块链的性能影响因素研究可以为后续的优化提供一定的理论指导和参考。

References

• Raft 共识算法概念 - blog - oschina：https://my.oschina.net/j4love/blog/5469044
• Fabric官方文档 - 排序服务：https://hyperledger-fabric.readthedocs.io/zh_CN/latest/orderer/ordering_service.html
• Raft Web Site：https://raft.github.io/
• The Raft Paper：https://raft.github.io/raft.pdf
• 动画演示： http://thesecretlivesofdata.com/raft/
• 论文：分布式 Fabric raft 区块链性能影响因素定量研究 - 李雪飞,严悍,周亚茹,牛天胜 - 计算机与数字工程-2021年第9期