1 介绍

消息的有序性在很多业务场景中占有很重要的位置。
比如购物场景，需要按照创建订单 --> 订单付款 --> 完成订单顺序执行。
又比如出行场景，接单 --> 接送到达目的地 --> 付款 --> 完成订单。
这种是严格按照顺序执行的，这样的顺序消费才不会出问题，而且各个订单之间是互相独立和并行执行的。
所以，在MQ中，如何稳定地保证顺序性消息处理，是一个不可避免的话题。

2 消息的有序性说明

消息的有序执行，一般不是单个组件的能力。而是整个消息从生产，排队，存储到消费都是有序的，比如上面提到的购物和出行场景。
这就要求我们在消息队列（如果是Kafka，还是RocketMQ、RabbitMQ）中，保证以下前提：

消息生产的有序性：即生产者组件有序发送消息
消息入出队列的有序性：即消息是按照进入的先后顺序排队列放的，遵循FIFO原则。
消息的存储的有序性：与上一点一致，部分场景下为了提高可用，就是要持久化到磁盘，这时候应该遵循有序存放，才能保证后续有序消费
消息消费的有序性：即按照顺序进行消费。又分为全局顺序消息与部分顺序消息，全局是指Topic下的所有消息都要保证顺序；部分顺序消息保证每一组消息被顺序消费即可。

这边还有个问题，如果想让全局都是顺序性消费，那么只能用一个消费者去消费队列（一般来说也是单个生产者），这是会严重影响整体性能的，一般没这个，都是分组顺序执行消费的。

2.1 消息生产的有序性

要保证整个消息队列的有序性执行，首先要保证消息生产的有序性。
RocketMQ在Broker中防止了很多Topic，主题（Topic）可以看做消息的归类，我们将消息进行类型划分，相同类型的消息称为一个 Topic。比如我们在淘宝或京东上购买商品的的过程，就可能产生：购物车消息、交易消息、物流消息等，1条消息必然归属于1个 Topic 。
1个 Topic可以有0 ~ n 个生产者向其发送消息；也可以被 0~n 个消费者订阅和处理，于是就有出现了生产者组和消费者组，如下图：

或者同一个Topic中，创建不同的Queue，同一个消息生产者将消息隔离发送到不同的Queue中：

按照上述的模式，同理，我们只需要保证一组相同的消息按照给定的顺序存入同一个队列中，就能保证生产者有序存储，比如一次完整的消费过程：创建订单、付款、完成订单按照顺序在一个队列（Queue）中执行那就可以了。

★ 同时我们要保证同一组的消息在消息生产的时候投送到一个组中。这个相对来说不难，可以这么做：

比如一个订单的多个子消息的父订单号是一致，我们把这些消息按照订单号取模，投送到对应的Queue中就行了，比如订单号 % 队列数量（ 163105015 % 9）
发送消息自定义消息标签（消息标签可以用队列编号命名），一组消息使用同一个标签，改组标签对应的消息都投向标签所在的队列。

★ 业务程序方面，必须使用同步发送的方式，这样才能保证生产者发送的消息有序，否则按照FIFO的原则，很可能 订单完成 会被先消费。
但是我们业务程序，比如Java代码中为了提升性能，可能使用多线程的模式进行事件触发。多线程下保证生产者顺序性，可以使用锁并配合 spring的publish event（按照顺序执行的内部队列），持久化之后，再按照先进先出的顺序推送消息进入MQ中。
可以参考下，大概就是将你的事件进行顺序化一下。

★ 上述方法也不能完完全全的避免顺序化执行。如果broker服务发生故障，或者消息发生丢失，都有可能导致事件消费不完整，出现不一致的问题。

2.2 消息有序性存储

Broker 存储架构采用文件存储机制（类似Kafka），即直接在磁盘上使用文件来保存消息，而不是采用Redis或者MySQL之类的持久化工具。
它会把消息存储所属相关的文件存储在ROCKETMQ_HOME下，包含三个部分：

CommitLog 消息元数据
ConsumeQueue 消息逻辑队列
IndexFile 索引文件

存储消息的元数据，所有消息都会顺序存入到CommitLog文件中。
ConsumeQueue是指存储消息在CommitLog上的索引，一个MessageQueue一个文件，记录当前MessageQueue被哪些消费者组消费到了哪一条CommitLog。
所以一切都是顺序性操作下来的，而且按照 MessageQueue 做了隔离了，不用担心乱序的问题。详细参考《MQ系列8：数据存储，消息队列的高可用保障
》

2.3 消息消费的有序性

最后一步就是消费的有序性了，既然消息生产和消息持久化都可以做到有序性。那么只要保证消费的有序性，就能保证整个消息队列的有序执行。
这边以RocketMQ为例子，RockerMQ采用MessageListener 回调函数进行监听，监听到消息之后进行数据处理。MessageListener主要提供了两种消费模式，如下：

有序消费模式MessageListenerOrderly
并发消费模式MessageListenerConcurrently

其中有序消费模式有序消费模式MessageListenerOrderly可以保证按照顺序进行消息处理。但是消费的业务代码实现是多线程并行的，依然是无法保证的。
实际上RocketMQ也是这么做的，MessageListenerConcurrently拉到消息之后会提交到线程池去消费，而MessageListenerOrderly则是通过分布式锁和本地锁保证同时只有一条线程去消费一个队列（Queue）上的数据。
这种消费模式就是使用以下3把锁来确保顺序性：

broker端的分布式锁
messageQueue的本地synchronized锁
ProcessQueue的本地consumeLock

3 总结

要消息的顺序性消费：需要保持先后顺序的消息放到同一个消息队列中(kafka中就是partition,rabbitMq中就是queue)，然后使用线程池消费的时候使用分布式锁和本地锁保证同时只有一条线程去消费一个队列（Queue）上的数据。

Java 面试宝典是大明哥全力打造的 Java 精品面试题，它是一份靠谱、强大、详细、经典的 Java 后端面试宝典。它不仅仅只是一道道面试题，而是一套完整的 Java 知识体系，一套你 Java 知识点的扫盲贴。

它的内容包括：

大厂真题：Java 面试宝典里面的题目都是最近几年的高频的大厂面试真题。
原创内容：Java 面试宝典内容全部都是大明哥原创，内容全面且通俗易懂，回答部分可以直接作为面试回答内容。
持续更新：一次购买，永久有效。大明哥会持续更新 3+ 年，累计更新 1000+，宝典会不断迭代更新，保证最新、最全面。
覆盖全面：本宝典累计更新 1000+，从 Java 入门到 Java 架构的高频面试题，实现 360° 全覆盖。
不止面试：内容包含面试题解析、内容详解、知识扩展，它不仅仅只是一份面试题，更是一套完整的 Java 知识体系。
宝典详情：https://www.yuque.com/chenssy/sike-java/xvlo920axlp7sf4k
宝典总览：https://www.yuque.com/chenssy/sike-java/yogsehzntzgp4ly1
宝典进展：https://www.yuque.com/chenssy/sike-java/en9ned7loo47z5aw

目前 Java 面试宝典累计更新 400+ 道，总字数 42w+。大明哥还在持续更新中，下图是大明哥在 2024-12 月份的更新情况：

想了解详情的小伙伴，扫描下面二维码加大明哥微信【daming091】咨询

同时，大明哥也整理一套目前市面最常见的热点面试题。微信搜[大明哥聊 Java]或扫描下方二维码关注大明哥的原创公众号[大明哥聊 Java] ，回复【面试题】即可免费领取。

阅读全文

深挖 RockectMQ 核心原理