撸源码,理流程,看清fabric中的Kafka到底算不算一种共识算法?

fabric 1.1中共识算法只有两种,一种是 kafka,一种是solo,solo是单个机器的,很少用于开发环境中。所以有段时间一直在困惑: 到底kafka能不能作为一种共识算法?

有疑惑的最好办法就是去看阅读源码,理清实现机制。于是我根据fabric 1.1的源码整理了下面的内容。希望通过具体的实现来回答这个问题。

Kafka共识的组成部分

fabric 1.1中的共识包括三个部分:

1. Chain。 这里的chain跟我们说的区块链中的链不是同一个概念,这里的Chain是在排序中,注入消息的一种方法。是一个接口。为了在实现上更方便,Chain负责排序消息,通过blockcutter把消息分块,之后发送消息,最后写入账本。Chain支持两种处理流程:

消息排序后放入数据流中,然后把数据流切成块,提交块到账本。solo和kafka是基于这种方式

把消息新切成块,排序块,之后把块提交。sbft用的是这种方式。

2. Consenter。可以理解为kafka的broker。包括了:broker的配置,重试机制,tls配置以及kafka的版本信息。Consenter通过生成Chain来定义整个排序机制。

3. ConsenterSupport。对Consenter操作的一个封装。包括了如:blockCutter,创建下一个block,把block写入账本,写配置信息块到账本等操作。

Kafka共识的流程

kafka的运行过程如下:

1. 会通过Chain Start方法启动Chain,这个方法主要是首先初始化 生成者,消费者和kafka中的Connect。之后等待消费者队列中的消息。

2. 有消息过来要求排序

先序列化这个消息中带签名的payload

把序列化后的数据封装成一个kafka消息格式的数据包

对kafkfa消息格式的数据包再次序列化

生成要发送的生产者数据包,这个包是指定的channel下的生成者的包

生产者(异步)发送这个消息

3. 消费者从生产者队列中获取到消息后,这个时候,Chain的Start方法拿到了要处理的消费者数据。

反序化消费者消息

根据消息的类型进行处理,消息有KafkaMessage_Connect,KafkaMessage_TimeToCut,KafkaMessage_Regular消息。

4. 处理KafkaMessage_Regular消息

根据配置序列号,查看当前是否还有未处理的消息,如果有,根据当前是系统管道还是应用管道,进行消息的有效性验证。

把这个消息根据 2 的处理步骤进行排序

所有消息都已经重新验证了,这个时候需要进行提交块操作

5. 提交块操作

分包操作。把当前消息的大小和还未处理,处于pending的消息包根据配置的块大小进行分包

把第一个包封装成块

使用blockwriter 把块,连同签名信息一起写入账本

写在最后

上面是从fabric角度来分析,可以看出kafka在fabric中起的很大一部分作用都是在保证数据的队列化和顺序性。而从kafka角度来说,kafka 在架构层面上给出了如下的保证:

由生产者发送到一个指定topic分区中是有序的。比如,记录M1和M2都是同一个生产者发送,M1比M2先发送,那么M1在日志中的偏移值就比M2更小(在M2的前面)

消费者实照存储在日志中的顺序查看记录。类似于队列的先进先出

对于一个topic的N个备份,可以容忍n-1的服务失败而不会导致数据丢失

从上面可以看出:分区,有序,容错是kafka的三个特性。这里的有序是说在一个分区中的消息被某一个消费者消费时,消息是有序的。换句话说,也就是说对于一个消费者来说,在一个分区内的所有消息是有序的。但是不保证不同分区的数据是有序的。

也正由于这三个特性,可以使用kafka来作为一种“简单粗暴”的共识算法。这里再次强调下共识的定义,所谓的共识是指:在一个时间段内对事物的前后顺序达成共识的一种算法。

kafka的分区有序就保证了kafka可以作为一种共识算法。从工程角度,这种共识算法的安全性较低。但是由于Fabric引入了比较强的身份管理机制,在一定程度上加强了整个系统的安全等级。

赶快来分享关注吖

蜗牛讲技术,满满的都是干货,你值得关注。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180902G0RLO700?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券