RocketMQ 顺序消息与多线程分片：生产、存储、消费的一致性设计

MessageQueueSelector#

生产端通过 MessageQueueSelector 按业务键选队列，同一键的所有消息命中同一队列，这是顺序的起点：

1
SendResult send(MultiOrder order) {
2
    Message msg = new Message("ORDER_STATUS_TOPIC", "TagA",
3
            order.getOrderId(), JSON.toJSONBytes(order));
4
    return producer.send(msg, (mqs, message, arg) -> {
5
        long orderId = (long) arg;
6
        // & Integer.MAX_VALUE 而非 Math.abs：防止 Integer.MIN_VALUE 取 abs 仍为负
7
        int index = (int) ((Long.hashCode(orderId) & Integer.MAX_VALUE) % mqs.size());
8
        return mqs.get(index);
9
    }, order.getOrderId());
10
}

两个细节：Math.abs(Integer.MIN_VALUE) 仍返回负数，取模得到 -1 直接数组越界，用 & Integer.MAX_VALUE 抹掉符号位是标准写法；取模基数是队列总数，扩缩容时同一个键会命中新队列，这是扩容乱序的根源（见「方案一」）。Spring 环境下 RocketMQTemplate.syncSendOrderly(destination, msg, hashKey) 内置了同样语义的哈希路由，能接受固定哈希时可直接用。

串行发送：单一生产者 + 同键串行#

MessageQueueSelector 只保证「落点相同」，不保证「落点内先后」。官方把生产顺序性拆成两个条件：同一分片键的消息由同一个生产者实例发出；同键消息串行发送，多线程并行发送时到达顺序取决于线程调度，无法判定。工程上要么在实体维度串行化（同一订单的处理被分布式锁串行化时，发送天然有序，推荐先检查业务是否已有这个串行点），要么把消息交给按分片键分组的单线程发送器。

发送失败：重试仍发同一队列，但要业务兜底#

顺序消息的发送路径（sendSelectImpl）里 selector 只调用一次，重试复用同一个队列。这不会因换队列破坏顺序，代价是队列所在 Broker 宕机时重试只会反复失败。因此：同步发送，拿到 SendResult 才算成功（sendMsgTimeout 默认 3000 ms）；重试耗尽后落待发送表，由定时任务补偿重发。

补偿重发必须保留原始分片键（仍走 selector）与原始幂等键。发送超时不等于发送失败，原消息可能已投递成功；恢复任务若重新生成新消息 ID，幂等键就对不上，重复消息会绕过去重直接执行。保留原幂等键（订单号 + 目标状态），重复投递才会被幂等表挡住。

本地事务与发送的原子性：事务消息#

「先提交本地事务，再发消息」在两步之间崩溃时，下游永远不知道这笔变更。事务消息（半消息机制）把两步绑成原子操作：

回查依赖业务实现 checkLocalTransaction，用事务 ID 反查本地事务状态，查不到返回 UNKNOW 等下一轮，不要乱返回 ROLLBACK。回查有上限（transactionCheckMax 默认 15 次，超限后半消息被丢弃），所以回查查询必须可靠。事务消息只保证「本地事务 + 发消息」的原子性，下游消费成功靠消费端幂等。

顺序消费的三把锁#

DefaultMQPushConsumer 默认注册 MessageListenerConcurrently，拉到的消息丢进消费线程池（默认 20 线程），同队列的两条消息被两个线程同时拿走，谁先执行完取决于线程调度（引子里 300 ms 反超的来源）。把监听器换成 MessageListenerOrderly 后，ConsumeMessageOrderlyService（基于 4.9.x 源码）用三层锁把队列变成串行单元：

锁是刻意拆细的：队列本地锁覆盖「判断 + 取消息 + 消费」整个循环，消费锁只覆盖业务监听器执行期间，Rebalance 移除队列只需等当前这条消息消费完。串行的核心在 ConsumeRequest.run() 的 while 循环：锁内反复「取一批消息 → 加消费锁 → 调用业务监听器 → 按返回值决定继续或延迟重试」，单线程逐条推进；连续消费超过 60 s 会主动让出线程，避免饿死线程池。

