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 协议》，转载必须注明作者和本文链接