【青训营笔记】- 「消息队列原理与实战」这是我参与「第五届青训营」笔记创作活动的第13天。前言本节课将重点讲解消息

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

前言

本节课将重点讲解消息队列应用场景、发展历史以及常见消息队列类型，帮助大家更好地了解消息队列。

场景代入

案例一：系统崩溃。假如数据都是从数据库中查询的，那么如果此时记录存储程序所在的机房被删库跑路了，上面这个流程会发生什么问题?
案例二：服务能力有限。只能同时处理10订单请求，面对庞大的请求量，处理订单的服务一脸茫然，它的命运该何去何从?
案例三：链路耗时长尾。对于一些耗时的操作，导致用户看不到最终的结果就放弃了。
案例四：日志存储。日志如何处理？

场景解决

案例一：解耦
案例二：削峰。把消息放入消息队列，每次只取出适当的请求进行处理
案例三：异步。把图中一些耗时的操作都进行异步处理，可能更快返回结果。
案例四：日志处理。

什么是消息队列？

消息队列（MQ）,指保存消息的一个容器，本质是个队列。但这个队列呢，需要支持高吞吐，高并发，并且高可用消息队列 (MQ)

一、前世今生

1.1 消息队列发展历程

1.2 业界消息队列对比

Kafka: 分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色
RocketMQ: 低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广
Pulsar: 是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体.采用存算分离的架构设计
BMQ: 和Pulsar架构类似存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群

二、消息队列-Kafka

2.1 使用场景

搜索服务
直播服务
订单服务
支付服务
日志信息、Metrics数据、用户分析

2.2 如何使用Kafka

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

2.3 基本概念

Topic: 逻辑队列，不同 Topic 可以建立不同的
TopicCluster: 物理集群，每个集群中可以建立多个不同的 Topic
Producer: 生产者，负责将业务消息发送到 Topic 中
Consumer: 消费者，负责消费 Topic 中的消息
ConsumerGroup: 消费者组，不同组 Consumer 消费进度互不干涉
Offset: 消息在 partition 内的相对位置信息，可以理解为唯-ID，在 partition 内部严格递增.
Replica：每个分片有多个 Replica，Leader Replica 将会从 ISR 中选出

2.4 一条消息的自述

从一条消息的视角，看看为什么 Kafka 能支撑这么高的吞吐?

Producer: 批量发送。批量发送可以减少IO次数，从而加强发送能力
Producer：通过压缩，减少消息大小，目前支持Snappy、Gzip、LZ4、ZSTD压缩算法
Broker:消息文件结构.
Broker:磁盘结构。顺序写。移动磁头找到对应磁道，磁盘转动，找到对应扇区，最后写入。寻道成本比较高，因此顺序写可以减少寻道所带来的时间成本。

2.5 寻找数据

Consumer 通过发送 FetchRequest 请求消息数据，Broker 会将指定 Offset 处的消息，按照时间窗口和消息大小窗口发送给 Consumer，寻找数据这个细节是如何做到的呢?

Broker:偏移量索引文件。二分找到小于目标 offset 的最大索引位置
Broker 时间戳索引文件。二分找到小于目标时间戳最大的索引位置，在通过寻找 offset 的方式找到最终数据

2.6 零拷贝

将磁盘中的数据直接发送给网卡，而不用从内核空间拷贝到用户空间，再发送到网卡。
写入也有类似的效果，减少IO耗时

2.7分配

手动分配Consumer-Low Level

通过手动进行分配，哪一个 Consumer消费哪一个 Partition 完全由业务来决定

自动分配Consumer-High Level

Rebalance

2.8 小结

刚刚总共讲了哪一些可以帮助Kafka提高吞吐或者稳定性的功能?

Producer: 批量发送、数据压缩
Broker: 顺序写，消息索引，零拷贝
Consumer: Rebalance

问题：

数据复制问题
重启操作
替换、扩容、缩容问题
负载不均衡，解决方案复制
运维成本高
没有自己的缓存，完全依赖Page Cache
Controller 和 Coordinator和Broker 在同一进程中，大量 IO会造成其性能下降

三、消息队列-BMQ

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

HDFS写文件流程
BMQ文件结构
Broker-Partition 状态机
Broker-写文件 Failover
Proxy
多机房部署
BMQ-高级特性
泳道消息：解决主干泳道流量隔离问题以及泳道资源重复创建问题
Databus:
- 解决客户端配置较为复杂，不支持动态配置，更改配置需要停掉服务，对于 latency 不是很敏感的业务，batch 效果不佳等问题
- 简化消息队列客户端复杂度，解耦业务与 Topic，缓解集群压力，提高吞吐
Mirror
Index

四、消息队列- RocketMQ

4.1 使用场景

例如，针对电商业务线，其业务涉及广泛，如注册、订单、库存、物流等;同时也会涉及许多业务峰值时刻，如秒杀活动、周年庆、定期特惠等

【青训营笔记】- 「消息队列原理与实战」

前言