消息管道

在系统架构中，MQ 的定位是消息和管道，主要起到解耦上下游系统，数据缓存的作用，主要操作为生产和消息

2cb1c8245c15f3df28228af3c8b8bd8c

架构

845c85d7f3d55cd47c894f0b8eb7ab06

Broker

  1. Broker 本质上是一个进程
  2. 在实际部署过程中，通常一个物理节点只会起一个进程，在大部分情况下，Broker 表示一个节点

Topic

  1. 在大部分 MQ 中，Topic 都是用来组织分区关系的一个逻辑概念
  2. 通常情况下，一个 Topic 会包含多个分区
    • 在 RabbitMQ 中，Topic 是指具体的一种主题模式

Partition

Queue / MessageQueue

  1. 在 MQ 中，分区、分片、Partition、Queue、MessageQueue 是一个概念，用来表示数据存储的最小单位
  2. 可以将消息写入到一个分区中，也可以将消息写入到 Topic 中，再分发到具体的某个分区
  3. 一个 Topic 通常会包含一个或多个分区

Producer

  1. 消息的发送方，即发送消息的客户端

Consumer

  1. 消息的接收方，即接收消息的客户端

ConsumerGroup

Subscription

  1. 一般情况下，MQ 中的 ConsumerGroup 和 Subscription 是同一概念
  2. 用来组织消费者和分区关系的逻辑概念，也可用于保存消费进度

Message

  1. 一条真实的业务数据，MQ 中的每条数据一般都叫做一条消息

Offset

ConsumerOffset / Cursor

  1. 指消费者消费分区的进度
  2. 每个消费者都会去消费分区，为了避免重复消费，都会保存消费者消费分区的进度信息

ACK

OffsetCommit

  1. 提交消费进度的操作，即数据消费成功后，提交当前的消费位点，确保不重复消费

Leader + Follower

  1. Leader 和 Follower 一般是分区维度副本的概念
  2. 一个分区一般会有多个副本，副本有主从概念，一般是一个主副本和多个从副本

Segment

  1. 指消息数据在底层具体存储时，分为多个文件存储时的文件，该文件叫做分区的数据段
  2. 如每超过 1G 的文件就新起一个文件来存储，即 Segment
  3. 几乎所有的 MQ 都有 Segment 的概念，如 Kafka 的 Segment，Pulsar 的 Ledger

StartOffset + EndOffset

  1. StartOffset 和 EndOffset 是分区维度的概念
  2. 数据是顺序写入分区的，一般从 0 位置开始往后写，此时 StartOffset 为 0
  3. 数据会过期，分区维度较早的数据会被清理，此时 StartOffset 会往后移，表示当前最早的有效数据的位点
  4. EndOffset 即最新的那条数据的写入位点
  5. StartOffset 和 EndOffset 是一直动态变化的

ACL

  1. 用来对集群中的资源进行权限控制，如控制 Topic 或 Partition 的读写操作等

功能

顺序消息

  1. Consumer 按 Producer 写入的顺序来消费消息

延时消息

定时消息

  1. Producer 发送消息到 Broker 时，设置该消息在多久后会被消费到，当时间到了，消息会被消费到
  2. 延时以 Broker 收到消息的时间为准，多久后消息能被 Consumer 消费
  3. 定时是指消息在设置的时间才能被看到
  4. 在技术上，延时和定时是一样的

事务消息

  1. 不同的 MQ 关于事务的定义，也是不太一样的
  2. 正常情况下，事务表示多个操作的原子性
    • 在 MQ 中，一般指的是发送一批消息，要么同时成功，要么同时失败

消息重试

  1. Producer 重试 - 当消息发送失败后，可以设置重试策略
  2. Consumer 重试 - 当消费的消息处理失败后，会自动重试消费消息

消息回溯

  1. 消息可以被多次消费
  2. 某条消息消费成功后，该消息不会被删除，后续还能再重复消费到该消息

广播消费

  1. 一条消息可以被多个消费者消费

死信队列

  1. 当某条消息无法成功处理时，把该消息写入到一个死信队列中，继续处理后续消息
  2. 大部分情况下，死信队列在 Consumer 中使用

优先级队列

  1. 给 Partition 中消息设置权重，权重大的消息能够被优先消费到
  2. 大部分情况下，MQ 的消息处理是 FIFO 的规则
  3. 优先级是在消息维度设置的

消息过滤

  1. 给每条消息打上 Tag，在消费的时候根据 Tag 去消费消息
  2. 通过 Tag 去查询过滤消息 - 在 Consumer 端

TTL

  1. MQ 中的消息会在一定时间或者超过一定大小后会被删除
  2. MQ 的主要是缓冲作用，一般会要求消息在一定的策略后自动被清理

消息轨迹

  1. 记录一条消息从 Producer 发送、Broker 保存、Consumer 消费的全生命周期的流程信息

消息查询

  1. 根据某些信息查询到消息队列中的信息
  2. 根据消息 ID 或者消费位点来查询消息 - SQL Select

消息压缩

  1. Producer 发送消息的时候，是否支持将消息进行压缩，以节省物理资源
  2. 压缩可以在 Producer 完成，也可以在 Broker 完成，一般会在 Producer 完成

多租户

  1. 同一个集群存在逻辑隔离
  2. Namespace / Tenant

消息持久化

  1. 消息被发送到 Broker 后，会不会持久化存储
  2. 有些 MQ 为了保证性能，只会把消息存储在内存中，在节点重启后，数据会丢失

消息流控

  1. 对读写集群的消息进行限制
  2. 限流维度 - Topic / Partition / ConsumerGroup 等

选型

业务消息 - RocketMQ
流消息 - Kafka

RabbitMQ + RocketMQ

业务消息 - 及时性、更多的功能特性、消息可追踪

  1. RabbitMQ 和 RocketMQ 属于业务消息类的 MQ
  2. RabbitMQ 发展较早，RocketMQ 是新生的消息类的消息队列
  3. 从功能、集群化、稳定性、性能来看，RocketMQ 都优于 RabbitMQ - RocketMQ 替代 RabbitMQ
  4. 国内 - RocketMQ；国外 - RabbitMQ

Kafka

流消息 - 大流量、高吞吐

  1. Kafka 属于流场景的 MQ - 高吞吐、大流量
  2. 功能简单 - 不支持死信队列、延时消息等功能
  3. 非常稳定 + 吞吐性能非常高，能承担超大流量的业务场景 - 流场景下的消息管道的不二之选

Pulsar

  1. Pulsar 定位 - 消息和流融合
  2. 目标 - 满足所有消息和流的场景，同时满足功能和性能两方面的需求
  3. 发展时间较短，不太稳定，处于快速发展阶段