这是我参与「第五届青训营 」伴学笔记创作活动的第 6 天
- BMQ：兼容Kafaka，存算分离，云原生消息队列
- BMQ架构：proxy和broker都是无状态的
- producer-->comsumer-->proxy-->broker-->HDFS-->controller-->coodinator-->meta
- HDFS写文件流程
- 一个副本由多个segment组成。客户端会按照副本数选择一定的datanode，将文件写在这些datanode上面，之后选择segment重复以上操作
- kafaka和BMQ数据文件对比：
- kafaka数据文件的写入：先在leader上面写好文件，同步到follower上面。同一个副本的所有segment在一台机器上；会出现负载不均衡的事情
- BMQ：对于单个副本来说，是随机分配到不同节点上面的
- BMQ写文件失败如何处理：
- 在写文件时，会选择与副本数量相同的datanode写文件，当有一个node宕机时，可以选择一个节点替换该节点写入文件
- 使用场景
- 可以用来处理高并发的业务场景：秒杀活动、周年庆、定期优惠等等
- kafaka和BMQ相关概念对比
- 数据流移动
producer-->broker-->consumer,其中broker又包括master和slave，slave提供轻量级服务发现和路由
- 消息存储模型：
对于一个broker来说，所有的消息会append在一个commitlog上面，按照不同的queue，重新dispatch在不同的consumer中，这样consumer就可以按照queue进行消费了。
consumerqueue存储的数据不是真实的数据，相当于保存在commitlog中数据的一个索引
