Hyperledger Fabric教程（15）--基于Kafka的Order服务实战

本文主要是介绍Hyperledger Fabric教程（15）--基于Kafka的Order服务实战，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

分布式的排序服务

基于Kafka的排序服务利用Kafka作为交易的消息队列，实现高吞吐量的数据分发。

每个通道都对应Kafka的一个主题（topic）。

排序服务节点在不同阶段充当不同的角色。

1. 接收交易阶段：

排序服务节点充当的是Kafka的生产者 （producer），接收到交易后转发给对应通道的主题。

2. 消息处理阶段：

排序服务节点充当的是Kafka的消费者 （consumer），实时监听消息进行后续的处理，生成区块或者交易分割消息等。

1. Kafka和Zookeeper的节点数 

Kafka的节点数是K 

Zookeeper的节点数是Z

K最少需要4个节点

才可以在1个节点宕机以后还能继续提交交易，排序和创建新的通道。

Z选择3、5或7个节点都可以。

选择奇数个节点可以避免脑裂，1个 节点会存在单点问题，7个 以上的节点就太多了。

docker-compose-cli.yaml

docker-compose-base.yaml

peer-base.yaml

docker-compose-couch.yaml

dc-orderer-kafka-base.yml

dc-orderer-kafka.yml

min.insync.relicas = 2 (M)

至少写入的副本数，一个消息写入副本的个数不小于这个数才确认写入成功。

这个值越大系统 越可靠，越小性能越高。

这里设置2的原因是避免单点故障。

default.relication.factor = 3 (N)

创建主题时保存的副本数，创建通道时需要有至少N个节点同步完成数据才能创建成功。

N的 值需要满足 1<M<N<K , N<K原因是K需要有一个节点的冗余。

unclean.leader.clection.enable = false

是否允许不在副本同步集合中的节点选举为主节点，主节点负责消息的读写。

一条消息只有在 副本同步集合中所有的节点都同步完成才算提交成功。

如果允许不在同步集合中的节点选举为 主节点，就有数据丢失的风险。

这篇关于Hyperledger Fabric教程（15）--基于Kafka的Order服务实战的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！