Hyperledger Fabric排序服务实现

排序算法 solo kafka raft

Raft (推荐)

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

Kafka (在 v2.0 中被弃用)

   和基于 Raft 的排序类似，Apache Kafka 是一个 CFT 的实现，它使用“领导者和跟随者”模型。Kafka 集群的管理，包括任务协调、集群成员、访问控制和控制器选择等，由 ZooKeeper 集合及其相关 API 来处理。管理Kafka集群会造成额外的管理开销。

Solo (在 v2.0 中被弃用)

   排序服务的 Solo 实现仅仅是为了测试，并且只包含了一个单一的排序节点，它已经被弃用了。

Raft详解

  对于将用于生产网络的排序服务，Fabric 实现了使用“领导者跟随者”模型的 Raft 协议，领导者是在一个通道的排序节点中动态选择的（这个集合的节点称为“共识者集合（consenter set）”），领导者将信息复制到跟随者节点。Raft 被称为“崩溃容错”是因为系统可以承受节点的损失，包括领导者节点，前提是要剩余大量的排序节点（称为“法定人数（quorum）”）。换句话说，如果一个通道中有三个节点，它可以承受一个节点的丢失（剩下两个节点）。如果一个通道中有五个节点，则可以丢失两个节点（剩下三个节点）。

  从它们提供给网络或通道的服务的角度来看，Raft 和现有的基于 Kafka 的排序服务是相似的。它们都是使用领导者跟随者模型设计的 CFT 排序服务。然而，有几个主要的差异值得考虑：

  Raft 更容易设置。部署 Kafka 集群及其 ZooKeeper 集群会很棘手，需要在 Kafka 基础设施和设置方面拥有高水平的专业知识。此外，使用 Kafka 管理的组件比使用 Raft 管理的组件多，这意味着有更多的地方会出现问题。Kafka 有自己的版本，必须与排序节点协调。这就体现出Raft协议的好处：内嵌在排序节点中。

  Kafka 和 Zookeeper 并不是为了在大型网络上运行。Kafka 是 CFT，它应该在一组紧密的主机中运行。这意味着实际上，您需要有一个组织运行 Kafka 集群。使用 Raft，每个组织都可以有自己的排序节点参与排序服务，从而形成一个更加去中心化的系统。

  Raft 是原生支持的，对 Kafka 相关问题的支持是通过 Apache 来处理的，Apache 是 Kafka 的开源开发者，而不是 Hyperledger Fabric。另一方面，Fabric Raft 的实现已经开发出来了，并将在 Fabric 开发人员社区及其支持设备中得到支持。

  Kafka 使用一个服务器池（称为“Kafka 代理”），而且排序组织的管理员要指定在特定通道上使用多少个节点，但是 Raft 允许用户指定哪个排序节点要部署到哪个通道。通过这种方式，节点组织可以确保如果他们也拥有一个排序节点，那么这个节点将成为该通道的排序服务的一部分，而不是信任并依赖一个中心来管理 Kafka 节点。

  Raft 是向开发拜占庭容错（BFT）排序服务迈出的第一步。正如我们将看到的，Fabric 开发中的一些决策是由这个驱动的。

  由于所有这些原因，在 Fabric v2.0 中，对于基于 Kafka 的排序服务正在被弃用。注意：与 Solo 和 Kafka 类似，在向客户发送回执后 Raft 排序服务也可能会丢失交易。例如，如果领导者和跟随者提供回执时同时崩溃。因此，应用程序客户端应该监听节点上的交易提交事件，而不是检查交易的有效性。但是应该格外小心，要确保客户机也能优雅地容忍在配置的时间内没有交易提交超时。根据应用程序的不同，在这种超时情况下可能需要重新提交交易或收集一组新的背书。

Raft 概念

  日志条目（Log entry）。 Raft 排序服务中的主要工作单元是一个“日志条目”，该项的完整序列称为“日志”。如果大多数成员（换句话说是一个法定人数）同意条目及其顺序，则我们认为条目是一致的，然后将日志复制到不同排序节点上。

  共识者集合（Consenter set）。主动参与给定通道的共识机制并接收该通道的日志副本的排序节点。这可以是所有可用的节点（在单个集群中或在多个集群中为系统通道提供服务），也可以是这些节点的一个子集。

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

  法定人数（Quorum）。描述需要确认提案的最小同意人数。对于每个共识者集合，这是大多数节点。在具有五个节点的集群中，必须有三个节点可用，才能有一个法定人数。如果节点的法定人数因任何原因不可用，则排序服务集群对于通道上的读和写操作都不可用，并且不能提交任何新日志。

  领导者（Leader）。领导者负责接收新的日志条目，将它们复制到跟随者的排序节点，并在认为提交了某个条目时进行管理。这不是一种特殊类型的排序节点。它只是排序节点在某些时候可能扮演的角色，而不是由客观环境决定的其他角色。

  跟随者（Follower）。跟随者从领导者那里接收日志并复制它们，确保日志保持一致。跟随者也会收到来自领导者的“心跳”消息。如果领导者在一段可配置的时间内停止发送这些消息，跟随者将发起一次领导者选举，它们中的一个将当选为新的领导者。

交易流程中的 Raft

  每个通道都在 Raft 协议的单独实例上运行，该协议允许每个实例选择不同的领导者。这种配置还允许在集群由不同组织控制的排序节点组成的用例中进一步分散服务。虽然所有 Raft 节点都必须是系统通道的一部分，但它们不一定必须是所有应用程序通道的一部分。通道创建者（和通道管理员）能够选择可用排序节点的子集，并根据需要添加或删除排序节点（只要一次只添加或删除一个节点）。

  虽然这种配置以冗余心跳消息和线程的形式产生了更多的开销，但它为 BFT 奠定了必要的基础。

  在 Raft 中，交易（以提案或配置更新的形式）由接收交易的排序节点自动路由到该通道的当前领导者。这意味着 Peer 节点和应用程序在任何特定时间都不需要知道谁是领导者节点。只有排序节点需要知道。

  当排序节点检查完成后，将按照我们交易流程的第二阶段的描述，对交易进行排序、打包成区块、协商并分发。

架构说明

Raft 是如何选举领导者的

  尽管选举领导者的过程发生在排序节点的内部过程中，但是值得注意一下这个过程是如何工作的。

  节点总是处于以下三种状态之一：跟随者、候选人或领导者。所有节点最初都是作为跟随者开始的。在这种状态下，他们可以接受来自领导者的日志条目（如果其中一个已经当选），或者为领导者投票。如果在一段时间内没有接收到日志条目或心跳（例如，5秒），节点将自己提升到候选状态。在候选状态中，节点从其他节点请求选票。如果候选人获得法定人数的选票，那么他就被提升为领导者。领导者必须接受新的日志条目并将其复制到跟随者。

  点击查看Raft模型

快照

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

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

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

  参考资料：官方文档