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

WalesZ
68 阅读4分钟

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

1 消息队列的概念

消息队列（MQ），指保存消息的一个容器，本质是个队列。这个队列需要具有以下特性：高吞吐、高并发、高可用。

生产 -> [Message] -> [Message] -> ... -> [Message] -> 消费

2 消息队列的前世今生

2.1 发展历程

  • TIB：1985，服务于金融机构和新闻机构
  • IBM MQ/WebSphere：1993，商业消息队列平台市场
  • MSMQ：1997，微软发布
  • JMS：2001，本质上是一套Java API
  • AMQP/RabbitMQ：2004，AMQP是高级消息队列协议。RabbitMQ是一个开源消息队列中间件
  • Kafka：2010，Linked开源
  • RocketMQ：2011，阿里中间件团队自研
  • Pulsar：2012，Yahoo内部

2.2 业界消息队列对比

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

3 常见消息队列介绍

3.1 Kafka

3.1.1 使用场景

  • 搜索服务
  • 直播服务
  • 订单服务
  • 支付服务

日志信息、Metrics 数据、用户行为（搜索、点赞、评论、收藏）

3.1.2 如何使用

  • 创建集群
  • 新增 Topic，设置好分片数量
  • 编写生产者逻辑
  • 编写消费者逻辑

3.1.3 基本概念

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

  • Topic：逻辑队列，可以理解成每个不同的业务场景是一个不同的topic，对这个业务来说，所有数据都存储在这个topic中

  • Partition：通常topic会有多个分片，不同分片直接消息是可以并发来处理的，这样可以提高单个topic的吞吐

  • Producer：生产者，即消息的生产端，负责将业务消息发送到Topic中

  • Consumer：消费者，负责消费Topic中的消息

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

image-20230211162239161

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

image-20230211162356215

  • Replica：分片的副本，分布在不同的机器上，可用来容灾。每个分片有多个Replica，Leader Replica 将会从 ISR（同步中的副本）中选取

    image-20230211162800559

3.1.4 数据复制

image-20230211163500377

broker 代表一个 kafka节点。

controller 是整个集群的大脑，负责对副本和broker进行分配

3.1.5 kafka架构

image-20230211163710456

zookeeper模块存储了集群的元数据信息（如副本的分配信息），controller计算号的方案都会放到这里

3.1.6 Producer——批量发送

image-20230211164159998

3.1.7 Producer——数据压缩

image-20230211164228869

3.1.8 Consumer——消息的接收端

对一个Consumer group来说，多个分片可以并发的消费，这样可以大大提高消费的效率。但需要解决 Consumer 和Partition的分配问题。

image-20230211164906266

  • Low level：通过手动分配，哪一个consumer消费哪一个partition完全由业务来决定

    • 优点：启动快

  • High level：自动分配（由kafka提供）。选取一台borker当作coordinator，用来帮助consumer group进行分片的分配

3.1.9 重启操作

image-20230211165701979

3.1.10 kafka的缺点

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

3.2 BMQ

BMQ兼容kafka协议，村算分离，云原生消息队列

3.2.1 架构

image-20230211170255985

producer -> consumer -> proxy -> broker -> HDFS -> controller -> coordinator -> Meta

3.2.2 运维操作对比

image-20230211170759659

所有节点变更操作都只是集群元数据的变化，通常情况下在秒级完成。真正的数据已经移到下层分布式文件存储去了，运维操作不需要额外关心数据复制带来的时间成本

3.2.3 HDFS 写文件流程

image-20230211170822043

3.2.4 BMQ 文件结构

image-20230211171602290

3.2.5 写文件流程

image-20230211171652653

3.2.6 Proxy

image-20230211172238267

3.3 RocketMQ

3.3.1 使用场景

低延时场景：电商业务、秒杀活动等

3.3.2 基本概念

image-20230211172400974

3.3.3 架构

image-20230211172517535

3.3.4 存储模型

image-20230211172534404

avatar
文章
阅读
粉丝