Fabric区块链kafka共识入门

Hyperledger Fabric推荐Kafa用于生产环境。Kafa是一个分布式、具备水平伸缩能力、崩溃容错能力 的日志系统。在Hyperledger Fabric区块链中能够有多个Kafka节点，使用zookeeper进行同步管理。 本文将介绍Kfaka的基本工做原理，以及在Hyperledger Fabric中使用Kafka和zookeeper实现共识的原理，并经过一个实例剖析Hyperledger Farbic中Kafka共识的达成过程。

若是但愿快速掌握Fabric区块链的链码及应用开发，建议访问汇智网的在线互动课程：

• Fabric区块链Java开发详解
• Fabric区块链NodeJs开发详解

1、Kafka工做原理

Kafka本质上是一个消息处理系统，它使用的是经典的发布-订阅模型。消息的消费者订阅特定的主题，以便收到新消息的通知，生产者则负责消息的发布。

当主题的数据规模变得愈来愈大时，能够拆分为多个分区，Kafka保障在一个分区内的消息是按顺序排列的。

Kafka并不跟踪消费者读取了哪些消息，也不会自动删除已经读取的消息。Kafka会保存消息一段时间，例如一天，或者直到数据规模超过必定的阈值。消费者须要轮询新的消息，这使得他们能够根据本身的需求来定位消息，所以能够重放或从新处理事件。消费者处于不一样的消费者分组，对应一个或多个消费者进程。每一个分区被分贝给单一的消费者进程，所以一样的消息不会被屡次读取。

崩溃容错机制是经过在多个Kafka代理之间复制分区来实现的。所以若是一个代理因为软件或硬件故障挂掉，数据也不会丢失。固然接下来还须要一个领导-跟随机制，领导者持有分区，跟随者则进行分区的复制。当领导者挂掉后，会有某个跟随者转变为新的领导者。

若是一个消费者订阅了某个主体，那么它怎么知道从哪一个分区领导者来读取订阅的消息？

答案在于zookeeper服务。

zookeeper是一个分布式key-value存储库，一般用于存储元数据及集群机制的实现。zookeeper容许服务（Kafka代理）的客户端订阅变化并得到实时通知。这就是代理如何肯定应当使用哪一个分区领导者的缘由。zookeeper有超强的故障容错能力，所以Kafka的运行严重依赖于它。

在zookeeper中存储的元数据包括：

• 消费者分组在每一个分区的读取偏移量
• 访问控制清单，用于访问受权与限制
• 生产者及消费者配额，每秒最多消息数量
• 分区领导者及健康信息

2、Hyperledger Fabric中的Kafka

要理解在超级帐本Hyperledger Fabric中的Kafka是如何工做的，首先须要理解几个重要的术语：

• Chain - 指的是一组客户端（通道/channel）能够访问的日志
• Channel - 一个通道相似于一个主题，受权的对等节点（peer）能够订阅而且成为通道的成员。 只有通道的成员能够在通道上交易，一个通道中的交易在其余通道中看不到
• OSN - 即排序服务节点（Ordering Service Node），在Fabric中被称为排序节点。排序节点负责：
  • 进行客户鉴权
  • 容许客户端经过一个简单的接口写入或读取通道
  • 执行配置交易的过滤与验证，实现通道的从新配置或建立新的通道
• RPC - 即远程过程调用（Remote Procedure Call），是一种用于调用其余机器上的服务而无需了解 通讯与实现细节的通讯协议，目的是像调用本地函数同样调用网络中其余机器上的函数
• 广播PRC - 交易提交调用，由排序节点执行
• 分发RPC - 交易分发请求，当交易由kafka代理处理后，分发给请求节点

注意，虽然在Hyperledger Fabric中Kafka被称为共识（Consensus），可是其核心是交易排序服务以及额外的崩溃容错能力。

在Hyperledger Fabric中的Kafka实际运行逻辑以下：

• 对于每一条链，都有一个对应的分区
• 每一个链对应一个单一的分区主题
• 排序节点负责未来自特定链的交易（经过广播RPC接收）中继到对应的分区
• 排序节点能够读取分区并得到在全部排序节点间达成一致的排序交易列表
• 一个链中的交易是定时分批处理的，也就是说当一个新的批次的第一个交易进来时，开始计时
• 当交易达到最大数量时或超时后进行批次切分，生成新的区块
• 定时交易是另外一个交易，由上面描述的定时器生成
• 每一个排序节点为每一个链维护一个本地日志，生成的区块保存在本地帐本中
• 交易区块经过分发RPC返回客户端
• 当发生崩溃时，能够利用不一样的排序节点分发区块，由于全部的排序节点都维护有本地日志

3、Hyperledger Fabric Kafka实例解析

考虑下图，假设排序节点OSN0和OSN2时链接到广播客户端，OSN1链接到分发客户端。

• OSN0已经有了交易foo，中继到kafka集群
• 此时OSN2将交易baz广播到集群中
• 最后，交易bar由OSN0发送到集群中
• 集群如今有三个交易，能够在图中看到三个交易的在日志中的位置偏移量
• 客户端发送分发请求，在OSN1的本地日志中，上述三个交易在4#区块里。
• 所以OSN1将4#区块返回客户端，处理结束

Kakfa的高性能对于Hyperledger Fabric有很大的帮助，多个排序节点经过Kafka实现同步，而Kafka自己并非排序节点，它只是将排序节点经过流链接起来。虽然Kafka支持崩溃容错，它并不能提供对网络中恶意攻击的保护。须要一种拜占庭容错方案（BFT）才能够对抗恶意的攻击，可是目前Hyperledger Farbic框架中还有待实现这一机制。

总而言之，在Hyperledger Farbic中，Kafka共识模块是能够用于生产环境的，它能够支持崩溃容错， 但没法对抗恶意攻击。

---

原文：Fabric Kafka入门 — 汇智网