概述
超级账本1.0的架构,将节点进行了拆分,分为endorser、orderer和committer三类节点,节点各司其职。其中orderer节点负责共识,目前从官方文档看,支持Solo(单节点共识)、kafka(分布式队列)和SBFT(简单拜占庭容错)三种共识方式。本文主要介绍基于kafka实现的共识机制。
设计思路
kafka是一个分布式高可用消息队列,可以有序的管理消息并在多个冗余副本间保证数据一致性。kafka集群的状态由zookeeper管理,选举leader节点。
orderer服务从kafka集群里获取相应topic(kafka的分区,用于在队列里隔离出多个数据域)的数据,以保证交易数据有序,借助了kafka的分布式一致机制。如下图:
这样的设计有一系列的问题需要考虑。
问题1
orderer服务(OSN)为每一笔交易进行验证和出块,效率不高。
改进
kafka里的交易数据按批次出块,减少验证次数,设置batchSize。
问题2
出块是异步且批量的,如果交易到达速度不平均,batchSize可能很久未到达,影响出块时间。
改进
为了降低批次的等待,设置出块的时间batchTimeout,超时或达到批次上限,均会触发出块操作。
问题3
不同的OSN-n的时间很难同步,导致各OSN出块所包含的交易会不一致。
改进
各OSN增加出块协熵消息(TTC-n,TimeToCut),并将该消息上送至kafka,以第一个TTC-n为准出块,后续重复的TTC-n将被忽略,以达到一致。
问题4
OSN根据块高度同步数据,但块高度和kafka的offset没有关联上,无法识别kafka的断点位置。
改进4-a
使用块的metadata域存储offset,如:“offsets:63-64”。
不足1):与Deliver接口不一致,需要增加块高度参数。
不足2):OSN丢失了若干块,如果从一个随机块或最新块开始同步,它将无法识别正确的offset。
改进4-b
每个OSN针对每条链都要维护一个检索表,记录了块高度和offset的对应关系,而不需要使用块的metadata数据。
问题5
每个OSN在收到分发请求后,都要从当前的节点进行追数,每个节点都要进行相同的操作,而且该操作的代价比较昂贵。
改进5-a
再创建一个分区,用于记录OSN提交的块,可以冗余且无序。但会引发问题6。
改进5-b
持久化已生成的块数据,每个OSN本地存储一个日志记录。同时解决了问题6。
问题六
kafka中存在冗余的消息;检索表会被请求,分发请求处理逻辑相对复杂,检索表操作会增加等待时间。
改进6-a
如果OSN收到唯一的消息,并且自己即将处理相同的消息,则立刻终止自己的提交操作。这样可以大量减少冗余数据提交,但不能完全消除。
改进6-b
选举一个OSN的leader (ZK或谁产生TTC-x谁是主) ,由它负责分区1上下一个块数据的产生。但是仍然可能出现冗余数据:主节点提交块X后宕掉,此时选举出新的主节点,它判断块X仍未提交,所以将自己的块X提交,此时原主节点的数据也提交至kafka上,出现冗余数据。
改进6-c
kafka记录压缩,用kv结构存储。可以完全消除数据冗余问题,但由于kv数据以最后提交的为准,会导致检索表数据过时。
改进6-d
因为改进5b方案,本地账本解决了冗余块消息的问题。
引用
《A Kafka-based Ordering Service for Fabric》 by Kostas Christidis