📌 消息队列如何保证消息顺序消费？

1️⃣ 问题背景

消息队列最大的优势是解耦、削峰和异步，但很多业务天然要求消息具有严格顺序，例如：

• 订单创建 → 支付 → 发货 → 收货
• 账户充值 → 扣款 → 冻结 → 解冻
• 库存增加 → 库存扣减
• 用户状态变更

如果消息乱序消费，例如"发货"先于"支付"执行，就会导致业务数据错误，因此顺序消费成为高并发系统中常见的设计要求。

2️⃣ 核心原理

几乎所有主流 MQ 都采用多个队列（Queue）或多个分区（Partition）的设计。

不同队列之间可以并行消费，而同一个队列内部按照 FIFO（先进先出）的方式存储消息。

只要同一个业务的数据始终进入同一个队列，那么 Broker 就能够保证它们的存储顺序。

3️⃣ 数据结构分析

生产端

生产者发送消息时，需要根据业务唯一标识（如 OrderId、UserId）选择固定队列。

以后所有 OrderId=1001 的消息都发送到 Queue3。

Broker

Broker 内部维护每个 Queue 的消息链表或日志文件。

由于写入采用追加模式，因此天然保证顺序。

消费端

消费端一个 Queue 对应一个消费线程，按照 Offset 顺序读取消息。

• 读取 Offset=1
• 处理完成
• 提交 Offset
• 继续读取 Offset=2

4️⃣ 算法分析

保证顺序消费通常遵循如下算法：

消费算法：

整个过程中不会开启多个线程同时消费同一个队列，因此不会发生乱序。

5️⃣ 执行流程

6️⃣ 实际案例

RocketMQ 顺序消息

发送消息时根据 OrderId 计算 QueueIndex：

这样所有订单1001的数据都会落入同一个 Queue。

Kafka 顺序消费

Kafka 的 Topic 会划分多个 Partition。

• Key 相同的数据进入同一个 Partition
• Partition 内按照 Offset 顺序追加写入
• 一个 Partition 同一时刻只会分配给 Consumer Group 中一个消费者实例

因此 Kafka 能保证 Partition 内部消息顺序，而不是整个 Topic 的全局顺序。

7️⃣ 优缺点分析

8️⃣ 面试常见问题

Q1：MQ 能保证全局顺序吗？

Q2：为什么生产者要按照业务 Key 选择队列？

Q3：消费者开启线程池还能保证顺序吗？

Q4：顺序消费为什么会降低性能？

9️⃣ 总结