这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天
简介
BMQ：Byte Message Queue (我猜的)
是由字节跳动自主研发的消息队列
由于是字节自研的所以找到的资料不太多
简单来说，BMQ就是一个兼容Kafka协议，存算分离，云原生消息队列，他的初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。主要就是为了分担一部分Kafka集群的功能，减轻Kafka的压力，用于离线计算
接下来，我们来了解一下BMQ的架构特点
架构介绍
下图是BMQ的架构图
基本链路是: Producer -> Consumer -> Proxy -> Broker -> HDFS -> Controller -> Coordinator -> Meta
这里着重强调以下 Proxy 和 Broker 无状态，为虾米进行运维方面比较做铺垫。
运维操作对比
| 具体操作 | Kafka | BMQ |
|---|---|---|
| 重启 | 需要数据复制，分钟级重启 | 重启后可直接对外服务，秒级完成 |
| 替换 | 需要数据复制，分钟级替换，甚至天级别 | 替换后可直接对外服务，秒级完成 |
| 扩容 | 需要数据复制，分钟级扩容，甚至天级别 | 扩容后可直接对外服务，秒级完成 |
| 缩容 | 需要数据复制，分钟级缩容，甚至天级别 | 缩容后可直接对外服务，秒级完成 |
上表是Kafka与BMQ在运维层面的操作速度对比，很明显可以看出，BMQ比Kafka快了整整几个数量级，可见BMQ的架构设计和性能的优化
实际上对于BMQ来说，所有节点变更的操作，都仅仅只是集群元数据的变化，通常情况下都能秒级完成，而真正的数据已移到下层分布式文件存储去了，所以运维操作不需要额外关心数据复制带来的时间成本。
HDFS 写文件流程
通过前面的介绍，我们知道了，同一个副本是由多个segment组成，我们来看看BMQ对于单个文件写入的机制是怎么样的，首先客户端写入前会选择一定数量的DataNode，这个数量是副本数，然后将一个文件写入到这三个节点上，切换到下一个segment之后，又会重新选择三个节点进行写入。这样一来，对于单个副本的所有segment来讲，会随机的分配到分布式文件系统的整个集群中
文件结构
对于Kafka分片数据的写入，是通过现在Leader节点上写好文件，然后同步到Follower上，所以对于同一个副本的所有Segment都在同一台机器上面。就会存在之前我们所说到的单分片过大导致负载不均衡的问题，但在BMQ集群中，因为对于单个副本来说，是随机到不同的节点上面的，因此不会存在Kafka的负载不均问题
Broker-Partition 状态机
其实对于写入的逻辑来说，我们还有一个状态机的机械，用来保证不会出现同一个分片在两个Broker上同时启动的情况，保证对于任意分片在同一时刻只能在一个Broker上存活，同时也能保证一个分片的正常运行。如果在该Broker分配到了Broker，首先会start这个分片，然后进入Recover状态，这个状态主要有两个目的，获取分片写入权力，也就是说，对于hdfs来说，只会允许我一个分片进行写入，只有拿到这个权力的分片我才能写入，第二个目的是如果上次分片是异常中断的，没有进行save checkpoint，这里会重新进行一次save checkpoint，然后就进入了正常的写流程，创建文件，写入文件，到一定大小之后又开始建立新的文件的写入。
