BMQ简介
1.BMQ兼容Kafka协议，存算分离，云原生消息队列，解决了Kafka的很多问题。 2.BMQ新增了Proxy层作为代理； 3.Coordinator 和 Controller 可以独立部署； 4底层新增 HDFS 用于存算分离。
BMQ架构图
基本链路是: Producer -> Consumer -> Proxy -> Broker -> HDFS -> Controller -> Coordinator -> Meta
运维操作对比
| 具体操作 | Kafka | BMQ |
|---|---|---|
| 重启 | 需要数据复制，分钟级重启 | 重启后可直接对外服务，秒级完成 |
| 替换 | 需要数据复制，分钟级替换，甚至天级别 | 替换后可直接对外服务，秒级完成 |
| 扩容 | 需要数据复制，分钟级扩容，甚至天级别 | 扩容后可直接对外服务，秒级完成 |
| 缩容 | 需要数据复制，分钟级缩容，甚至天级别 | 扩容后可直接对外服务，秒级完成 |
通过对比可以知道，BMQ会比Kafka速度快很多，所有节点变更的操作，都仅仅只是集群元数据的变化，通常情况下都能秒级完成，而真正的数据已移到下层分布式文件存储去了，所以运维操作不需要额外关心数据复制带来的时间成本。
HDFS写文件流程
通过前面的介绍，我们知道了，同一个副本是由多个segment组成，我们来看看BMQ对于单个文件写入的机制是怎么样的，首先客户端写入前会选择一定数量的DataNode，这个数量是副本数，然后将一个文件写入到这三个节点上，切换到下一个segment之后，又会重新选择三个节点进行写入。这样一来，对于单个副本的所有segment来讲，会随机的分配到分布式文件系统的整个集群中。
文件结构
对于Kafka分片数据的写入，是通过现在Leader节点上写好文件，然后同步到Follower上，所以对于同一个副本的所有Segment都在同一台机器上面。就会存在之前我们所说到的单分片过大导致负载不均衡的问题，但在BMQ集群中，因为对于单个副本来说，是随机到不同的节点上面的，因此不会存在Kafka的负载不均问题。
