这是我参与「第五届青训营」笔记创作活动的第13天

一. 重点内容

消息队列的发展
消息队列 - Kafka
消息队列 - BMQ
消息队列 - RocketMQ

二. 知识点介绍

1. 消息队列的历史

业界消息队列对比：
- kafka：分布式、分区、多副本的日志提交服务，适合高吞吐场景
- RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的扩展性，适合实时场景
- pulsar：下一代云原生分布式消息流平台，集信息、存储、轻量化函数式为一体、采用存算分离的架构设计
- BMQ：存算分离，初步定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群

2. 消息队列 - Kafka

使用场景：搜索服务、直播服务、订单服务、支付服务、日志信息、用户行为、Metrics数据
基本概念：
- Topic：逻辑队列
- Cluster：物理集群，每个集群可以建立多个不同的Topic
- Producer：生产者，负责将业务消息发送到Topic中
- Consumer：消费者，负责消费Topic中的消息
- ConsumerGroup：消费者组。不同组Consumer消费进度互不干涉
- Offset：消费在partition内的相对位置信息，相当于唯一ID，在partition内部严格递增
- Replica：每个分片有多个Replica，Leader Replica将会从ISR中选出
数据复制：
架构：
Producer：
- 批量发送：减少I/O次数，加强发送能力
- 数据压缩：减少消息大小，目前支持Snappy、Gzip、LZ4、ZSTD压缩算法
Broker：
- 消息文件结构：
- 磁盘结构：移动磁头找到对应磁道，磁盘转动，找到对应扇区，最后写入。寻道成本比较高，因此顺序写可以减少寻道所带来的时间成本
- 顺序写：提高写入效率
- 偏移量索引文件：二分找到小于目标offset的最大文件
- 时间戳索引文件：二分找到小于目标时间戳最大的索引位置，再通过寻找offset的方式找到最终数据
Consumer：
- 消息接收端：
- Low Level：通过手动进行分配，哪一个Consumer消费哪一个partition完全由业务决定
- High Level：Rebalance
Kafka重启操作：关闭重启 -> Leader切换，追赶数据 -> 数据同步完成 -> Leader回切
Kafka替换、扩容、缩容及负载不均衡：
- 缺点：运维成本高；对于负载不均衡的场景，解决方案复杂；没有自己的缓存，完全依赖Page Cache；Controller和Coordinator和Broker在同一进程中，大量I/O会造成性能下降

3. 消息队列 - RocketMQ

简介：兼容Kafka协议，存算分离，云原生消息对列
架构：
运维操作对比-Kafka vs BMQ：
HDFS写文件流程：随机选择一定数量的DataNode进行写入
Broker-Partition状态机：保证对于任意分片在同一时刻只能在一个Broker上存活
Broker写文件流程：
Proxy：
Databus：
- 简化消息队列客户端复杂度
- 解耦业务与Topic
- 缓解集群压力，提高吞吐
Index：直接在BMQ中将数据结构化，配置索引DDL，异步构建索引后，通过Index Query服务读出数据
Parquet：Apache Parquet是Hadoop生态圈中一种新型列式存储结构，可以兼容Hadoop生态圈的大多数计算框架，如Hadoop、Spark，被多种查询引擎支持，如Hive、Drill等