这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天
今天整理了消息队列中BMQ的相关学习笔记。
BMQ简介
兼容Kafka协议，存算分离，云原生消息队列。
BMQ介绍
运维操作对比
HDFS写文件流程
BMQ文件结构
对于Kafka分片数据的写入，是通过在Leader上面写好文件，然后同步到Follower上，所以对于同一个副本的所有Segment都在同一台机器上面。就会存在单片过大导致负载不均衡的问题，单在BMQ集群中，因为对于单个副本来讲，是随机分配到不同的节点上面的，因此不会存在Kafka的负载不均问题。
Broker-Partition 状态机
其实对于写入的逻辑来说，我们还有一个状态机的机制，用来保证不会出现同一个分片在两个 Broker.上同时启动的情况，另外也能够保证一个分片的正常运行。首先，Controller做好分片的分 配之后，如果在该Broker分配到了Broker,首先会start这个分片，然后进入Recover状态，这个状 态主要有两个目的获取分片写入权利，也就是说，对于hdfs来讲， 只会允许我一个分片进行写入， 只有拿到这个权利的分片我才能写入，第二一个目的是如果上次分片是异常中断的，没有进行save checkpoint,这里会重新进行一次save checkpoint,然后就进入了正常的写流程状态，创建文件， 写入数据，到一定大小之后又开始建立新的文件进行写入。
Broker-写文件流程
数据校验: CRC ,参数是否合法 校验完成后，会把数据放入Buffer中 通过一个异步的Write Thread线程将数据最终写入到底层的存储系统当中 这里有一个地方需要注意一下， 就是对于业务的写入来说，可以配置返回方式，可以在写完缓存之后直接返回，另外我也可以数据真正写入存储系统后再返回，对于这两个来说前者损失了数据的可靠性，带来了吞吐性能的优势，因为只写入内存 是比较快的，但如果在下一次flush前发生宕机了，这个时候数据就有可能丢失了，后者的话，因为数据已经写入了存储系统，这个时候也不需要担心数据丢失，相应的来说吞吐就会小一些 我们再来看看Thread的具体逻辑，首先会将Buffer中的数据取出来，调用底层写入逻辑，在-定的时间周期 上去lush, flush完成后开始建立Index,也就是offset和timestamp对于消息具体位置的映射关系 Index建立好以后，会save- -次checkpoint,也就表示，checkpoint后的数据是可以被消费的辣，我们想一下， 如果没有checkpoint的情况 下会发生什么问题，如果flush完成之 后宕机，index还没有建立，这个数据是不应该被消费的 最后当文件到达一定大小之后，需要建立-一个新的segment文件来写入
