消息队列学习 ｜ 青训营笔记

一只兔兔
188 阅读8分钟

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

这里主要是，消息队列应用场景、发展历史以及常见消息队列类型的介绍，帮助大家更好地了解消息队列。已经实际使用方面相关的一些内容，走入到消息队列的世界中。

  • 一些令人崩溃的场景：

    • 系统崩溃

    image-20230124090402921

    • 服务处理能力有限
    • 链路耗时长尾

    image-20230124090439878

    • 日志如何处理

    image-20230124090513416

  • 消息队列：保存消息的一个容器，本质就是个队列，需要支持：

    • 高吞吐
    • 高并发
    • 高可用

前世今生

image-20230124090651341

  • 业内猛的MQ:

image-20230124090854684

RocketMQ阿里自研

PULSAR腾讯用的

BMQ字节用的，类似PULSAR

Kafka

  • 使用场景：

image-20230124091122345

  • 如何使用Kafka

    • 创建Kafka集群
    • 新建Topic & 分区数量
    • 引入SDK，编写生产者逻辑
    • 编写消费者逻辑。

基本概念

image-20230124091228943

  • Topic: 逻辑队列，不同Topic可以建立不同的Topic
  • Cluster: 物理集群，每个集群中可以建立多个不同的Topic
  • Producer: 生产者，负责将业务消息发送到Topic中
  • Consumer: 消费者，负责消费Topic中的消息
  • ConsumerGroup: 消费者组，不同组Consumer消费进度互不干涉
  • Partition: Topic的一个分区的概念，一个Topic有多个分区，不同分区的消息是可以并发处理的。可以提升单个Topic中，并发处理的能力。
  • Offset: 消息在Partition内的相对位置信息，可以理解为唯一ID，在Partition内，严格递增。

image-20230124091819504

  • Replica：每个分片有多个Replica，Leader Replica将会从ISR中选出。（容灾的时候用的昂！！！看到了熟悉的Leader/Follower结构。Leader宕机了，重新选一个Follower -> New Leader）

image-20230124091932766

数据复制

image-20230124092115751

第二个broker本身还担任Controller的角色，帮助我们计算副本的分配逻辑。（Controller的作用）

Kafka架构

image-20230124092231453

数据压缩&Batch Send

image-20230124092406254

Broker数据的存储

Broker消息文件结构

image-20230124092454858

顺序写，可以减少寻道所带来的时间成本

顺序写

image-20230124092619825

Broker数据的查找

image-20230124092703725

Broker偏移量索引文件

image-20230124092913203

image-20230124092943481

这里是稀疏索引，所以找到小于目标offset的最大文件，就能找到索引啦！！！

时间戳索引文件

offset上层加了一层时间戳索引

image-20230124093111063

通过时间戳进行文件索引

Broker数据的拷贝

传统数据拷贝

image-20230124093246682

很多数据拷贝

零拷贝

image-20230124093346501

Consumer消息的接收

consumer拉去哪个partition呢？

image-20230124093443278

  • 缺点：

    • 如果Consumer挂掉了，数据流就挂掉了，不能自动容灾。
    • 手动新增Consumer，也很难分配workload

High Level

image-20230124093556717

其中一个Broker充当Coordinator的角色，负责协调。

Coordinator，动态感知，并进行Partition的管理和动态分配。

Consumer Rebalance

  1. 第一轮请求：一开始Consumer不知道哪个是Coordinator。随机找一个broker，连接上，看看哪个是Coordinator

image-20230124093904163

  1. 第二轮请求：Consumer告诉Coordinator，自己要加入ConsumerGroup当中

image-20230124094043131

  1. Coordinator从Group中，选出一个Leader

image-20230124094222474

提供一些业务特性，选一个Leader

  1. 第三轮请求：发送集群同步请求，并且携带分配方案

image-20230124094318439

  1. 例如，心跳维持集群的链接，如果Coordinator和例如Consumer3的心跳断了，就自动Rebalance，去掉Consumer3，重新进行分配。

image-20230124094412586

帮助Kafka提高吞吐&稳定性总结

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

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

Kafka数据复制问题

重启操作

image-20230124094810563

替换、扩容、缩容

只要有集群节点的变动，就会产生数据复制的时间成本昂！（分片在变动嘛orz，唉，导致副本的迁移啊之类的，很多事情orz）

  • 负责不均衡也会在这个过程中产生

Kafka问题总结

  1. 运维成本高
  2. 对于负载不均衡的场景，解决方案复杂
  3. 没有自己的缓存，完全依赖Page Cache
  4. Controller 和Coordinator和Broker在同一进程中，大量I0会造成其性能下降

BMQ

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

介绍

image-20230124095640475

运维对比

image-20230124095727283

Broker和Proxy都是无状态，不和数据绑定，数据都在底层的HDFS中，运维非常快！！！

Partition状态机

image-20230124100020150

Broker写文件流程

image-20230124100135492

Proxy

image-20230124101306747

多机房部署

image-20230124101332333

高级特性

image-20230124101500183

泳道消息

BOE: Bytedance Offline Environment，PPE: Product Preview Enrionment

RD -> BOE -> PPE -> Prod

image-20230124101657018

image-20230124101720232

  • 泳道消息：

image-20230124101805994

泳道相当于创建了一个环境嘛，流量都能在我的环境里昂！！！

Databus

image-20230124101857485

image-20230124102111646

Mirror

image-20230124102204250

跨区域，时延非常长！！！

image-20230124102308901

异步跨区域进行操作，提升效率。强一致性 -> 最终一致性

Index

image-20230124102413658

业务不是非常友好昂，可能想要自己的索引！！！

image-20230124102448132

Parquet

Apache Parquet是Hadoop生态圈中-种新型列式存储格式，它可以兼容Hadoop生态圈中大 多数计算框架(Hadoop、Spark等)， 被多种查询引擎支持(Hive、Impala、 Drill等)。

  • 列存储：

image-20230124102637748

image-20230124102715224

RocketMQ

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

基本概念

image-20230124103612406

Tag能够支持更多的应用场景昂！

架构

image-20230124103723152

存储模型

image-20230124103755845

高级特性

事务场景

image-20230124103856749

  • 事务消息：

image-20230124104033096

简单的两阶段提交嘛！

延迟消息

image-20230124104131643

定时任务，cronjob，不错昂！

  • 流程：

image-20230124104211624

消息重试&死信队列

image-20230124104348390

比如重试了多次没法处理，放入死信队列，人工就可以看看死信队列里的消息昂！！！

avatar
文章
阅读
粉丝