由此得出关键推论：顺序消费的正确性依赖锁与路由信息的持续一致，乱序窗口有三个来源：锁过期（网络抖动、GC 停顿超过 60 s）、锁切换（Rebalance）、Broker 主从切换后的路由刷新。这是官方文档「极端情况下可能乱序」的出处，也是消费幂等必须存在的第二个理由（第一个是重复投递）。

并行度模型：队列数就是天花板#

1
整个消费组的有效并行消费单元数 ≤ Topic 队列总数
2

3
单个队列吞吐 ≈ 1000 ms / 单条业务处理耗时
4
消费组总吞吐 ≈ 队列数 × 单队列吞吐
5

6
例：单条消息处理 40 ms → 单队列约 25 TPS
7
    8 个队列 → 约 200 TPS
8
    32 个队列 → 约 800 TPS

两条纪律：调大 consumeThreadMax 不提升单队列吞吐，线程数只用于让多个队列同时被消费，超过实例分到的队列数就是空转；队列数少于实例数时多余实例分不到队列（同组内队列不共享），扩实例前核对队列数 ≥ 实例数。队列数是创建 Topic 时的容量决策，改动会引发分片重分布。

方案一：扩队列，处理扩容窗口的跨队列乱序#

扩队列是唯一能线性提升吞吐的手段，但取模基数变化会让同键消息跨队列：旧队列还压着「已支付」，「已发货」已进新队列，两个队列并行消费，顺序被打穿。严格做法是停写、等旧队列存量排空再切流；业务上往往退而求其次：接受窗口内乱序，靠状态版本号挡住过期状态（见「状态机校验」），扩容完成后窗口自动关闭。

方案二：消费端内存队列二次分发#

同键串行不必绑死在 MQ 队列上。监听器拿到一批消息后按键二次分发到固定槽位的内存队列，每个槽位单线程：同键仍在同一槽位内串行，不同键并行。把 consumeMessageBatchMaxSize 调大（如 16），监听器同步等待整批完成后返回 SUCCESS，单队列吞吐从 25 TPS 升到约 25 × 16（受槽位数与键离散度限制），队列数不动。

两个纪律：必须同步等待整批完成再返回 SUCCESS：Push 模式下返回即提交位点，异步投递后宕机，未落库的消息真丢，只能靠对账找回；慢键是队列下限，批内一条 5 s 的消息拖住整批，要单独优化或拆分。

方案三：把 IO 拆出顺序链路#

顺序链路里真正需要串行的往往只有「按版本落库」一步。消费端只做轻量校验 + 事件按序写入事件表（单条 2～5 ms），重活（外部调用、算账、通知）由异步 worker 按版本推进，不依赖 MQ 顺序。单队列吞吐升到 200～500 TPS，热点键（大商家占满队列）也得到缓解。代价是多一张事件表和一个 worker，重活的失败重试要自己设计。

方案四：升级 5.x 消息组 + Pop 消费#

生产端给消息设置 MessageGroup（语义等价于分片键），Topic 声明为 FIFO 类型；消费端 Pop 模式不要求实例绑定队列，同一消息组的消息处理期间锁定在一个消费者上。收益是乱序窗口比队列锁切换更小，消费者可水平扩、不受队列数约束；代价是一次性迁移成本，且 SimpleConsumer 一次拉多条时顺序性要业务自己保证。

选型对比#

四个方案不互斥，常见组合：先拆 IO（收益最大且不动分片），再扩队列，消费端叠内存队列兜峰值。

失败要先分类，再决定重不重试#

重试的价值取决于失败是否瞬时。瞬时失败（网络超时、数据库抖动）抛给 MQ 走本地重试；确定性失败（业务校验不通过、非法状态转换、消息体损坏）重试结果必然还是失败，直接落死信表并告警后返回 SUCCESS 跳过（让这类消息走完重试只是白停摆队列）。跳过即乱序，这个决定依赖两个配套：死信表有「人工或定时任务介入」的闭环；后续消息的合法性由状态机校验把守，一条消息进死信后其依赖消息会被级联拦下。这是预期行为：宁可级联进死信，不可错误执行。

并发消费的重试还会带来另一种重复：批量消费 2、3 两条，3 失败重试期间 2 可能被再次处理。无论哪种模式，重试和重复投递是常态，幂等不是优化项。

