fabric orderer 排序节点的笔记

1. 对于fabric中的每个通道。

 orderer 将其映射到 kafka集群中的一个 topic ,即一个通道对应一个 topic。每个 topic 只创建一个分区(partion). 因为消息在单个分区里面是有序的,这样就保证了交易的顺序。

2 .OSN:orderer service node

  主要功能: 1. client 端认证 2.允许 client 的 SDK 和 channel 进行交互 3.过滤并且验证 configure transactions 

3. ttc-x time to cut

 关于结块操作:
 为了提高 OSN 的效率,将kakfa的交易数据按照批次出块,这样可以减少验证次数,减少签名(因为签名比较费时)。
 所以引入了 batch 机制,即设置一个 batchSize 参数,一旦交易数达到阈值,就会进行切块操作。
 但是按照 数量出块,又会带来新的问题:因为出块是异步的,假设设置 batchSize=1000,orderering 需要发出1000个交易的batch,现在已经有了999个交易存储在内存中,只需要等待一个交易就可以生成新的区块,但是没有交易发往orderering了,这时候前面的999个交易就被动延迟了。这是不可接受的。
 为了解决这个问题,引入了出块时间 batchTimeout,即用另外一个维度-时间去触发切块操作。这样既超时或者达到批次上限都会触发结块操作。
 因为不同的 OSN 之间都是通过kakfa集群获取数据,并没有直接的关联,而且OSN之间性能不一样,所以OSN的出块的时间很难一致。最终也会导致出块所包含的交易不一致,这也是不可以接受的。
  所以引入了 ttc-x 的概念,各个OSN之间到了切块的时间,都会往kafka 集群中对应的 topic 发出一个 ttc-x 的消息,ttc-x  也属于kafka中的消息,这个消息也会和其他正常的交易信息放到同一个分区里,所以ttc-x和其他的消息都是有序的。
   每个OSN切块的操作都以第一个读取到的 ttc-x 为准,进行出块操作,后续重复的 ttc-x 消息都忽略掉,这样就达到了出块的高度和区块里的交易数一致。
   只是每个OSN 性能不一样,出块的时间不一样而已。

4.账本文件的存储地址

    进入对应的 orderer.example.com 的docker容器: docker exec -it orderer.example.com bash
    cd 到 /var/hyperledger/production/orderer/chains
     即可以看到 blockfile_xxxxxx格式的文件。
本作品采用《CC 协议》,转载必须注明作者和本文链接

不卑不亢,不慌不忙,这才是生活的模样。

讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!