在分布式系统中，确保消息按照预期顺序进行处理是一项具有挑战性的任务。特别是在使用 RabbitMQ 作为消息队列时，由于多个消费者可能同时监听队列，如何保证消息的有序性成为一个重要的问题。本文将深入讨论在 RabbitMQ 中如何确保消息的顺序消费。
背景
考虑一个典型的业务场景：支付场景处理。订单的生命周期通常包括创建、支付、完成等多个阶段，而这些阶段的处理顺序对业务逻辑非常关键。在分布式环境下，多个消费者可能同时监听订单处理队列，因此确保订单内部的消息按照顺序处理成为一项重要任务。
挑战
在分布式系统中，存在以下挑战：
- 并发消费者： 多个消费者同时监听队列，导致消息的竞争消费。
- 消息乱序： RabbitMQ 本身不保证消息的有序性，消息的顺序可能与发送顺序不一致。
技术方案（参考阿里云社区）
整体概述
在消息队列中保障消息的顺序性通常涉及将相同业务标识的消息发送到同一个队列，并确保消费者按照一定的顺序从队列中拉取并处理消息。以下是一个通用的技术方案描述：
哈希策略决定队列选择： 通过一定的哈希计算策略， 以确保业务标识相同的消息被发送到同一个主题或队列， 比如同一个订单的创建， 支付， 完成这三个消息一定要在一个队列中。
消费者有序拉取： 消费者按照顺序从队列中拉取消息。由于相同业务标识的消息被发送到同一个队列，保证了它们在队列中的有序性。
消费具体如何保证消息消费的顺序呢？
消息消费的顺序性控制：
向Broker发起锁定该消息队列的请求： 消费者在开始处理消息之前，首先要向消息队列的 Broker（消息中间件）发起请求，请求锁定（获取锁）该消息队列。这是为了确保在特定时刻只有一个消费者能够处理这个消息队列，从而避免并发问题。
拉取队列中消费的位置： 一旦消费者成功获取到锁，它需要确定从消息队列中拉取消息的位置。这通常包括消费者已经处理过的消息位置，以便继续处理未处理的消息。这是为了保证消息的顺序性和避免重复处理。
加锁成功则创建该消息队列的拉取任务，否则等待其他消费者释放该消息队列的锁： 如果消费者成功获取到锁，说明它有权处理消息队列。在这种情况下，消费者会创建一个拉取任务，即开始从消息队列中拉取消息并进行处理。如果加锁失败，说明其他消费者可能正在处理该队列，此时当前消费者需要等待其他消费者释放锁，然后再次尝试获取锁。
前置条件的引入： 在消费消息前，引入一些前置条件，例如查询同一个订单号下，上一个消息是否被成功消费或者存入DLQ队列中。可以使用消息辅助表进行记录。
这个过程的目的是确保在同一时刻只有一个消费者能够处理特定的消息队列，从而保证消息的有序性和避免并发冲突。这种机制常见于需要强调消息处理顺序的业务场景，例如订单处理系统中，确保订单的创建、支付、发货等步骤按顺序执行。
消息的重试
消息重试与DLQ队列：
最大重试次数： 设置最大重试次数，当消息重试次数达到最大之后，将消息存入死信队列（DLQ）。
重试次数的影响： 注意重试机制对顺序性的影响。如果一个消息的重试次数达到最大值并被存入DLQ队列，可能会中断该消息与后续消息的顺序性。
总结
为了保证消息的顺序性，需要在生产、存储、传递、放置和消费等多个环节采取综合措施。向Broker发起锁定消息队列的请求，确保同一时刻只能被消费者组内一个消费者消费，同时在消息的生产端采用哈希策略确保同一 HashKey 的消息被分配到同一队列。此外，在消息的存储和传递中，采用支持有序消息的队列，保持消息插入顺序。对于消息的消费，通过批量拉取消息和消息提交到内部线程池的方式，保证同一时刻消费队列只会被线程池中的一个线程消费。同时，设置适当的重试机制和死信队列，以应对消费失败的情况。在消费前通过前置条件检查，如查询消息辅助表，确保上一个消息是否被成功消费或存入DLQ队列，进一步确保了整个消息系统的有序性。