消息队列专有名词解释

什么是消息队列

消息队列（Message Queue，MQ）是具有缓冲功能、具备类发布/订阅能力的存储引擎，架构设计中作为总线和管道，主要用来削峰、异步解耦、缓存。消息队列最基本的功能是生产/消费，在此基础上建设扩展如事务消息、顺序消息、延时消息、死信队列等高级功能，实现了高吞吐、低延时、高可靠等特性。当前开源社区使用较多的标准消息队列有Kafka、RocketMQ、RabbitMQ、Pulsar等。

MQ专有名词解释

学习消息队列架构之前，要先认识下面这些专有名词，看下表，

名词	说明	备注
Broker	本质上是一个进程。 通常部署一个物理节点只会起一个进程，可以认为Broker表示一个节点， 特殊场景下，一个物理节点中也可以起多个进程，表示一台节点有多个Broker。
Topic	主题，组织分区关系的一个逻辑概念。 一个Topic包含多个分区，RabbitMQ例外，它的Topic指具体某一种主题模式。
Partition/Queue/MessageQueue	分区/分片，数据存储的最小单位。 可以直接将消息写入到一个分区中，也可以将消息写入到Topic，再分发到具体某个分区。 一个Topic通常包含一个或多个分区。
Producer	生产者，消息的发送方。
Consumer	消费者，消息的接收方。
ConsumerGroup/Subscription	消费分组/订阅，组织消费者和分区关系的逻辑概念，也有保存消费进度的作用。
Message	消息，一条真实的业务数据。
Offset/ConsumerOffset/Cursor	位点/消费位点/游标，消费者消费分区的进度。 每个消费者都会消费分区，保存消费者消费分区的进度信息，可以避免重复消费。
ACK/OffsetCommit	确认/位点提交，提交消费进度的操作。 数据消费成功后，提交当前的消费位点，确保不重复消费。
Leader/Follower	Leader和Follower是分区维度副本的概念，即集群中的分区会有多个副本，就会有主从副本。
Segment	段/数据分段，消息数据在底层具体存储时，分为多个文件存储时的文件，这个文件叫分区的数据段。
StartOffset/EndOffset	起始位点/结束位点，分区维度的概念。 数据是顺序写入到分区的，一般从0的位置开始往后写，起始位点就是0。 数据有过期的概念，分区维度较早的数据会被清理。此时起始位点就会往后移，表示当前阶段最早那条有效消息的位点。 结束位点是指最新的那条数据的写入位置。因为数据一直在写入分区，所以起始位点和结束位点是一直动态变化的。
ACL	访问控制列表，对集群的资源进行权限控制。

从消息队列功能的角度，有以下专有名词，看下表，

名词	说明	备注
顺序消息	从生产者和消费者的角度看，生产者按顺序写入Topic的消息，消费者能不能按生产者写入的顺序消费消息，如果能就是顺序消息。
延时消息/定时消息	生产者发送消息到Broker，可以设置这条消息在多久后能被消费到，时间到了后，消息就会被消费到。 延时就是以Broker收到消息的时间为准，多久后消息能被消费者消费，比如消息发送成功后的10分钟才能被消费。 定时就是可以指定消息在设置的时间才能被看到，比如设置10:00才能被消费。
事务消息	在不同的消息队列中的实现方式不一样，定义也不太一样。 事务表示多个操作的原子性，即一批操作要么一起成功，要么一起失败。 消息队列的事务是指发送一批消息，要么同时成功，要么同时失败。
消息重试	消息重试分为生产者重试和消费者重试。 生产者重试是指当消息发送失败后，可以设置重试逻辑，比如重试几次、多久后重试、重试间隔多少。 消费者重试是指当消费的消息处理失败后，会自动重试消费消息。
消息回溯	允许消息被多次消费，某条消息消费成功后，这条消息不会被删除，还能再重复到这条消息。
广播消费	广播从字面上理解是一个主动的动作，Broker将一条消息广播发送给多个消费者。 消息队列的广播本质上是指一条消息能不能被很多个消费者消费到。 只要能被多个消费者消费到，就能起到广播消费的效果，就可以叫做广播消费。
死信队列	死信队列是一个功能，而不是一个像分区一样的实体概念。 当某条消息无法处理成功时，则把这条消息写入到死信队列，将这条消息保存起来，从而可以处理后续消息的功能。 大部分情况下，死信队列在消费端使用得比较多，消费到的消息无法处理成功，就将数据先保存到死信队列，可以继续处理其他消息。 在生产时也会有死信队列概念，某条消息无法写入Topic，可以先写入到死信队列。 从功能上来看，死信队列的功能业务也可以自己去实现。 消息队列中死信队列的意思是，消息队列的SDK已经集成了这部分功能，从而让业务使用起来就很简单。
优先级队列	可以给在一个分区或队列中的消息设置权重，权重大的消息能够被优先消费到。 大部分情况下，消息队列的消息处理是FIFO先进先出规则。 如果某些消息需要被优先处理，基于这个规则就无法实现，就有了优先级队列，优先级是消息维度设置的。
消息过滤	可以给每条消息打上标签，在消费时根据标签信息去消费消息。 可以理解为一个简单的查询消息的功能，通过标签去查询过滤消息。消息过滤主要在消费端生效。
消息过期/删除（TTL）	消息队列中的消息会在一定时间或者超过一定大小后被删除。 消息队列主要是缓冲作用，一般会要求消息在一定的策略后会自动被清理。
消息轨迹	记录一条消息从生产端发送、服务端保存、消费端消费的全生命周期的流程信息。 用来追溯消息什么时候被发送、是否发送成功、什么时候发送成功、服务端是否保存成功、什么时候保存成功、被哪些消费者消费、是否消费成功、什么时候被消费等。
消息查询	根据某些信息查询到消息队列中的信息。 比如根据消息ID或消费位点来查询消息，可以理解为数据库里面的固定条件的select操作。
消息压缩	生产端发送消息时，是否支持将消息进行压缩，节省物理资源（比如网卡、硬盘）。 压缩可以在SDK完成，也可以在Broker完成，并没有严格限制。压缩在客户端完成会比较合理。
多租户	同一个集群是否有逻辑隔离，比如一个物理集群能否创建两个名称都为test的主题。 此时一般会有一个逻辑概念Namespace（命名空间）和Tenant（租户）来做隔离，一般有这两个概念的就是支持多租户。
消息持久化	消息发送到Broker会不会持久化存储，比如存储到硬盘。 有些消息队列为了保证性能，只会把消息存储在内存，此时节点重启后数据就会丢失。
消息流控	能否对写入集群的消息进行限制。 一般会支持Topic、分区、消费分组、集群等维度的限流。