程序员小潘

顺序消息是 RocketMQ 提供的一种高级消息类型，支持消费者按照发送消息的先后顺序获取消息，从而实现业务场景中的顺序处理。顺序消息的顺序关系通过消息组（MessageGroup）判定和识别，发送顺序消息时需要为每条消息设置归属的消息组，相同消息组的多条消息之间遵循先进先出的顺序关系，不同消息组、无消息组的消息之间不涉及顺序性。比如：一条订单从创建到完结整个生命周期内产生的消息，如果要保证消费的顺序性，则可以用订单号作为 MessageGroup。

消费者订阅了某个主题后，RocketMQ 会将该主题中的所有消息投递给消费者。若消费者只需要关注部分消息，可通过设置过滤条件在 Broker 端进行过滤，只获取到需要关注的消息子集，避免接收到大量无效的消息。以电商交易场景为例，用户从下单到拿到商品，中间会产生很多消息，被不同的下游系统订阅消费。下游系统往往只关心自己需要处理的消息，比如支付系统只关心支付消息，这时候生产者就可以在发送消息的时候给消息打上标签，下游系统按需订阅即可。

RocketMQ 5.0 消费者引入了一种新的消费模式：Pop 消费模式，目的是解决 Push 消费模式的一些痛点。要实现这个目标还是有不小的挑战，看看 RocketMQ 是如何做到的吧。

RocketMQ 相较于其它消息队列产品的一个特性是支持延时消息，也就是说消息发送到 Broker 不会立马投递给消费者，要等待一个指定的延迟时间再投递，适用场景例如：下单后多长时间没付款系统自动关闭订单。RocketMQ 4.x 版本的延时消息存在一定的局限性，实现原理是：Broker 内置了名称为的Topic，包含 18 个对应延时级别的队列，每个延时级别的时间是固定的。

RocketMQ 5.0 引入了新的 Proxy 组件，为了便于多语言客户端 SDK 的开发维护，客户端的很多功能也都下沉到了 Proxy，客户端因此变得更加轻量化了，新版客户端源码简洁易懂。源码相较于 4.x 版本变化很大，本文分析 RocketMQ 5.0 Producer 客户端和 Proxy 的消息发送整体流程。服务端源码版本基于 5.0.0、客户端源码版本基于 java-5.0.4。

RocketMQ 4.x 版本之前，一套完整的 MQ 服务包含的组件有：Namesrv、Broker、Consumer、Producer。RocketMQ 5.0 版本之后，官方引入了一个新的组件：Proxy，它的作用是什么呢？

1. 前言在RocketMQ体系中，系统预定义了一系列的Topic，开发者自定义的Topic名称不可以和它们重名，否则会抛异常。这些预定义的系统Topic都有它们各自的用途，例如RMQ_SYS_TRANS_OP_HALF_TOPIC用来存放半事务消息，SCHEDULE_TOPIC_XXXX用来存放延时消息等等。其中有一个Topic较为特殊，它就是TBW102，它有什么用呢？​Producer在发送消息时，默认情况下，不需要提前创建好Topic，如果Topic不存在，Broker会自动创建Topic。但

1. 前言在消息中间件中，消费者对于消费成功的消息，一般是需要返回ACK给Broker的，它的目的是让Broker知道消息已经被成功消费，不必再投递给其它消费者重试了。在RocketMQ中，这一过程的具体实现为「上报消费位点」，RocketMQ没有办法针对单个消息返回ACK，Consumer只能上报MessageQueue已经消费的消息偏移量。​Consumer实例启动时，同一Group下所有的实例都会进行「重平衡」操作，给自身重新分配MessageQueue，默认的分配策略就是「平均分配」，这意味着

1. 前言Consumer启动后会立即触发一次「重平衡」操作，给自己分配MessageQueue，对于新分配的MessageQueue会提交拉取请求，开始拉取消息进行消费。应用在消费消息时，返回消费状态CONSUME_SUCCESS或RECONSUME_LATER，如果消息消费失败，消息并不会丢失，Broker会在稍后一段时间重新投递该消息，如果超过16次都消费失败，Broker会认为Consumer已经不具备消费这条消息的能力，会将消息扔到死信队列，这个时候就需要人工介入处理了。​以上是Rocket

基于4.9.0版本分析，https://github.com/apache/rocketmq/tree/rocketmq-all-4.9.01. 缘起阿里内部为了适应淘宝更快、更复杂的业务，在2001年启动了「五彩石项目」，第一代消息队列服务Notify在这个背景下应运而生。2010年ActiveMQ仍然作为核心技术广泛应用于阿里内部各个业务线，与此同时，支持顺序消息、事务消息、海量消息堆积的消息服务也是阿里急需的，在这种背景下，2011年MetaQ诞生。2011年Kafka开源，2012年阿.

RocketMQ拥有海量的消息积压能力，主要是因为它支持消息的持久化，Broker接收到消息后，会将消息写入CommitLog文件。但是，磁盘IO的效率较低，为了保证性能和吞吐量，RocketMQ通过顺序写、内存映射和零拷贝、异步刷盘等一系列手段来优化性能。​首先是Linux系统的高速页缓存(PageCache)，通过将一部分内存用作PageCache，写数据时先写到Cache，再由异步线程将脏页数据同步到磁盘，顺序写的性能几乎等于写内存。读数据时先读到Cache，再次读就能命中缓存，而且在PageCa

