前言：
本笔记主要记录了学习消息队列相关知识的内容，因篇幅较长将Kafka和BMQ、RocketMQ拆分为两篇笔记
本文主要为BMQ、RocketMQ相关内容
关于BMQ
什么是BMQ
字节跳动自主研发的消息队列，是一个兼容Kafka协议，存算分离，云原生的消息队列。
- 新增Proxy层作为代理
- Coordinator和Controller可以独立部署
- 底层新增HDFS用于存算分离
与Kafka对比
| 具体操作 | Kafka | BMQ |
|---|---|---|
| 重启 | 需要数据复制，分钟级重启 | 重启后可直接对外服务，秒级完成 |
| 替换 | 需要数据复制，分钟级替换，甚至天级别 | 替换后可直接对外服务，秒级完成 |
| 扩容 | 需要数据复制，分钟级扩容，甚至天级别 | 扩容后可直接对外服务，秒级完成 |
| 缩容 | 需要数据复制，分钟级缩容，甚至天级别 | 缩容后可直接对外服务，秒级完成 |
实际上对于所有节点变更的操作，都仅仅只是集群元数据的变化，通常情况下都能秒级完成，而真正的数据已经移至下层分布式文件存储去了，所以运维操作不需要额外关心数据复制所带来的时间成本
- 对于Kafka分片数据的写入，是通过先在Leader上面写好文件，然后同步到Follower上，所以对于同一个副本的所有Segment都在同一台机器上面，就会存在前面所说的单分片过大导致负载不均衡的问题。
- 但在BMQ集群中，因为对于单个副本来说，是随机分配到不同的节点上面的，因此不会存在Kafka的负载不均衡问题。
BMQ读写流程
-
Failover机制
- 当节点出现问题导致不能正常写入时，更换节点创捷新文件进行写入，这样保证了写入的可用性。
-
写入状态机：（用于保证不会出现同一个分片在两个Broker上同时启动的情况）
- 在Controller做好分片的分配后，首先会start这个分片，然后进入Recover状态。这个状态主要有两个目的：获得分片写入权限；在异常中断的情况下，重新进行一次save checkpoint ，便进入正常的写流程状态：创建文件，写入数据，到一定大小后又开始建立新的文件进行写入。
BMQ高级特性
泳道 、Databus、Mirror、Index 、Parquet……
关于RocketMQ
RocketMQ 是阿里出品的消息队列，针对电商业务线，其业务涉及广泛，如注册、订单、库存、物流等；同时，也会涉及许多业务峰值时刻，如秒杀活动、周年庆、定期特惠等。
基本架构
- 与Kafka相似，有Producer，Consumer，Broker这三个部分
- Kafka中Partition的概念在RocketMQ叫做ConsumerQueue
- 数据流通过Producer发送给Broker集群，再由Consumer进行消费
- Broker节点有Master和Slaver的概念
- NameServer为集群提供轻量级服务发现和理由
高级特性
RocketMQ 提供了一些高级特性，支持事务，支持延迟消息，支持消息重试和死信队列。
在实际地应用中，库存服务和消息队列需要在一个事务内来保证 ACID 特性，事务的支持使得 RocketMQ 可以很好地应对购物场景。
