一、基于Kafka的order服务
分布式的排序服务
基于Kafka的排序服务利用Kafka作为交易的消息队列,实现高吞吐量的数据分发。
每个通道都对应Kafka的一个主题(topic)。
排序服务节点在不同阶段充当不同的角色。
1. 接收交易阶段:
排序服务节点充当的是Kafka的生产者 (producer),接收到交易后转发给对应通道的主题。
2. 消息处理阶段:
排序服务节点充当的是Kafka的消费者 (consumer),实时监听消息进行后续的处理,生成区块或者交易分割消息等。
二、基于Kafka的order最佳实践
1. Kafka和Zookeeper的节点数
Kafka的节点数是K
Zookeeper的节点数是Z
K最少需要4个节点
才可以在1个节点宕机以后还能继续提交交易,排序和创建新的通道。
Z选择3、5或7个节点都可以。
选择奇数个节点可以避免脑裂,1个 节点会存在单点问题,7个 以上的节点就太多了。
三、实践所需的yaml文件
docker-compose-cli.yaml
docker-compose-base.yaml
peer-base.yaml
docker-compose-couch.yaml
dc-orderer-kafka-base.yml
dc-orderer-kafka.yml
四、数据持久化
容器 |
容器内路径 |
宿主机路径 |
peer |
/var/hyperledger/production |
./p0o1 |
orderer |
/var/hyperledger/production/orderer |
./orderer0 |
kafka |
/tmp/kafka-logs |
./k0 |
couchdb |
/opt/couchdb/data |
./c0 |
五、Kafka的配置
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
是否允许不在副本同步集合中的节点选举为主节点,主节点负责消息的读写。
一条消息只有在 副本同步集合中所有的节点都同步完成才算提交成功。
如果允许不在同步集合中的节点选举为 主节点,就有数据丢失的风险。