这是我参与「第五届青训营 」伴学笔记创作活动的第 14 天

前言

个人对这节课的理解是，更加侧重的是架构层面的理解，其实难度蛮大的，我感觉我的笔记整理的也不是很好，后续再进行一定的优化吧

BMQ简介

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

初步定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群

BMQ架构

文字叙述可以是：

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

其中，Proxy和Broker为无状态

运维架构对比

具体操作	Kafka	BMQ
重启	需要数据复制，分钟级重启	重启后可以直接对外服务，秒级完成
替换	需要数据复制，分钟级甚至天级别替换	替换后可以直接对外服务，秒级完成
扩容	需要数据复制，分钟级甚至天级别扩容	扩容后可以直接对外服务，秒级完成
缩容	需要数据复制，分钟级甚至天级别缩容	缩容后可以直接对外服务，秒级完成

BMQ与Kafka文件结构对比

对于Kafka分片数据的写入，是通过先在Leader上面写好文件，然后同步到Follower上，对于同一个副本的所有Segment都在同一台机器上面。就会存在之前我们所说的单分片过大导致负载不均衡的问题。

但是在BMQ集群中，因为对于单个副本来讲，是随机分配到不同的节点上的，因此不会窜爱Kafka负载不均的问题

Broker-Partition状态机

对于写入过程而言，实际上还有一个状态机的机制，用于保证不会出现同一个分片在两个Broker上同时重启的情况，同时也能保证一个分片的正常运行。

首先，Controller做好分片的分配后，如果在这个Broker分配到了Broker，首先会启动这个分片，然后进入Recover状态，这个状态主要有两个目的的获取分片写入权利。

也就是说，对于HDFS而言，只会允许我一个分片进行写入，只有拿到这个权利的分片才能写入。

第二个目的是，如果上次分片是异常中断的，没有进行save&checkpoint，这里会重新进行一次save&checkpoint，然后就进入了正常的写流程状态：创建文件、写入数据，到一定大小后又开始建立新的文件进行写入

一些小结

• BMQ的架构模型旨在解决Kafka存在的问题（运维成本高、负载不均衡等）
• BMQ的读写流程为Failover机制和写入状态机
• BMQ具备一些高级特性：泳道、Databus、Mirror、Index、Parquet）