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

消息队列

入门

问题->解决方案

系统崩溃->解耦

服务处理能力有限->削峰

链路耗时长尾->异步

日志如何处理->消息队列

消息队列：保存消息的容器，本质是一个队列，支持高吞吐、高并发、高可用

发展历程：

TIB->IBM MQ\WebSphere->MSMQ->JMS->AMQP\RabbitMQ->Kafka->RocketMQ->Pulsar

常见消息队列组件：

Kafka：分布式、分区、多副本的日志提交服务，适用于高吞吐场景

RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量、灵活的扩展性、适用于实时场景

Pulsar：云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计

BMQ：与Pulsar架构类似，存算分离，逐步替换掉Kafka集群

Kafka

使用场景

主要为离线消息处理（日志信息、Metrics处理、用户行为）

使用方法

创建集群->新增Topic->编写生产者逻辑->编写消费者逻辑

Topic：逻辑队列，可以理解为一个独立的业务

Partition：Topic的一个分区，一个Topic可以有多个分区，不同分区消息可以并发处理

Offerset：消息在Partition中的相对位置，可以理解为消息的唯一id，在Partition中严格递增

Replica（副本）：每个Partition有多个Replica，Leader Replica从ISR中选出，提高容错性

Cluster：物理集群，可以建立多个不同的Topic

Producer：生产者，将业务消息发送到Topic

Consumer：消费者，消费Topic中的消息

ConsumerGroup：消费者组，不同组的Consumer消费进度互不干涉

Zookeeper：负责存储集群元信息，包括分区分配信息等

高吞吐+稳定性

Producer：消息池机制，支持批量发送，有效减少IO次数、数据压缩机制，减少消息大小， 支持Snappy、Gzip、LZ4、ZSTD压缩算法

Broker：顺序写机制，提高写入效率、二分查找+稀疏索引，提高读取效率、零拷贝（数据从磁盘进入内核空间，直接发送到消费者，无需经过应用空间）

Consumer：手动分配（在代码中人工写好分配方式，存在缺陷 -> Rebalance 自动分配（选取一台Broker作为Coordinator，负责协调工作）

缺点

运营成本高、对于负载不均衡的场景，解决方案复杂、没有自己的缓存，完全依赖Page Cache、Controlle和Coordinator和Broker在同一进程中，大量IO导致性能下降

BMQ

兼容Kafka协议、存算分离、云原生消息队列

运维操作

相较于Kafka（分钟级，甚至天级），在重启、替换、扩容、缩容都是秒级完成

HDFS写文件流程

随机选取一定数量的DataNode（数据节点）进行写入，实现负载均衡

Broker-Partition状态机

保证对于任意分片在同一时刻只能在一个Broker上存活

高级特性

BOE：完整独立的线下环境

PPE：产品预览环境

泳道消息：解决主干泳道流量隔离问题以及泳道资源重复创建问题

Databus：简化消息队列客户端复杂度、解耦业务与Topic、缓解集群压力，提高吞吐

Mirror：多机房部署在跨区域读写操作中延迟较高，进入Mirror机制，本质是最终一致性

Index：提供反查数据功能

Parquet： Apache Parquet是Hadoop生态圈中的一种新型列式存储格式，兼容Hadoop、Spark等计算框架，被Hive、Impala、Drill等查询引擎支持