幂等键：业务唯一键，不是 msgId#

RocketMQ 的投递语义是 at-least-once：失败或超时就重投。exactly-once 需要 Broker 端去重，实现代价极高，官方不做。所有一致性设计收敛为一个问题：同一条消息被消费 1 次和 N 次，业务结果是否相同。

msgId 不能做幂等键：生产端重试、Broker 端写入都可能让不同 msgId 指向同一业务消息。幂等键取自业务语义：状态变更用 orderId + 目标状态，事件用事件源生成的 eventId。它同时覆盖两类重复：同一条消息被投两次，以及发送端补偿任务重发产生的「不同消息、同一操作」。

去重表与业务操作同事务#

去重记录与业务操作必须在同一事务：先记去重后执行业务，中间失败则这条消息永远不会再被处理；先执行业务后记去重，中间宕机则重投后重复执行。

1
@Transactional
2
public ConsumeOrderlyStatus handle(OrderStatusMsg m) {
3
    try {
4
        // bizKey = orderId + targetState，唯一键冲突即重复投递
5
        consumeRecordMapper.insert(m.getBizKey(), CONSUMED);
6
        orderMapper.updateState(m.getOrderId(), m.getTargetState(), m.getVersion());
7
        return ConsumeOrderlyStatus.SUCCESS;
8
    } catch (DuplicateKeyException e) {
9
        return ConsumeOrderlyStatus.SUCCESS;   // 幂等：重复消息视为成功
10
    }
11
}

三个坑：不要引入「消费中」中间态，业务执行期间重复消息到达会把它误判，处理慢的消息反复重试后进死信，要么加超时判定要么干脆用上图的原子写；去重表必须跟着业务键分库路由，与业务操作同库同事务，全局去重库破坏同事务前提；重试粒度是整条消息，业务 A 已执行、业务 B 失败重投后 A 会被再次执行，子操作（尤其不可事务化的外部调用）要么并入同一事务，要么各自幂等。

状态机校验：乱序发生时的止损#

幂等挡重复，挡不住乱序：位点重放、Rebalance 窗口、扩容迁移产生的乱序消息对幂等表是没消费过的新消息。第二道防线是消息携带目标状态与版本号，用带前置条件的原子更新拒绝非法转换。不要「先查状态、内存判断、再更新」三步走，查询与更新之间有并发窗口，先查后改挡不住并发重复：

1
UPDATE order_state
2
SET state = 3, version = version + 1
3
WHERE order_id = #{orderId} AND state = 2;   -- 仅当前状态是前置状态时才生效

影响行数为 0 即乱序、重复或上游状态已推进，按确定性失败落死信。这道防线把前面所有机制失效的后果收敛为「该消息与其后续依赖消息进死信」，错误状态永远写不进业务库。

版本缺口缓冲：让乱序自愈#

拒绝式的代价是瞬态乱序也要人工捞死信。缓冲式换一种思路：发现前置版本缺失（版本号不连续）时，消息落暂存表后返回 SUCCESS 放行队列；定时补偿任务扫描暂存表，前置版本补齐后重新按序处理。乱序被限制在单个键内，同队列其他单号不受影响。

默认拒绝式，缓冲式留给已知存在瞬态乱序窗口的场景（如扩容迁移期），并必须配暂存超时与暂存量告警两个上限，否则消息真丢时问题会被暂存表藏住。

位点提交与对账#

位点由客户端周期性提交 Broker，返回 SUCCESS 后消息移出 ProcessQueue、位点推进：时序上「处理完成」先于「位点提交」，所以返回 SUCCESS 前必须确保业务已持久化（方案二同步等待的原因）。位点按队列连续推进，宕机恢复从位点重放，已落库部分靠幂等表挡住，整条链路成立的前提仍是幂等写入与业务操作同事务。

以上机制把不一致概率压到很低但不是零（锁过期窗口、跳过的毒消息、回查超限丢弃的半消息），定时对账收尾：比对源与目的的不一致记录，以源为准修复（修复动作带幂等键），并监控不一致数的趋势，突变通常意味着上游某个机制失效了。