关于RocketMQ那些你可能不知道的性能优化！

关注

原创最新推荐文章于 2026-07-15 12:01:21 发布 985 阅读 AI 写同款· GEO 优化 ›

RocketMQ代码实战(二)：RocketMQ发送带Tag的消息在代码实战：使用rocketmq-spring-boot-starter发送和消费消息讲解了使用rocketmq-spring-boot-starter快速搭建生产者消费者服务，本次继续讲解发送带Tag的消息 Tag（标签）可以看作子主题，它是消息的第二级类型。同一业务模块不同目的的消息就可以用相同 Topic 而不同的 Tag来标识。比如交易消息又可以分为：交易创建消息、交易完成消息等，一条消息可以没有 Tag。 1.发送消息 @RestController public class Rock 阅读详情

RocketMQ Binder集成

RocketMQ也是根据Spring Cloud Stream的规范做了相应的自己的实现，RocketMQ 由于对应的Binder类实现，可以说是集成了消息发送，消息订阅。为了方便大家去阅读源码，我简单的跟大家说一下。

集成消息发送

RocketMQMessageChannelBinder类根据规范完成RocketMQMessageHandler的创建和初始化，RocketMQMessageHandler 是消息处理器MessageHandler的具体实现，其主要作用是转化消息格式并且发送消息，此类中持有RocketMQTemplate对象，RocketMQTemplate是对RocketMQ客户端API的封装。

是不是已经开始有点晕了？

简单来说，这个handler是一个很关键的类，它就是包含消息发送的逻辑处理，解析Message对象头中的参数，调用上面说的RocketMQTemplate中不同的消息发送接口。无论你是发送的顺序消息，事物消息，定时消息还是普通消息，都是由Message对象头（Header）中的属性决定，在我们业务代码创建Message的时候去设置。

划重点咯，如果大家有兴趣，可以把RocketMQMessageHandler这个类当作一个入口，就可以很轻松看到整个消息发送的流程。

集成消息订阅

同样，由RocketMQMessageChannelBinder类根据协议完成RocketMQInboundChannelAdapter（简称adapter）的创建和初始化，顾名思义，这个adapter适配器需要适配Spring Framework中的重试和回调机制，它的作用是订阅消息并且转换消息格式。其中的RocketMQListenerBindingContainer对象是对RocketMQ客户端API的封装。

RocketMQ提供了两种消费模式，顺序消费和并发消费，不管是哪种消费模式，其对应的监听器收到消息后都会回调RocketMQListener。RocketMQListener 也是SpringBoot中已支持的RocketMQ组件，在adapter中创建和初始化RocketMQListener的实现类。上面两种消费模式的监听器在监听到消息的时候，会先回调RocketMQListener的onMessage()方法，然后在调用adapter父类中的sendMessage()方法将消息发送到DirectChannel。

以上就是RocketMQ Binder集成的大致过程，我们来总结一下：

Spring Cloud Stream 提供了简单易用的消息编程模型，内部是基于发布/订阅模型来实现的。
Spring Cloud Stream 的Binder提供标准协议，不同的消息中间件都可以按照标准协议接入。
Binder提供bindConsumer和bindProducer接口协议，分别用于构造生产者和消费者。

RocketMQ集群管理

在分布式服务（SOA）的架构中，我们是不允许任何中间件是单点的，服务发现机制也是必备的。咱们的服务实例会有多个，数量也是动态变化的，随时可能存在服务挂掉再重启的可能性。服务发现的意义就在于其提供的服务管理能力，服务调用方在注册中心获取服务提供的的信息，从而进行远程调用。

RocketMQ架构设计

说到RocketMQ的架构设计，就不得不说一下它和Kafka的渊源了。Kafka也是一款高性能的消息中间件，在大数据的场景中经常会使用，但是因为Kafka不支持消息失败重试，定时消息，事物消息，它的顺序消息也有明显的缺陷的，在复杂的业务场景下难以支撑。所以淘宝的中间件团队参考Kafka设计了RocketMQ，所以两者在概念上会有一点点相似。

我们常见的消息中间件，比如RocketMQ，Kafka，RabbitMQ等都是基于发布订阅模型，Producer把消息发送到消息服务器，也就是消息中间件，然后Consumer通过订阅来从消息服务器订阅自己想要的消息。在整个过程中，Producer和Consumer都是客户端，而消息服务器是服务端。客户端和服务端都需要通过注册中心来感知对方的存在。

下面我们就由一张图来看看RocketMQ的架构设计：

RocketMQ的架构主要分为四个部分，全部支持分布式集群部署：

