RocketMq

RocketMq主要采用发布订阅的方式，发布订阅又有哪些有点呢：解耦、异步、可伸缩、负载均衡

• 解耦：发布者和订阅者之间没有直接依赖关系
• 异步：增快响应速度
• 可伸缩：根据需要动态地添加或删除订阅者
• 负载均衡：将消息均匀地分配给多个消费者，避免某个消费者过载

快速开始

本地部署 RocketMQ | RocketMQ (apache.org)

常用部署组件

2.1 Broker

Broker是RocketMQ的核心，大部分工作都在Broker中完成，包括接收请求，处理消费，消费持久，消息的HA，以及服务端过滤等都在里面完成

就相当于这个Rocket服务本身：包括了主题，消息队列

Broker 是 RocketMQ 的核心服务节点，负责接收来自 Producer（生产者）的消息、存储消息以及将消息转发给 Consumer（消费者）。在 RocketMQ 架构中，Broker 分为 Master Broker 和 Slave Broker（或称为 Replica）两种角色：

• Master Broker：处理消息的读写请求，是生产者发送消息和消费者消费消息的主要目标。
• Slave Broker：作为 Master Broker 的副本存在，主要用于备读或者故障切换，以提高系统的可用性。在 Master Broker出故障时，Slave Broker 里的消息依然可以被消费，或者直接被提升为新的 Master 继续提供服务。

Broker 的部署可以是单节点的，也可以是集群式的，甚至支持同机器、同进程混布的模式。
其具体部署形式可以参考 Broker 部署指南。

2.2 NameServer

相当于Nacos，用于注册发现服务，维护Broker路由，监测服务状态

NameServer 是 RocketMQ 的路由服务集群，它不保存任何消息数据，而是维护着所有 Broker 的路由信息（包括 Broker 存活情况、各 topic 的路由信息等）。Producer 和 Consumer 在发送或订阅消息前，都需要先从 NameServer 获取 Broker 的路由信息，之后才能正确地与 Broker 通信。NameServer 支持集群部署，以确保高可用。

该组件的部署相对简单，可以参见文档 NameServer 部署指南。

2.3 Proxy

Proxy 是 RocketMQ 为了提高性能和简化客户端接入而引入的一个可选组件。它作为一个轻量级的代理服务器，位于客户端与 Broker 之间，主要职责包括：

• 负载均衡：自动为客户端分配合适的 Broker，减轻客户端的负担。
• 协议转换：支持多种协议接入，使得不同语言的客户端能够更容易地与 RocketMQ 集成。
• 安全控制：可以作为一层安全网关，实现访问控制、鉴权等功能。
• 网络优化：通过缓存、连接复用等技术优化网络通信效率。

该组件的部署相对独立，可以选用不同模式进行部署，如 Local 模式以及 Cluster 模式，你可以参考Proxy 部署指南进行部署。

2.4 Controller

Controller是 RocketMQ 5.0 新增的组件，它充当控制平面的角色，负责管理和协调系统的整体状态。它主要出现在可切换架构的部署过程中，如 Broker 宕机时，它将进行调度，对 Broker 集群进行选举管理。Controller 本身也支持集群部署，基于 Raft 实现容灾。

该组件的部署可以参考Broker 部署指南中的主备自动切换模式部署指南章节。

2.5 Dashboard

RocketMQ Dashboard 是 RocketMQ 提供的一款可视化管理界面，它允许用户通过网页浏览器直观地监控和管理 RocketMQ 集群的状态，包括但不限于查看消息队列、消费进度、Broker 健康状况、主题配置、消费组详情等信息。Dashboard 的存在大大提升了运维人员对 RocketMQ 集群的监控能力和管理效率。

该组件的部署可以参考DashBoard 部署指南。

结构

消息生产

生产者（Producer）：

Apache RocketMQ 中用于产生消息的运行实体，一般集成于业务调用链路的上游。生产者是轻量级匿名无身份的。

消息存储

• 主题（Topic）：

  Apache RocketMQ 消息传输和存储的分组容器，主题内部由多个队列组成，消息的存储和水平扩展实际是通过主题内的队列实现的。

• 队列（MessageQueue）：

  Apache RocketMQ 消息传输和存储的实际单元容器，类比于其他消息队列中的分区。 Apache RocketMQ 通过流式特性的无限队列结构来存储消息，消息在队列内具备顺序性存储特征。

• 消息（Message）：

  Apache RocketMQ 的最小传输单元。消息具备不可变性，在初始化发送和完成存储后即不可变。

消息消费

• 消费者分组（ConsumerGroup）：

  Apache RocketMQ 发布订阅模型中定义的独立的消费身份分组，用于统一管理底层运行的多个消费者（Consumer）。同一个消费组的多个消费者必须保持消费逻辑和配置一致，共同分担该消费组订阅的消息，实现消费能力的水平扩展。

• 消费者（Consumer）：

  Apache RocketMQ 消费消息的运行实体，一般集成在业务调用链路的下游。消费者必须被指定到某一个消费组中。

• 订阅关系（Subscription）：

  Apache RocketMQ 发布订阅模型中消息过滤、重试、消费进度的规则配置。订阅关系以消费组粒度进行管理，消费组通过定义订阅关系控制指定消费组下的消费者如何实现消息过滤、消费重试及消费进度恢复等。

  Apache RocketMQ 的订阅关系除过滤表达式之外都是持久化的，即服务端重启或请求断开，订阅关系依然保留。

一对多的订阅机制，订阅机制维护了消息过滤、重试、消费进度的规则配置

原理

消费消息

短轮询

消费端拉取信息

长轮询

消费端拉取信息

事务消息

可以让我们确保发送的消息一定能写进MQ里，绝不会丢失掉

事务消息提供了：回滚、提交机制

假如half消息发送成功了，生产者没收到响应怎么办？

MQ事务消息流程就是上面的，但是我们来进行比较严谨的分析，如果我们把half消息发送给MQ了，MQ给保存下来了，但是MQ返回给我们的响应生产者没收到，会怎么样？

这时候，生产者会误以为发送到MQ的half消息失败了，就不会执行后边的流程。

但MQ已经保存下来了一条half消息，这个消息怎么处理？

其实RocketMQ这里有一个补偿机制，他会去扫描自己处于half状态的消息，如果我们一直没有对这个消息执行commit或rollback操作，超过了一定的时间，他就会回调你的订单系统的一个接口，看看你这个消息什么情况，你生产者到底是打算commit这个消息，还是打算rollback这个消息？