# RocketMQ概述

RocketMQ是阿里巴巴2016年MQ中间件，使用Java语言开发，RocketMQ 是一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。同时，广泛应用于多个领域，包括异步通信解耦、企业解决方案、金融支付、电信、电子商务、快递物流、广告营销、社交、即时通信、移动应用、手游、视频、物联网、车联网等。

具有以下特点：

能够保证严格的消息顺序
提供丰富的消息拉取模式
高效的订阅者水平扩展能力
实时的消息订阅机制
亿级消息堆积能力

我们可以看到 github上对它的概述：切换为中文版就是：

发布/订阅消息传递模型
财务级交易消息
各种跨语言客户端，例如Java，C / C ++，Python，Go
可插拔的传输协议，例如TCP，SSL，AIO
内置的消息跟踪功能，还支持开放式跟踪
多功能的大数据和流生态系统集成
按时间或偏移量追溯消息
可靠的FIFO和严格的有序消息传递在同一队列中
高效的推拉消费模型
单个队列中的百万级消息累积容量
多种消息传递协议，例如JMS和OpenMessaging
灵活的分布式横向扩展部署架构
快如闪电的批量消息交换系统
各种消息过滤器机制，例如SQL和Tag
用于隔离测试和云隔离群集的Docker映像
功能丰富的管理仪表板，用于配置，指标和监视
认证与授权

我们为什么要使用MQ呢？

要做到系统解除耦合，当新的模块进来的时候，可以做到代码改动量最小。(解耦)
设置流量缓冲池，可以按照自身的吞吐能力进行消费，不被突然间的高流量冲垮。(削峰、限流)
强弱依赖链路梳理，能把非关键调用链路操作异步化并提升整体系统的吞吐能力。(异步)

MQ的架构：

它主要由四大核心部分组成：

Producer: 消息的发送者(生产者)；比如发件人。
**Consumer:**消息接收者(消费者);比如收件人。
**Broker:**暂存和传输消息的管道；比如快递。
**NameServer:**管理Broker，比如快递公司。相当于Broker的注册中心，保留了broker的信息。

可以看到各个模块都可以进行集群式的部署，这也是它吞吐量大、高可用的原因。同时也支持多种集群模式。

NameServer

NameServer 是一个简单的Topic路由注册中心，支持Topic、Broker的动态注册与发现。

主要有两个功能：

Broker管理 ：NameServer 接受 Broker集群的注册信息并且保存下来作为路由信息的基本数据，然后提供心跳检测机制，监测各个brocker是否存活。
路由信息管理： 每个 NameServer将保存关于 Brocker集群的整个路由信息和用于客户端查询的队列信息。 Producer 和 Consumer通过 NameServer就可以知道整个 Broker集群的路由信息，从而进行消息的投递和消费。

NameServer 通常会有多个实例部署，互相独立。各个模块注册的时候向每一台 NameServer都注册自己的路由信息，所以每个 NameServer上都保存了一份完整的路由信息。

Producer

发布消息的角色。 Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程中支持快速失败和重试。一般由业务系统负责产生消息。

RocketMQ提供了三种方式发送消息：同步、异步和单向。

**同步发送：**同步发送指消息发送方发送数据后会在收到接收方发回回应之后才发下一个数据包。一般用于重要的通知消息。
**异步发送：**异步发送指发送方发出数据后，不等接收方回应，接着发送下一个数据包，一般用于接受链路可能耗时比较长但是对响应时间比较敏感的业务场景。
**单向发送：**单向发送是指只负责发送消息不需要等待服务器回应，而且没有回调函数出发，适用于某些耗时非常短，对可靠性要求也不高的场景。

Consumer

消息消费者，负责消费消息，一般是后台系统负责异步消费。

Consumer也由用户部署，支持 Push 和 Pull两种消费模式，支持集群消费和广播消息，提供实时的消息订阅机制。

Pull: 拉取型消费者(Pull Consumer) 主动从消息服务器拉取消息，只要批量拉取到消息，用户应用就会启动消费过程，所以称为主动消费型。

Push:推送型消费者(Pull Consumer) 封装了消息的拉取、消费进度和其他的内部维护工作，将消息到达时执行的毁掉接口留给用户应用程序来实现。所以被称为被动消费类型，单从实现上来看还是从消息服务器中拉取消息，不同于 pull的是 push首先要注册消费监听器，当监听器触发后才开始消费消息。

Broker

Broker主要负责消息的存储、投递和查询以及保证服务的高可用，相比NameServer来说部署相对复杂。

Broker 是具体提供业务的服务器，单个 Broker 节点与所有的 NameServer 节点需要保持长连接和心跳，并定时将 Topic 信息注册到 NameServer。
Broker 负责消息存储，以Topic为纬度支持轻量级的队列，单机可支撑上万队列规模，支持消息推拉模型。
有上亿级消息堆积能力，同时可以严格保证消息的有序性。

还有一些其他的概念：

Message

**Message（消息）**就要要传输的信息。

一条消息必须要有一个主题（Topic），主题可以看作是你的消息要到达的地址。一条消息也可以拥有一个可选的标签（Tag）和额外的键值对，他们可以设置一个业务key并在 Broker上查找此消息以便在开发期间查找问题。

Topic

**topic（主题）**可以看作消息的规类，它是消息的第一级类型。一条消息必须有一个Topic 。

topic与生产者和消费者的关系非常松散，一个topic可以有0个或多个生产者向其发送消息，一个生产者也可以同时向不同的topic发送消息，反之它也可以被0个或多个消费者订阅。

Tag

**Tag(标签)**可以看作子主题，是消息的二级类型。目的是为用户提供更加灵活的使用。这样一个模块的不同目的消息就可以通过相同的Topic加不同的Tag来做区分。

Group

Group(分组) ：一个组可以订阅多个Topic。

Queue

类似kafka中的partition。每个Queue内部是有序的。在MQ中分为读和写两种队列，一般来说读写队列的数量是一致的。

Message Queue

Message Queue(消息队列) ，主题被划分为一个或多个子主题即消息队列。一个Topic下面可以设置多个消息队列，发送消息时执行该Topic，MQ会轮询该Topic下的所有队列将消息发送出去。

Offset

在RocketMQ中，所有消息队列都是持久化、长度无限的数据结构。所谓长度无限是指队列中的每个存储单元都是定长，访问其中的存储单元使用offset来访问。offset是long类型，64位。

所以可以认为它时一个长度无限的数组，offset就是下标。

参考文章：

rocketmq.apache.org/zh/docs/qui...

juejin.cn/post/684490...

希望这篇文章对大家有所帮助，您的赞和收藏是对我最大的支持和认可！

RocketMQ-概述