消息队列原理与实战 | 青训营笔记

Dillonz
133 阅读5分钟

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

前言

本文章主要介绍了消息队列的概念、企业上主流使用的3个消息队列中间件的实现原理。

什么是消息队列

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

image.png

消息队列可以解决什么问题？

  • 解耦、削峰、异步、日志处理

消息队列的前世今生

消息队列发展历程

image.png

业界消息队列对比

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

消息队列-Kafka

使用场景

  • 日志信息,Metrics数据，用户行为

如何使用Kafka

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

基本概念

  • Topic：逻辑队列，不同Topic可以建立不同的Topic
  • Cluster：物理集群，每个集群中可以建立多个不同的Topic
  • Producer：生产者，负责将业务信息发送到Topic中
  • Consumer：消费者，负责消费Topic中的消息
  • ConsumerGroup：消费者组，不同组Consumer消费进度互不干涉

image.png

  • Offset：消息在partition内的相对位置信息，可以理解为唯一ID,在partition内部严格递增

image.png

  • Replica：每个分片有多个Replica，Leader Replica将从ISR中选出

image.png

数据复制

image.png

Kafaka架构

image.png

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

一条消息的自述

image.png

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

  • 思考1：

    • 如果发送一条信息，等到其成功后再发一条会有什么问题？

image.png

Producer

  • 批量发送

image.png

  • 思考2：

    • 如果消息量很大，网络带宽不够用，如何解决？

  • 数据压缩

image.png

Broker

  • 数据存储

image.png

  • 消息文件结构

image.png

  • 磁盘结构
    • 移动磁头找到对应磁道，磁盘转动，找到对应扇区，最后写入。寻道成本比较高，因此顺序写可以减少寻道所带来的的时间成本

image.png

  • 顺序写

    • 采用顺序写的方式进行写入，以提高写入效率 image.png

  • 如何找到消息

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

image.png

  • 偏移量索引文件

image.png

  • 时间戳索引文件

二分找到小于目标时间戳最大的索引位置，再通过寻找offset的方式扎到最终数据

image.png

  • 传统数据拷贝

image.png

  • 零拷贝

image.png

Consumer

  • 消息的接收端

image.png

  • 如何解决Partition在Consumer Group中的分配问题？

  • Low Level

    • 通过手动进行分配，哪一个Consumer消费哪一个Partition完全由业务来决定
    • 优点：启动快
    • 缺点：如果Consumer3挂掉了，7、8分片就停止消费了；如果新增了一台Consumer4，意味着需要停掉整个集群，重新配置再上线。保证Consumer4也可以消费数据；上面两个问题，有时候对于线上业务来说是致命的

image.png

  • High Level
    • 通过自动分配的方式来解决上述问题，即在Broker集群中，对于不同的Consumer Group来说，都会选取一台Broker当做Coordinator，而Coordinator作用就是帮助Consumer Group进行分片的分配，也叫做分片的Rebalance，使用这种方式，如果Consumer Group中发生宕机，或者有新的Consumer加入，整个partition和Consumer都会重新分配来达到一个稳定的消费状态

image.png

Rebalance

image.png

数据复制问题

image.png

重启操作

image.png

替换、扩容、缩容

image.png

负载不均衡

image.png

image.png

消息队列-BMQ

简介

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

image.png

运维操作对比

image.png

HDFS写文件流程

  • 随机选择一定数量的DataNode进行写入

image.png

文件结构对比

image.png

Broker

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

image.png

  • 写文件流程

image.png

  • 写文件Failover
    • 如果DtaNode节点挂了或者是其他原因导致我们写文件失败，应该如何处理？

image.png

Proxy

image.png

多机房部署

image.png

高级特性

  • 泳道->Databus->Mirror->Index->Parquet

image.png

消息队列-RocketMQ

使用场景

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

RocketMQ和Kafka对比

image.png

RocketMQ架构

  • Producer、Consumer、Baroker这三个部分，Kafka和RocketMQ是一样的，而Kafka中的Partition概念在这里叫做ConsumerQueue

image.png

  • 数据流也是通过Producer发送给Broker集群，再由Consumer进行消费Broker节点，有Mater和Slave的概念，NameServer为集群提供轻量级服务发现和路由

image.png

存储模型

image.png

高级特性

  • 事物场景

image.png

  • 事务消息

image.png

  • 延迟发送

image.png

  • 延迟消息

image.png

  • 如何处理失败消息？

image.png

  • 解决方案：消费重试和死信队列

image.png

引用

  • 字节内部课：消息队列与实战
avatar
文章
阅读
粉丝