顺序消息

用途：确实需要“同一实体的事件按序处理”时正确实现，并理解代价

两种顺序

类型	含义	可行性
全局顺序	Topic 内所有消息按发送顺序消费	只能单队列单消费者，吞吐极低，几乎不该用
分区顺序	同一业务键（订单、账户）的消息有序	标准做法：按 key 路由到固定队列

生产端：用 MessageQueueSelector 以业务键哈希选择队列，保证同一实体的消息进同一队列。
- 队列数变更（扩容）会改变映射，历史消息与新消息可能落到不同队列 → 迁移期需要双读或冻结路由。
Broker 端：队列内 FIFO（RocketMQ 天然满足，前提是消息未被重试打乱）。
消费端：该队列必须单线程串行消费（顺序监听器会锁住队列），且失败时不能并发继续。

顺序消费下重试会阻塞该队列后续消息（避免乱序），因此：

问一句：“乱序真的会造成业务错误吗？”

优先用“消息自带版本/最终状态”消除顺序依赖，比维持顺序链路成本低得多。

顺序消费把并行度降到队列粒度：单队列吞吐受限于单线程处理速度。要提升吞吐只能增加队列数（同时保证 key 分布均匀），而热点实体（大客户订单）无法通过加队列解决——此时应重新设计消息内容（幂等 + 版本）而不是加顺序。