在很多业务场景中，比如订单状态变更、交易同步、写日志等，需要消息按发送顺序被消费。RocketMQ 提供顺序消息（Ordered Messages / FIFO Topic）特性来满足这一需求。然而顺序消息天然要保证同组消息的先后消费，这就限制了并发和吞吐量。下面介绍一系列方法，可以在尽量减少对顺序保证影响的前提下，提升 RocketMQ 顺序消息的吞吐量。
顺序消息的原理与瓶颈所在
RocketMQ 的顺序消息是通过“消息组”（MessageGroup）来区分顺序域。相同消息组的消息被保证落在同一个队列（MessageQueue）里，并由同一个消费者线程（或顺序 listener）按顺序消费。不同组之间可以并行。要保证生产顺序，还要生产者按顺序发送，不要并行发送同组消息。要保证消费顺序，消费端要是顺序消费，不使用并发消费方式。
瓶颈主要在于：
- 同一个 MessageGroup 的所有消息都集中在一个队列里，这个队列只能由一个线程顺序消费，吞吐能力受限。
- 生产端发送顺序性约束：如果多个线程或多个 Producer 并行发送同组消息，有可能导致序列错乱或影响顺序打印与存储效率。
- 消费端处理逻辑里如果有 I/O、RPC、数据库写入等慢操作，一个消息处理拖慢整个队列。
- 队列数少或消息组设计不合理，导致热点队列严重并发负载不均衡。
提升吞吐量的策略
以下是若干策略，可以帮助提高顺序消息场景的吞吐量，同时尽可能保留顺序性：
消息组设计更细粒度（分组拆分）
将顺序业务按组拆分。例如，不是把所有订单都归到一个消息组，而是按用户 ID、商家 ID、地域或订单类型等，分成多个消息组。这样不同组可以并行处理，不同组之间不需要顺序。这样可并行度提高，同时顺序性在每组内部得到保证。
增设更多 MessageQueue（队列）
创建 Topic 时调高读写队列数（ReadQueueNums 与 WriteQueueNums / ConsumeQueue 数量），让 Broker 上的队列、分区更多。这样消息组在映射到队列时，可以分散到多个队列里。多个队列意味着多个消费线程可以同时消费不同队列，从而增加总体吞吐量。
使用批量消费
在消费端开启批量消费，将多条消息一次性取来处理，而不是每条消息单独拉取、处理、应答。对于顺序 listener（MessageListenerOrderly 或类似顺序消费方式），如果业务允许，批量消息里仍维护顺序处理（批内顺序）。这样可以减少消费端的网络、IO、线程上下文切换等开销。
优化消费逻辑中的慢操作
消费端常常因为数据库访问、远程调用、写日志、文件系统 IO 等操作耗时过长。可以将这些操作优化或异步化。比如把部分操作放后台线程去做、或使用缓存减少数据库查询次数、减少同步阻塞等待、减少不必要的日志记录。这样一个消息处理的时间缩短，队列能更快地推进。
调整消费者并发度与线程配置
虽然顺序消费者一个队列一个线程消费是顺序消息的基本要求，但可以通过增加不同队列的消费者实例来并行处理不同队列。也可以在消费者内部调优线程池、消息预取、消费线程最小／最大数等参数以提升整体吞吐量。要注意不要超过队列数，否则部分消费者空闲。
硬件与 Broker 配置优化
- 提升 Broker 与 NameServer 的硬件资源，如多核 CPU，高性能 SSD，网络带宽优秀。
- 磁盘 I/O 优化，文件系统选择及刷盘策略调优。
- 数据存储与刷盘机制优化（如异步刷盘、写入合并等），减少写入延迟与锁竞争。
- 操作系统调优，例如合理的文件描述符数、网络 buffer 设置等。
监控与动态调整
建立监控系统，对各个队列的 lag（积压）、消费延迟、生产发送速度、消费速度等指标实时监控。根据队列积压情况，动态扩容队列数、部署更多消费者实例，或调整消息组与队列的映射策略。热点队列如果负载过高，可以拆分消息组或增加队列。
注意事项与折中
在追求吞吐量提升的过程中，需要注意以下折中问题：
- 顺序保证 vs 并发度：拆分消息组或增加队列数会减弱“全局顺序”的保证，只能保证组内顺序。若业务需要严格的全局顺序，改动空间小，吞吐量提升有上限。
- 批量消费可能延迟变大：批量取多条消息可能引入等待更多消息到达的延迟，对实时性要求高的业务可能不适合。
- 资源消耗：更多队列、更多消费者、更多线程意味着资源消耗增高（内存、CPU、网络）。要确保部署环境可承受。
- 故障与重试处理：如果某条消息处理失败阻塞队列，会拖慢组内后续消息。要妥善设置重试机制且避免 long blocking。重试次数、重试等待、超时处理等逻辑要慎定。
- 业务逻辑约束：有的业务逻辑本身对顺序性与即时性要求极高，不允许拆分或批量处理，这类场景提升空间有限。
总结
想要在 RocketMQ 顺序消息场景中提升吞吐量，并不是要完全牺牲顺序性，而是通过合理设计消息组、增加队列数、优化消费逻辑、开启批量消费、调整并发度，以及硬件与 Broker 的调优，来在“局部顺序 /组内顺序”模式下最大限度地并行处理，提高整体吞吐量。