这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天
1 Why Message Queue?
1.1 服务崩溃：
整个服务链路中一环出现问题，导致服务全部消息丢失
1.2 服务能力有限：
一个秒杀活动，短时间内挤入大量请求，服务器响应不过来
1.3 链路长尾问题
1.4 日志存储
避免重要日志丢失
1.5 历程
-
Kafka:
分布式、分区、多副本的日提交，在高吞吐场景下发挥出色
-
RocketMQ:
低延迟、强一致、高性能、高可靠、万亿级容量和灵活性可扩展性
-
Pulsar:
是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构
-
BMQ:
和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的 Kafka集群
2. 主要消息队列介绍
3.1 Kafka
3.1.1 如何使用
发布 - 订阅模式 ： 创建集群 --> 新增 Topic --> 编写生产者逻辑 --> 编写消费者逻辑
- 每个分片(Partition) 都有多个副本 Replica, Leader Replica 从 ISR （In Sync Replica）中选出。
3.1.2 kafka 架构
架构图：
数据分区复制：
3.1.3 消息发送：
批量发送，减少 I/O耗时、 压缩消息，减小消息大小。
Broker消息文件结构：
数据路径：/Topic/Partition/Segment/(log/index/timeindex)
3.1.4 消息接受：
引入 Coordinator 进行自动分配分区, 新增或删减 consumer, 会进行 Rebalance
3.1.5 kafka 重启
- Leader 回切目的：假设有 100 个集群， 前 99 个节点需要不停的重启，如果Leader不回切，那么所有 Topic 的Leader都会堆积到了 第 100 集群节点上，导致该集群节点读写压力非常大。
3.2 BMQ
兼容 kafka 协议，存算分离，云原生消息队列
3.2.1 架构
Proxy 是无状态的，消息不做任何处理，直接传给 Broker
3.2.2 文件结构 （HDFS）
可对比下与 kafka 的区别， BMQ 中每一个 segment 都随机分配到不同数量的 DataNode, 而不像 kafka，同一个 Partition 的全部分配到一个节点。
