HyperLedger Fabric 开发实战快速掌握区块链技术.PDFVIP

HyperLedger Fabric 开发实战——快速掌握区块链技术 如果一个事务通过了有效性检查，提交者将使用写集来更新世界状态。在更新阶段，对于 写集中的每个键，相同键的值都设置为在写集中指定的值，进一步地，这个世界状态的键的版 本会被改变，以反映最新的版本。 3．模拟和验证案例 本节通过一个示例场景帮助理解语义。对于本例的目的，在世界状态中，键 k 的存在是由 元组(k、ver 、val)表示的，其中，ver 是键 k 的最新版本，它的值由val 表示。 现在，考虑一组 5 个事务：T1、T2、T3、T4 和 T5，它们都在同一个快照上模拟世界状 态。下面的代码片段显示了对事务进行模拟的世界状态的快照，以及由这些事务执行的读取和 写入活动的顺序。 World state: (k1,1,v1), (k2,1,v2), (k3,1,v3), (k4,1,v4), (k5,1,v5) T1 - Write(k1, v1), Write(k2, v2) T2 - Read(k1), Write(k3, v3) T3 - Write(k2, v2) T4 - Write(k2, v2), read(k2) T5 - Write(k6, v6), read(k5) 现在，假设这些事务是在 T1 的序列中排序的。T5 可以包含在一个区块或不同的区块中：  T1 通过验证，因为它不执行任何读取操作。此外，世界状态中的键 k1 和 k2 的元组被 更新为(k1，2 ，v1)和(k2，2 ，v2) 。  T2 失败了，因为它读取了一个键 k1 ，它被之前的事务修改为 T1 。  T3 通过验证，因为它不执行读操作。进一步的，在这个世界状态下的键的元组被更新 到(k2，3，v2) 。  T4 失败了，因为它读取了一个键 k2 ，它被之前的事务 T1 修改过。  T5 通过验证，因为它读取了一个键 k5 ，它没有被前面的任何事务修改过。 注意： 目前还不支持具有多个读写集的事务。 6.4 Kafka集群配置 有了前面 5 个章节的部署经验，再加上本章前三节的概述理论，将会容易理解本章的重点 Kafka 集群部署。 116 第 6 章 Kafka 集群部署 在进行本次方案之前，首先需要对 Kafka 集群的拓扑有些简单的了解。搭建 Kafka 集群的 最小单位组成如下：  三个 Zookeeper 节点集群。  四个Kafka 节点集群。  三个 Orderer 排序服务节点集群。  其他 Peer 节点。 以上集群至少需要 10 个服务节点提供集群服务，其余节点用于背书验证、提交及数据同 步。 Kafka 是一个分布式消息系统，由 LinkedIn 使用 scala 编写，用作 LinkedIn 的活动流 （Activity Stream ）和运营数据处理管道（Pipeline ）的基础。具有高水平扩展和高吞吐量。 在 Fabric 网络中，数据是由 Peer 节点提交到 Orderer 排序服务，而 Orderer 相对于 Kafka 来说相当于上游模块，且 Orderer 还兼具提供了对数据进行排序及生成符合配置规范及要求的 区块。而使用上游模块的数据计算、统计、分析，这个时候就可以使用类似于 Kafka 这样的分 布式消息系统来协助业务流程。 有人说 Kafka 是一种共识模式，也就是说平等信任，所有的 HyperLedger Fabric 网络加盟 方都是可信方，因为消息总是均匀地分布在各处。但具体生产使用的时候是依赖于背书来做到 确权，相对而言，Kafka 应该只能是一种启动 Fabric 网络的模式或类型。 Zookeeper 是一种在分布式系统中被广泛用来作为分布式状态管理、分布式协调管理、分 布式配置管理和分布式锁服务的集群。Kafka 增加和减少服务器都会在 Zookeeper 节点上触发 相应的事件，Kafka 系统会捕获这些事件，进行新一轮的负载均衡，客户端也会捕获这些事件 来进行新一轮的处理。 Order