消息队列原理初识｜ 青训营笔记

steak0107
67 阅读4分钟

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

消息队列简介

什么是消息队列？

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

image.png

消息队列发展历程

image.png

行业消息队列对比

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

Kafka

使用场景

搜索服务、直播服务、订单服务、支付服务的日志信息

image.png

如何使用Kafka

创建集群 -> 新增Topic -> 引入Kafka的SDK，编写生产者逻辑 -> 编写消费者逻辑

基本概念

image.png

  • Topic: 逻辑队列，不同Topic可以建立不同的Topic，数据是存在其中的
  • Partition: Topic的分区，不同分区的消息可以并发处理，以此提高单个Topic吞吐的能力
  • Cluster: 物理集群，每个集群中可以建立多个不同的Topic
  • Producer: 生产者，负责将业务消息发送到Topic中
  • Consumer: 消费者，负责消费Topic中的消息
  • ConsumerGroup: 消费者组，不同组Consumer消费进度互不干涉

Offset

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

image.png

Replica

每个partition中有多个Replica，Leader Replica将会从ISR中选出

image.png

  • 多个副本分布在不同的机器上，以此达到容灾的作用
  • 副本中有不同的角色，Leader、Follower，Leader来执行写入和读取，消费也会先从Leader消费
  • Leader会计算分配的策略
  • Follower会拉取Leader的数据来保持一致，如果和Leader数据差距过大，就会被移除ISR
  • 如果Leader发生宕机，就会从Follower中重新选取一个Leader

数据复制

image.png Broker Controller：负责对集群中的所有副本以及Broker进行分配

架构

image.png ZooKeeper: 负责存储集群元信息，包括分区分配信息、当前正在消费的位置信息等

Producer

批量发送

将消息批量发送可以减少I/O次数，从而加强发送能力。

image.png

数据压缩

对于占空间很大的消息，通过压缩，减少消息大小，目前支持Snappy、Gzip、LZ4、ZSTD压缩算法。

image.png

Broker

数据的存储

image.png

消息文件结构

image.png 文件的命名：每个segment的第一个offset

背景-磁盘结构

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

顺序写

采用顺序写的方式进行写入，以提高写入效率。

image.png

如何找到消息

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

image.png

偏移量索引文件

image.png

  • 二分找到小于目标Offset的最大文件
  • 采取了稀疏索引的方式来构建索引

传统数据拷贝

image.png

零拷贝

image.png

Consumer

消息的接收端

  • 手动分配(Low Level)
    • 通过手动分配，哪一个Consumer消费哪一个Partition完全由业务(代码)来决定
    • 但缺点是不能自动容灾，一个Consumer挂掉后其被分配的Partition就不会被处理掉
    • 以及如果要对Partition重新分配的话，需要停掉被替代的Consumer再加入，会造成线上的数据中断

image.png

  • 自动分配(High Level)
    • 在Broker当中，不同的Consumer Group都会选取一个Coordinator(协调者)，其能帮助某个一个Group中的各个Consumer进行自动分配Partition
    • 其会考虑到负载均衡

image.png

Consumer Rebalance

image.png

帮助Kafka提高吞吐或者稳定性的功能？

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

Kafka缺点

  • 在重启操作时，可能会出现数据不一致问题，且可能会造成Leader的压力会过大，以及重启的时间成本很大
  • 对于Kafka集群来说，只要有节点的变动，都会有数据复制所带来的时间成本问题，进而带来运维成本很高
  • 对于负载不均衡的场景，解决方案复杂
  • 没有自己的缓存，完全依赖Page Cache
  • Controller和Coordinator和Broker在同一进程中，大量I/O会造成其性能下降

以上内容若有不正之处，恳请您不吝指正！

avatar
文章
阅读
粉丝