RocketMQ基础概念

​

 一、概述

RocketMQ是一个分布式消息中间件，它主要用于处理高吞吐量的消息传递、事件流处理等场景，广泛应用于大规模分布式系统中的消息传递和异步通信。RocketMQ的设计目标是高可用、可扩展和高性能，支持异步消息、顺序消息、事务消息等多种消息模式。

二、RocketMQ系统架构

​编辑

上图就是一个简单RocketMQ系统架构，包括服务注册与发现中心 (NameServer) 、生产者 (Producer) 、消费者 (Consumer) 、Broker、四大模块组成。

当消息被发送到主题（Topic）上的时候，消费者将收到其订阅主题上的所有消息，生产者负责定义消息的类别，为了支持高并发和水平扩展，中间的消息主题需要进行分区，同一个Topic会有多个生产者，同一个消息会有多个消费者，消费者之间要进行负载均衡。

扩展：在RocketMQ5.0以后，也可以通过直连Proxy，将数据发送给Proxy，Proxy在当前阶段只是一个代理，不负责真正的数据存储，当收到数据后，还是将数据发到Broker进行保存。

三、服务注册与发现中心 (NameServer)

NameServer主要作用是提供 Broker 节点的路由信息给生产者和消费者。它不负责消息的存储和传递，而是负责服务的发现与路由，确保生产者和消费者能够找到合适的 Broker 进行消息的发送与接收。

主要负责以下几个关键功能：

(1) Broker 注册与发现

• 当 RocketMQ 的 Broker 启动时，会向 NameServer 注册自己的信息，包括 Broker 的地址、状态、支持的主题（Topic）、队列信息等。
• 生产者和消费者在启动时，会通过 NameServer 查询到可用的 Broker 信息，从而进行消息的发送和接收。

(2) 路由信息管理：

• NameServer 存储了所有 Broker 的路由信息，并为生产者和消费者提供这些信息，以便它们能够找到合适的 Broker 来进行消息的发布或消费。
• 生产者向 NameServer 查询到目标 Topic 对应的 Broker 信息后，会直接与 Broker 进行通信。

四、生产者 (Producer)

在 RocketMQ 中，生产者（Producer）是消息的发送者，负责将消息发送到消息队列（Topic）。生产者的主要职责是将应用程序的数据或事件发送到消息队列中，供消费者（Consumer）消费。

首先看一下我们消息的构成

public class Message implements Serializable {
    private static final long serialVersionUID = 8445773977080406428L;
    private String topic;
    private int flag;
    private Map<String, String> properties;
    private byte[] body;
    private String transactionId;
}

RocketMQ消息的构成非常简单，如上图所示

• topic 表示要发送的消息的主题。
• body 表示消息的存储内容
• properties 表示消息属性，例如Tag
• transactionId 会在事务消息中使用。

Tag: 不管是 RocketMQ 的 Tag 过滤还是延迟消息等都会利用 Properties 消息属性机制，这些特殊信息使用了系统保留的属性Key，设置自定义属性时需要避免和系统属性Key冲突。

Tag 消息属性

Topic 与 Tag 都是业务上用来归类的标识，区别在于 Topic 是一级分类，而 Tag 可以理解为是二级分类。使用 Tag 可以实现对 Topic 中的消息进行过滤。

• Topic：消息主题，通过 Topic 对不同的业务消息进行分类。
• Tag：消息标签，用来进一步区分某个 Topic 下的消息分类，消息从生产者发出即带上的属性。

两者关系如下图

​编辑

什么时候该用 Topic，什么时候该用 Tag？

可以从以下几个方面进行判断：

