hyperledger fabric 1.4 order service(排序服务)

order service是fabric中独有的一个概念,它主要用于对收到的数据进行排序,打包区块,并通过共识算法,分发到各个节点中去。所以fabric中的共识算法则是在order节点中体现。如需系统的学习fabric,可以参考视频教程

值得我们多说一句的是orderer admin可以维护联盟的信息,联盟的信息保存在orderer的system channel 中。如何创建联盟,可以参考我写的其他博客。

那么order service是如何处理接收到的数据的?

1、客户端将请求发送给peer节点,peer节点进行背书,将背书后的提案返回给客户端。

2、此阶段客户端将背书提案的tx提交给order节点,order会根据tx排序并打包成区块。

3、此阶段将打包好的区块分发到连接到order的peer节点,并非所有的peer都必须链接到order,peer之间共享账本可以通过gossip方式进行区块共享传递。每一个peer独立的对接收到区块做校验,来验证是否正确的背书,如果验证不通过,就不会更新world state。

orderer service的实现有一下几种,但是无论是哪一种共识,都不会产生分叉,因为进行打包区块的操作,是由固定的order节点进行操作的,同一时刻只有一个order节点在进行打包区块,而比特币因为存在同一时刻,有两个节点同时计算出hash值的概率,所以存在分叉,在fabric打包区块的设置中,触发打包区块有两个参数尤为重要,一个为batchsize,此参数是用于控制每个区块里可以存储的数据的条数,当达到这一配置的时候自动打包成一个区块,还有一个是timeout,当收到第一条数据达到这个时间的时候就会打包区块,那么在此timeout时间内的数据会同时打包到区块中。

solo 模式

单节点此种方式使用于测试开发环境,因为此种方式无法提高系统的吞吐量,同时无法与order节点之间进行容错。

kafka模式

kafka也是一种cft容错的一种基于zk实现leader-folower模式。kafka半去中心化。

raft模式

raft模式基于raft协议实现的共识算法,打包区块有leader节点进行。

需要注意的是对于一个智能合约的开发者来说,order共识算法的实现是透明的,同时fabric是支持可插拔式的修改共识算法。

本文由博客一文多发平台
OpenWrite 发布!

    原文作者:桃猿结义
    原文地址: https://segmentfault.com/a/1190000020758515
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