Producer：消息发送者，主要负责把消息发送到Broker。
Consumer：消息消费者，主要负责从Broker订阅消费消息。
Broker：消息存储者，主要负责消息的存储，投递和查询，以及服务高可用的保障。
NameServer：服务管理者，主要负责管理Broker集群的路由信息。

多说一下，NameServer是一个简单的Topic路由注册中心，其角色类似于Dubbo中依赖的ZooKeeper，支持Broker的动态注册与发现，它主要由两个功能：

服务注册：接收Broker集群的注册信息，保存下来作为路由信息的基本数据，还会提供心跳检测，检查Broker是否存活。
路由信息管理：由于NameServer保存了Broker集群的路由信息。Producer和Comsumer通过NameServer可以知道Broker集群的路由信息，从而进行消息的投递与消费。

RocketMQ基本概念

说完了RocketMQ的架构设计，我们再来捋一捋它的基本概念，什么是Message，什么是Topic，什么又是Queue？

Message：消息，顾名思义，生产和消费数据的最小单位，每条消息必须属于一个Topic，RocketMQ中每条消息拥有一个唯一的MessageID，且可以携带具有业务表示的Key。
Topic：主题，表示的是一类消息的集合，每个主题都有若干条消息，我们可以试想一下发邮件的过程，多条邮件可以同属一个主题，只是标识出此邮件的分类信息。Topic是消息订阅的基本单位。
Queue：消息队列，组成Topic的最小单元，一个Topic可以有多个消息队列，Topic是逻辑上的概念，而Queue是物理存储，在Consumer消费Topic时底层实际拉取的是Queue的消息。试想我们一个类别的消息，可以有多个消息发送通道就可以理解啦。
Tag：为消息设置的标志，用于同一个主题下面区分不同类别消息，这个应该很好理解，比如同一个食物主题下，可以通过Tag来区分是菠萝还是黄瓜，可以根据不同的业务设置不同的Tag。
UserProperties：用户自定义的属性集合，属于Message的一部分。
ProducerGroup：同一类Producer的集合，这一类Producer发送同一类消息且发送的逻辑一致。值得一提的是，如果发送的是事物消息且发送者在发送消息后崩溃，则Broker会提醒同一个Group下的其他生产者实例以提交或回溯消费。
ConsumerGroup：同一类Consumer的集合，有生产者集合当然就有消费者集合啦，同样ConsumerGroup通常消费同一类消息且消费逻辑一致。消费者组使得在消费消息方面，实现负载均衡和容错变得更加容易，需要注意的是，同一消费者组下的消费者必须订阅同一个Topic。

为什么放弃Zookeeper选择NameServer

基本概念也说完啦，下面我们来简单聊一下，既然RocketMQ可以说是Kafka的改进，那为什么抛弃了Kafka使用的Zookeeper注册中心反而选择NameServer呢？

在Kafka中的服务注册与发现通常使用Zookeeper来完成的，RocketMQ其实早期也适用了Zookeeper来做集群的管理，但是后来放弃了转而使用自己开发的NameServer。

那为什么RocketMQ的团队会放弃Zookeeper，选择重复造轮子呢？

简单来说，在Kafka中，Master和Slave是在同一台Broker机器上，Broker机器上有多个分区，每个分区的Master/Slave身份是在运行的过程中通过选举出来的，Broker机器拥有双重身份，既有Master分区，也有Slave分区。

而在RocketMQ中呢，Master和Slave不在同一台Broker机器上，我们可以通过上面的架构图看出来，Broker的Master/Slave身份在Broker配置文件中事先定义好的，在Broker启动之前就已经定好了。

那这个差异会有什么问题呢？

Kafka的Master需要选举，而RocketMQ不需要。

问题其实就出在这个选举上，选举的原理就是少数服从多数，那么Zookeeper的选举机制就必须由Zookeeper集群中的多个实例共同完成，那么这样一来，集群中的多个实例必须相互通信。

当然通信也不是问题，那么如果集群中的实例很多,网络通信就会变得异常复杂且低效。

而NameServer的设计目标是让网络通信变得简单，从而使性能得到极大提升。

为了避免单点故障，NameServer也必须以集群的方式部署，但是集群中各个实例相互之间不会进行通信。NamerServer是无状态的，可以任意部署多个实例。Broker会向每一台NamerServer注册自己，因此每一个NameServer实例都可以保存一份完整的路由信息。值得提一下的是，NameServer与每一台Broker机器保持长连接，间隔30s从路由注册表中将故障机器移除，但不会通知Producer和Consumer。