• 消息类型是否一致：如普通消息、事务消息、定时（延时）消息、顺序消息，不同的消息类型使用不同的 Topic，无法通过 Tag 进行区分。
• 业务是否相关联：没有直接关联的消息，如淘宝交易消息，京东物流消息使用不同的 Topic 进行区分；而同样是天猫交易消息，电器类订单、女装类订单、化妆品类订单的消息可以用 Tag 进行区分。
• 消息优先级是否一致：如同样是物流消息，盒马必须小时内送达，天猫超市 24 小时内送达，淘宝物流则相对会慢一些，不同优先级的消息用不同的 Topic 进行区分。
• 消息量级是否相当：有些业务消息虽然量小但是实时性要求高，如果跟某些万亿量级的消息使用同一个 Topic，则有可能会因为过长的等待时间而“饿死”，此时需要将不同量级的消息进行拆分，使用不同的 Topic。

小结：针对消息分类，我们可以选择创建多个 Topic，或者在同一个 Topic 下创建多个 Tag。但通常情况下，不同的 Topic 之间的消息没有必然的联系，而 Tag 则用来区分同一个 Topic 下相互关联的消息，例如全集和子集的关系、流程先后的关系。

五、消费者 (Consumer)

在 RocketMQ 中，消费者（Consumer）是负责从消息队列中接收并处理消息的角色。消费者从消息队列（Topic）中拉取消息，并对消息进行业务处理，通常是将消息转化为某种业务事件进行响应或处理。

消费者与消费者组

Producer将消息发送到Broker，如果在我们的业务高峰期，下游消费者消费能力不足的话，大量的瞬时流量会堆积在服务端，因此需要增加消费能力来解决这个问题，最简单的方式就是扩容消费者，如果多个消费者设置了相同的Consumer Group，我们认为这些消费者在同一个消费组内。

RocketMQ两种消费模式

(1) 集群模式（Cluster Mode）

• 在集群模式下，消费者组内的消费者共享消息队列。每个队列仅由一个消费者实例消费，确保同一消息队列中的消息只会被消费者组内的一个消费者消费。
• 集群模式适用于负载均衡场景，一个 Consumer Group 下的多个消费者共同消费 Topic 中的消息。

​编辑

(2) 广播模式（Broadcast Mode）

• 在广播模式下，所有消费者都会接收到 Topic 中的每一条消息，即使这些消费者属于同一个消费者组。广播模式适用于需要将消息发送到所有消费者的场景。
• 每个消费者都单独消费消息队列，不会出现负载均衡。

​编辑

RocketMQ 消费者的异步和同步消费

RocketMQ 支持两种方式来处理消息的消费：

• 同步消费：消费者在消费消息后，等待消息处理结果返回，再继续消费下一条消息。同步消费适用于处理需要顺序执行的业务场景。
• 异步消费：消费者获取消息后，可以异步处理，不需要等待消息处理的完成即可继续消费下一个消息。这种方式可以提高消费吞吐量。

六、Broker

Broker 是消息存储和路由的核心组件，负责消息的接收、存储、传递和消费。Broker 是 RocketMQ 架构中的关键节点，它负责接收生产者发送的消息，并将其存储到磁盘中，同时负责将这些消息传递给消费者。一个 RocketMQ 集群通常由多个 Broker 节点组成，以提供高可用性和水平扩展能力。

Broker的基本功能

主要有以下几点：

• 消息接收：接收来自生产者的消息并存储到消息队列中。
• 消息存储：将消息持久化到磁盘，以保证消息的可靠性。
• 消息路由：将消息路由到相应的消费者。
• 消息发送：将消息从 Broker 传递到消费者，支持多种消费模式（如广播和集群消费模式）。
• 负载均衡：在分布式环境下，Broker 支持消息队列的负载均衡，以提高系统的吞吐量。

Broker 的部署模式

RocketMQ 支持多种 Broker 部署模式：

(1) 单节点模式（Standalone）

• 在简单的测试或小规模部署中，可以使用单节点模式，所有消息都通过一个 Broker 节点进行存储和处理。

(2) 集群模式（Cluster Mode）

• 在生产环境中，通常使用集群模式。多个 Broker 节点通过集群模式部署，每个 Broker 节点处理一部分消息的读写，提供高吞吐量和高可用性。

• Broker 之间的消息可以通过 Topic 和消息队列的分布进行负载均衡。

​