走进消息队列 | 青训营

Brabem
77 阅读3分钟

走进消息队列

前言：

消息队列可以解决以下问题：

  1. 系统崩溃

    通过引入消息队列，进行解耦

  2. 服务处理能力有限

    通过削峰以减少请求

  3. 链路耗时长尾

    采用异步的方案，同时处理处理

  4. 日志处理

消息队列的定义

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

一、前世今生：消息队列发展历程

业界流行的MQ如下：

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

二、Kafka

  1. 使用场景

    搜索服务、直播服务、订单服务、支付服务、用户行为（搜索、点赞、评论、收藏）

  2. 如何使用Kafka

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

  3. 基本概念

    Topic：逻辑队列，不同Topic可以建立不同的Topic

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

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

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

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

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

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

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

4.一条消息的自述

Producer->生产->Broker->消费->Consumer

5.Producer-批量发送

批量发送可以减少IO次数，从而加强发送能力

6.Producer-数据压缩

通过压缩，减少消息大小，目前支持Snappy、Gzip、LZ4、ZSTD压缩算法

7.Broker-数据的存储

Broker->Batch->本地磁盘

8.消息文件结构

9.Broker-磁盘结构

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

Consumer通过发送FetchRequest请求消息数据，Broker会将指定Offset处的消息，按照时间窗口和消息大小窗口发送给Consumer

11.Consumer-消息的接收端

12.Consumer-Low Level

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

13.Consumer-High Level

14.Kafka-问题总结

运维成本高

对于负载不均衡的场景，解决方案复杂

没有自己的缓存，完全依赖Page Cache

Controller和Coordinator和Broker在同一个进程中，大量IO会造成其性能下降

三、BMQ

简介

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

运维操作对比

写文件流程

由Client写入到DataNode，然后读取到Client中

甬道消息的开发流程

开发->BOE->PPE->Prod

Databus的作用

简化消息队列客户端复杂度

解耦业务与Topic

缓解集群压力，提高吞吐

四、RocketMQ

使用场景

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

RocketMQ基本概念

高级特性

最终一致性

avatar
文章
阅读
粉丝