1. 前言顺序消息是RocketMQ的特性之一，它可以让Consumer消费消息的顺序严格按照消息的发送顺序来进行。例如：一条订单产生的三条消息：订单创建、订单付款、订单完成。消费时要按照这个顺序依次消费才有意义，但是不同的订单之间这些消息是可以并行消费的。顺序消息可以分为全局有序和分区有序，绝大部分场景下，分区有序就已经能够满足需求了，因此本文会重点分析。​全局有序：某个Topic下所有的消息都是有序的，所有消息按照严格的先进先出的顺序进行生产和消费，要求Topic下只能有一个分区队列，且Cons

1. 前言RocketMQ采用2PC的思想，实现了Producer发送「事务消息」。事务消息的提交分为两个阶段，阶段一，Producer发送半事务(Half)消息到Broker，Broker存储消息，然后响应消息写入结果，此时消息对Consumer是不可见的。阶段二，Producer根据消息发送结果做对应的处理，如果消息发送成功，则开始执行本地事务，并提交事务状态给Broker，事务状态有三种，对应的Broker动作为：COMMIT_MESSAGE：事务提交，消息对Consumer可见。ROLLBA

1. 前言定时消息(延迟消息)是RocketMQ比较有用的特性之一，定时消息被发送到Broker后，不会马上投递给Consumer，而是等待特定的时间，然后再投递消费。应用场景举例：用户下单后，系统锁定库存，如果用户在15分钟内未付款，系统自动取消订单，释放库存让其他用户有购买的机会。这种场景通过延迟消息就可以很轻松的实现。​延迟消息并不支持用户指定任意时间，而是通过设置延迟级别来指定的。RocketMQ最多支持18个延迟级别，每个延迟级别对应的延迟时间可以通过配置messageDelayLevel自

1. 前言之前的文章介绍了Consumer是怎么拉取消息的，但是没有介绍Broker是如何处理Consumer消息拉取请求的，Broker在接收到Consumer的消息拉取请求后，是如何检索消息然后投递给客户端的呢？本篇文章会详细分析。​回顾一下Consumer消息拉取流程，Consumer服务启动会做一次重平衡操作，重新分配MessageQueue，对于新分配的MessageQueue会构建对应的PullRequest去拉取消息，此时PullMessageService线程会被唤醒，调用PullAP

1. 前言MQConsumer是RocketMQ提供的消费者接口，从接口定义上可以看到，它主要的功能是订阅感兴趣的Topic、注册消息监听器、启动生产者开始消费消息。​消费者获取消息的模式有两种：推模式和拉模式，对应的类分别是DefaultMQPushConsumer和DefaultMQPullConsumer，需要注意的是，在4.9.0版本，DefaultMQPullConsumer已经被废弃了。Push模式下，由Broker接收到消息后主动推送给消费者，实时性较高，但是会增加Broker的压力。

1. 前言Broker会把Producer发送的消息写入到CommitLog，理论上来说，RocketMQ只要有CommitLog文件就可以正常运行了。构建额外的ConsumeQueue是为了加速消费者的消费效率，构建Index文件的目的又是什么呢？​Index文件是否存在，都不影响RocketMQ生产者和消费者的正常运行，它的目的仅仅是提高消息查询的效率。如果我们要根据Key或时间段查询消息，通过CommitLog去检索无疑性能是非常差的，通过空间换时间，往CommitLog写入消息后，再往Inde

1. 前言理论上来说，RocketMQ只要有CommitLog文件就可以正常运行了，那为何还要维护ConsumeQueue文件呢？​ConsumeQueue是消费队列，引入它的目的是为了提高消费者的消费速度。毕竟RocketMQ是基于Topic主题订阅模式的，消费者往往只关心自己订阅的消息，如果每次消费都从CommitLog文件中检索数据，无疑性能是非常差的。有了ConsumeQueue，消费者就可以根据消息在CommitLog文件中的偏移量快速定位到消息进行消费了。​之前的文章已经说过，Brok

1. 前言生产者调用MQProducer.send()方法会将消息发送到Broker，Broker是如何处理该请求，以及消息是如何存储的呢？​RocketMQ网络通信协议被封装成Java对象RemotingCommand，消息发送也是一个请求，对应的请求头为SendMessageRequestHeader，头信息里就标明了消息是由哪个Group生产的、要发到哪个Topic下、消息属性是什么等等，这里就不展开了。总之，客户端要发送消息，必须构建RemotingCommand，再通过Netty客户端将请求

1. 前言MQProducer是RocketMQ提供的生产者接口，默认实现为DefaultMQProducer，如果要发送事务消息，对应的实现类为TransactionMQProducer。本篇暂不讨论事务消息，主要分析下默认生产者的启动和发送消息的流程。​DefaultMQProducer仅仅是RocketMQ暴露给用户使用的外观类，它内部持有一个生产者实现DefaultMQProducerImpl，它才是具体的执行者。使用这种结构的好处是，RocketMQ在后续版本可以任意更换实现类，这一切对用户

1. 前言RocketMQ架构体系里有四个角色：NameServer、Broker、Producer、Consumer。其中，Broker统称为服务端，Producer和Consumer统称为客户端。客户端要如何与服务端通信？拿消息发送举例，一个消息可以发送到哪些Broker上？有新的Broker上线/旧的Broker下线，客户端如何感知到？这些事情就是NameServer干的活。​NameServer的两大职责：路由管理、服务注册与发现。它就像微服务架构中的【注册中心】，类似于Zookeeper，但