这是我参与「第五届青训营」伴学笔记创作活动的第 9 天，本文章主要介绍了BMQ消息队列的流程与结构。

Kafka存在的问题总结

因为有数据复制的问题存在，所以Kafka运维的时间成本和人力成本都不低
对于负载不均衡的场景，我们需要有一个较为复杂的解决方案进行数据迁移，从而来权衡IO升高的问题
没有自己的缓存，完全依赖Page Cache
Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降

BMQ简介

兼容Kafka协议，存算分离，云原生消息队列

架构

Producer->Consumer->Proxy->Broker->HDFS->Controller->Coordinator->Meta

运维操作对比

重启、替换、扩容、缩容； Kafka需要天级完成，BMQ需要秒级完成。

HDFS写文件流程

首先客户端写入前会随机选择一定数量的DataNode，这个数量是副本数，然后将一个文件写入到这三个节点上，切换到下一个segment之后，又会重新选择三个节点进行写入。这样一来，对于单个副本的所有segment来讲，会随机的分配到分布式文件系统的整个集群中。

BMQ文件结构

对于Kafka分片数据的写入，是通过先在Leader上面写好文件，然后同步到Follower上，所以对于同一个副本的所有Segment都在同一台机器上面，就会存在之前我们所说到的单分片过大导致负载不均衡的问题，但在BMQ集群中，因为对于单个副本来讲，是随机分配到不同的节点上面的，因此不会存在Kafka的负载不均衡问题。

Broker-Partition状态机

保证对于任意分片在同一时刻只能在一个Broker上存活

多机房部署

Proxy->Broker->Meta->HDFS

BMQ-高级特性

泳道->Databus->Mirror->Index->Parquet

泳道消息

BOE:Bytedance Offline Environment，是一套完全独立的线下机房系统 PPE:Product Preview Environment，即产品预览环境

开发->BOE->PPE->Prod

Databus

简化消息队列客户端复杂度
解耦业务与Topic
缓解集群压力，提高吞吐

Mirror

使用Mirror通过最终一致的方式，解决跨Region读写问题

Index

如果希望通过写入的Logld、UserId或者其他的业务字段进行消息的查询，应该怎么做？

直接在BMQ中将数据结构化，配置索引DDL，异步构建索引后，通过Index Query服务读出数据

Parquet

Apache Parquet是Hadoop生态圈中一种新型列式存储格式，它可以通过兼容Hadoop生态圈中大多数计算框架，被多种查询引擎支持。

消息队列 2 | 青训营笔记