单队列+单消费者不够，因集群部署时多实例可能同时绑定同一队列导致竞争消费；必须协同满足三点：声明队列时启用x-single-active-consumer=true、spring boot配置concurrency=1且手动ack、消费者逻辑严格单线程执行。
RabbitMQ 本身不保证全局消息顺序，Java 客户端必须靠队列绑定策略 + 消费线程控制 + 分区 Key 设计三者协同，才能在业务层面达成“同一实体严格有序、不同实体可并行”的效果。
为什么单队列 + 单消费者还不够？
单纯声明一个 Queue 并只起一个 @RabbitListener，看似能保序，但实际在集群或滚动发布时极易失效：多个实例可能同时绑定同一队列，触发竞争消费；即使配置了 concurrency:1，若未显式启用 x-single-active-consumer:true，RabbitMQ 默认允许多个消费者拉取消息，顺序立刻崩坏。
必须同时满足以下三点：
- 队列声明时传入
Map<string object></string>参数，设"x-single-active-consumer" = true - Spring Boot 配置中关闭自动扩缩：
spring.rabbitmq.listener.simple.concurrency=1且max-concurrency=1 - 消费者方法内禁止异步调用（如
CompletableFuture.runAsync）、禁止线程池提交，所有逻辑必须在当前线程完成
分区 Key 必须全局唯一且稳定哈希
业务上常说“按订单 ID 分组”，但直接用 orderId.toString().hashCode() 做路由键有隐患：不同 JVM 实例下 String.hashCode() 虽然算法一致，但若订单 ID 含中文或特殊字符，某些旧版 JDK 存在哈希冲突风险；更严重的是，若未来订单 ID 改为 UUID v4，其随机性会导致分组打散，同一订单消息落到不同队列。
推荐做法是用确定性哈希函数，并统一收口：
- 使用
Objects.hash(orderId)或MurmurHash3.hash64(orderId.getBytes())替代原生hashCode() - 路由键格式固定为
"order." + (hash % queueCount)，其中queueCount是预设队列数（如 4 或 8），避免动态计算导致不一致 - Key 字符串必须全程不参与业务逻辑（比如不能把 Key 当作数据库字段存），只用于路由分发
发送端必须用 convertSendAndReceive 或 send 显式指定 routingKey
rabbitTemplate.convertAndSend(exchange, routingKey, message) 是唯一可控方式。切勿依赖默认交换机直投队列（即空 exchange + 队列名当 routingKey），因为这种方式绕过 Exchange 路由逻辑，无法做 Key 分组；也别用 convertAndSend(queueName, message)，它底层会走默认 Direct Exchange，routingKey 等于队列名，彻底失去分组能力。
正确示例：
String routingKey = "order." + (MurmurHash3.hash64(orderId.getBytes()) % 4);
rabbitTemplate.convertAndSend("order.exchange", routingKey, order);
注意：order.exchange 必须是 DirectExchange 类型，且每个 routingKey（如 order.0）都已绑定到对应队列（q_order_0）。
消费者端要防“假单线程”陷阱
即使配置了 concurrency=1，如果监听方法返回值是 void 且未手动 ack，RabbitMQ 默认 autoAck=true，消息一送达就删，崩溃后消息丢失；若开了 manual ack 但没 catch 所有异常，未 channel.basicNack，消息会卡住不动。
真正安全的写法：
- 配置
acknowledge-mode:manual - 监听方法签名带
Channel channel和Delivery delivery（或用@Header(AmqpHeaders.DELIVERY_TAG)） - 所有业务逻辑 try-catch 包裹，成功则
channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false)，失败则basicNack并考虑死信路由 - 禁止在监听方法里 new Thread / submit 到线程池 / 调用 @Async 方法
顺序性最脆弱的环节不在发送，而在消费线程模型失控——一旦跨线程，FIFO 就只是幻觉。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
