这是我参与「第五届青训营 」伴学笔记创作活动的第 17 天
课程概要
- 消息队列的前世今生
- 消息队列-Kafka
- 消息队列-BMQ
- 消息队列-RocketMQ
- 最佳实践
消息队列-BMQ
BMO容Kaka协议，存算分离，云原生消息队列，初期定位是承接高吞的离业务场景，逐步替换掉对应的Kaka集群
运维操作对比
-
重启
- Kafka：需要数据复制，分钟级重启
- BMQ：重启后可直接对外服务，秒级完成
-
替换
- Kafka：需要数据复制，分钟级替换，甚至天级别
- BMQ：替换后可直接对外服务，秒级完成
-
扩容
- Kafka：需要数据复制，分钟级扩容，甚至天级别
- BMQ：扩容后可直接对外服务，秒级完成
-
缩容
- Kafka：需要数据复制，分钟级缩容，甚至天级别
- BMQ：缩容后可直接对外服务，秒级完成
HDFS 写文件流程
随机选择一定数量的DataNode进行写入
- 同一个副本是多个segment组成，我们来看看BMQ对于单个文件写入的机制是怎么样的，首先客户端写入前会选择一定数量的DataNode，这个数量是副本数，然后将一个文件写入到这三个节点上，切换到下一个segment之后，又会重新选择三个节点进行写入。这样一来，对于单个副本的所有segment来讲，会随机的分配到分布式文件系统的整个集群中
Broker-写文件流程
- 先进行数据校验: CRC，参数是否合法
-
校验完成后，会把数据放入Buffer中通过一个异步的Write Thread线程将数据最终写入到底层的存储系统当中
-
对于业务的写入来说，可以配置员返回方式，可以在写完缓存之后直接返回，也可以数据真正写入存储系统后再返回，对于这两个来说：
- 前者损失了数据的可靠性，带来了吞吐性能的忧势，因为只写入内存是比较快的，但如果在下一次flush前发生宕机了，这个时候数据就有可能丢失了
- 后者的活，因为数据已经写入了存储系统，这个时候也不需要担心数据丢失，相应的来说吞吐就会小一些
-
TIhread的具体逻辑：
- 首先会将Buffer 中的数据取出来，调用底层写入逻辑 ，在一定的时间周期上flush，flush完成后开始建立index，也就是offset和timestamp对于消息具位置的映射关系
- index建立好以后，会save一次checkpoint，也就表示checkpoint后的数据是可以被消费的，如果flush完成之后宕机，index还没有建立，这个数据是不该被消费的
-
最后当文件达到一定大小之后，需要建立一个新的segment文件来写入
