SpringCloud Stream整合RocketMQ事务消息实战：可靠消息与幂等设计

1. 为什么不直接用RocketMQ客户端，而是再套一层Stream

1.1 没有Stream时的常见痛点：从一个订单积分的需求说起

之前做了一个订单支付成功后的积分发放需求，业务链路本身并不复杂：支付回调成功，先写订单表，再发一条MQ消息通知下游系统增加积分、发短信、更新库存。刚开始图省事，直接在Service里注入RocketMQTemplate往topic里塞消息，接口调通了就上线了。结果跑了两个月，问题陆续冒出来：支付回调重复触发导致重复发消息、业务事务回滚了但消息已经发出去了、下游消费成功了但ACK丢失导致消息重复投递。最麻烦的是，组里几个服务各自用不同的方式写MQ相关的代码，有的直接new Producer，有的封装了一层工具类，有的用注解监听，风格完全不统一，换个topic都要翻半天代码。

后来把消息链路重构成SpringCloud Stream + RocketMQ，才真正体会到Stream这层抽象的价值。Stream做的事情不复杂，但很关键：把消息中间件的差异屏蔽在Binder层，业务代码面对的不再是RocketMQ的Producer、Consumer这些API，而是统一的MessageChannel和@StreamListener。也就是说，哪怕未来把RocketMQ换成Kafka，业务代码几乎不用动，只需要换一个Binder依赖，改一下配置。

1.2 Stream的三大抽象：Destination、Binder、Binding到底各管什么

Stream这套抽象可以拆成三个核心概念：Destination、Binder、Binding。理解这三个东西，很多配置就不会觉得玄乎了。

• Destination：消息通道的目标地址，翻译成RocketMQ就是topic名。配置里写的destination: order-topic，本质上就是在声明一个逻辑地址。
• Binder：对接具体消息中间件的适配层。RocketMQ有RocketMQBinder，Kafka有KafkaBinder。它负责把Stream的统一操作翻译成RocketMQ的底层调用。
• Binding：把生产者和消费者与某个Destination连接起来的绑定关系。一个Binding包含input或output两种方向，input对应消费者，output对应生产者，同时会把group、并发消费、重试策略等参数全部挂在这个Binding上。

用生活化的方式类比：Destination是门牌号，Binder是帮你找到门牌号的房屋中介，Binding是你和中介签的合同。合同里规定了你看房子的频率（并发数）、钥匙丢了怎么办（重试）、房租到期后要不要续（消费组）。平时你只需要知道门牌号，不需要关心中介具体怎么找到房子。

这套抽象带来的直接好处是：业务代码从“面向具体的MQ API编程”变成“面向消息通道编程”。我在实际项目中感受最深的一点是，测试阶段可以引入一个内存Binder，单元测试里不需要真的启动RocketMQ就能验证消息收发逻辑，这对CI流水线来说太重要了。

1.3 事务消息和Stream的关系：抽象层做不到的事情

Stream的抽象虽然方便，但有一个前提：它默认处理的是普通消息，也就是发送后不管成功失败、不保证和本地事务一致的那种消息。如果业务需要“本地数据库操作和发消息要么一起成功、要么一起失败”，Stream的MessageChannel本身并没有提供这个能力，因为这个语义必须由消息中间件底层来支撑。

RocketMQ从4.3.0版本开始支持事务消息，核心机制是半消息加回查。SpringCloud Stream的RocketMQ Binder虽然暴露了Binding层的抽象，但事务消息的完整控制仍然需要直接使用RocketMQTemplate，通过它注册RocketMQLocalTransactionListener，让本地事务的提交或回滚状态能够传回Broker。所以实际项目里的通用做法是：普通消息走Stream的通道，事务消息走RocketMQTemplate，二者共存，各干各擅长的活。我在下文落地代码里会把这个结构完整展示出来。

2. RocketMQ事务消息的执行全过程：半消息、回查与状态提交

2.1 先写库还是先发消息：一个经典的两难问题

没有事务消息之前，谈到“可靠消息”，最常见的两个方案都有明显的缺陷。

先发消息再写库：消息发出去了，下游消费者立即处理，结果查订单发现订单还没写入，导致下游处理失败。如果本地数据库操作因为某种原因回滚了，消息已经无法撤回，下游已经基于错误的事实执行了业务动作，这就是典型的账对不上的问题。

先写库再发消息：数据库事务提交后，MQ调用如果超时或者网络抖动，消息就丢了，下游永远感知不到这笔订单。虽然可以在业务表里加一个“消息发送状态”字段，用定时任务扫表补偿，但这会引入额外的表、调度任务和人工干预。

事务消息的思路是把这个两难问题交给Broker来解决：业务方先发送一条“半消息”，这条消息暂时不投递给消费者；然后执行本地事务；根据本地事务的执行结果，再通知Broker是Commit还是Rollback。整个过程看起来就像消息中间件和业务数据库在做一个分布式事务协调。

2.2 半消息是什么：对消费者不可见，对生产者可见

半消息是理解RocketMQ事务消息的钥匙。它的本质是：消息已经发送到了Broker，但Broker把它存放在一个特殊主题下，而不是直接放到业务主题。这个特殊主题在RocketMQ源码里叫RMQ_SYS_TRANS_HALF_TOPIC，可以通俗理解为“事务消息暂存区”。在这种状态下，普通消费者在业务topic上收不到这条消息，因为Broker不会让半消息进入正常消费链路。

为什么要这样设计？关键是要保证“本地事务执行结果”和“消息是否可见”两个状态同步。如果消息一开始就可见，消费者可能立刻处理，而这时本地事务还没提交，就会出现脏读；如果消息一开始不可见，等本地事务提交后再变成可见，消费者看到的数据一定来自已经提交的本地事务，逻辑上才自洽。

在实际编码时，生产者发送半消息后不能直接发普通消息。RocketMQTemplate里有一个专门的方法：sendMessageInTransaction。这个方法内部会先发送半消息，再回调executeLocalTransaction执行本地事务，然后根据返回值决定提交还是回滚。对于调用方来说，这个流程看起来就是一个同步调用：事务成功了消息就发出去，失败了消息就消失，不需要自己拼状态。

2.3 回查机制的触发条件与执行逻辑

回查机制是事务消息可靠性的保障，也是很多人觉得难的地方。回查到底在解决什么问题？简单说：生产者向Broker提交半消息之后，Broker得到的最终状态可能因为网络异常、生产者进程崩溃等原因丢失，此时半消息会一直滞留在暂存区。Broker没法一直等下去，所以在一定时间后主动去问生产者：“你那条本地事务到底提交了没有？”

这个“主动询问”的过程，在代码里对应的是RocketMQLocalTransactionListener的checkLocalTransaction方法。正常流程下，如果本地事务执行得很快，executeLocalTransaction会直接返回COMMIT或ROLLBACK，Broker不需要回查；只有Broker长时间没有收到提交指令，或者收到的是UNKNOWN状态，才会触发回查。

这里有一个很重要的设计约束：checkLocalTransaction不能依赖内存状态，因为生产者进程可能已经重启过。正确做法是根据消息里携带的业务唯一键，去数据库里查一下本地事务的结果。比如订单服务发送事务消息时带上orderId，回查时就去订单表查这个orderId是否存在，存在说明本地事务提交成功，返回COMMIT；不存在说明事务回滚了，返回ROLLBACK；如果暂时查不到但业务又可能在处理中，返回UNKNOWN让Broker过段时间再查。

我见过不少同事在checkLocalTransaction里返回UNKNOWN之后就不再管了，结果消息一直处于未知状态，延迟越来越大。记住，UNKNOWN不是终态，它只是告诉Broker“我还没查清楚，你再等等”。正确做法是配合数据库查询逻辑，保证最终能返回COMMIT或ROLLBACK中的一种。

2.4 普通消息与事务消息的差异对比

这张表也解释了为什么我建议项目里两条链路并存：强一致性的业务走事务消息，允许丢失或者可补偿的异步通知走普通消息。如果无脑全上事务消息，性能损耗和复杂度都会成倍增加。

3. 发送端可靠：从“发出去”到“确认落盘”

3.1 可靠消息的定义：至少一次投递意味着什么

谈到可靠消息，首先要纠正一个常见误解：可靠并不等于“绝对不丢”。消息系统在分布式环境下，网络分区、进程崩溃、磁盘故障都可能发生，没有任何方案能保证绝对不丢，最多只能做到“至少一次投递”（At Least Once）。这个语义的含义是：消息要么不投递，投递就一定会投递成功，但是可能重复投递。

正是因为“至少一次”的存在，发送端要做的事情不仅仅是把消息发出去，还要确认Broker真的接收并持久化了。如果只是调用了send方法而不检查返回值，在网络抖动导致发送超时时，你并不知道消息是已经落在Broker上了，还是压根没发出去，这个不确定性才是消息丢失的真正来源。

RocketMQ的同步发送会返回SendResult，里面有sendStatus，只有SEND_OK才表示消息成功写入Broker。在事务消息场景下，sendMessageInTransaction的返回值代表的是本地事务执行的结果状态，而不是消息是否落盘，这一点要区分清楚。

3.2 同步发送与发送结果的判定

事务消息内部一定是同步发送半消息的，因为后续要等Broker确认半消息已经存储成功，才能继续执行本地事务。如果半消息发送失败，本地事务根本不应该执行，否则会出现“业务已经改了，消息却根本不在Broker上”的极端情况。

在事务消息里，这个逻辑已经封装好了：sendMessageInTransaction会先同步发送半消息，如果半消息发送异常，会直接抛异常，本地事务就不会被触发。对于普通消息，我建议也尽量使用同步发送，并且主动判断SendResult。下面是一段实际项目里我常用的发送封装逻辑：

java复制public boolean sendReliable(String destination, Message<?> message) {
    SendResult result = rocketMQTemplate.syncSend(destination, message);
    if (result == null || result.getSendStatus() != SendStatus.SEND_OK) {
        log.error("消息发送失败, destination={}, msgId={}", destination, message.getHeaders().getId());
        return false;
    }
    return true;
}

这里有一个细节：syncSend方法在RocketMQTemplate里是支持超时时间的，默认是3000毫秒。如果业务链路本身就比较重，建议显式设置一个更合理的超时时间，比如5000毫秒或10000毫秒，避免因为GC停顿或者网络瞬时拥堵导致误判为失败。

3.3 本地消息表的兜底方案：为什么哪怕有事务消息，我还是建议保留这张表

事务消息虽然好用，但它把可靠性全部押在了RocketMQ的Broker和生产者进程的配合上。如果Broker本身不可用，半消息发送就失败，本地事务也不会执行，这相当于业务链路直接降级。有些场景不能接受这种强依赖，于是本地消息表这个“老办法”依然有存在的价值。

本地消息表的思路是：在业务数据库里建一张消息表，然后在同一个本地数据库事务里同时写入业务数据和待发送消息。事务提交后，一个定时任务扫描这张表中未发送的记录，调用MQ发送，发送成功后把记录标记为已发送。这样即使MQ暂时不可用，消息也安全保存在数据库里，等MQ恢复后再补发。

为什么在有了事务消息之后我还是建议保留这个方案？因为事务消息解决的是“本地事务和发消息的一致性”问题，而本地消息表是一种与消息中间件无关的通用兜底方案。在某些场景下，比如消息内容需要支持更灵活的重发策略、需要精确控制每条消息的发送状态、需要人工对账时，本地消息表比事务消息更直观、更可控。我在项目里的实际做法是：核心链路用事务消息享受它的低延迟优势，同时保留一个简易的消息表，把失败的消息记录在那里，做定时补偿和人工排查的依据。

4. 消费端可靠：手动ACK、重试与幂等设计

4.1 重复消费是常态，不是Bug

消费端可靠的第一步是接受一个现实：重复消费一定会发生。原因有两个层面：一是消息系统本身的“至少一次投递”语义决定了消息可能重复投递；二是消费端处理成功但ACK丢失时，Broker会重新投递同一条消息。

很多人把重复消费当成Bug去修，其实是修不掉的，因为这是消息系统的特性，而不是缺陷。正确的应对方式是让消费端具备幂等性，也就是说，同一业务事件无论被处理多少次，最终的结果都一样。

我见过一个典型案例：消费端收到订单创建消息后，直接执行了INSERT操作，结果因为消费超时后Broker重新投递，数据库里出现了两条相同订单，引发了一堆对账问题。后来在订单表上加了orderId唯一约束，重复消费时捕获到DuplicateKeyException直接返回成功，问题才彻底解决。

4.2 手动ACK怎么配，为什么不建议用自动确认

SpringCloud Stream默认的消费确认模式是自动确认，也就是说只要消费方法没有抛异常，框架就会自动向Broker确认消息已经处理完毕。自动确认在大多数场景下方便，但有一个隐患：如果消费方法里执行业务逻辑后、框架自动ACK之前，应用进程崩溃了，这条消息实际上没确认，Broker会重投。这个不用太担心，因为重投后消费逻辑会再执行一次，只要业务幂等，问题不大。

真正需要注意的反而是另一种情况：业务逻辑执行成功了，但框架因为某些原因没有成功ACK，导致消息被重复投递。比如消费方法里调了一个外部接口超时，异常被吞掉了，框架认为消费失败，于是重试投递，实际上外部接口可能已经处理成功了。

在可靠性要求高的场景，我建议把确认模式设为手动。配置方式是在binding的consumer属性里设置acknowledge-mode: MANUAL，然后在消费方法里显式调用acknowledgment.acknowledge()。只有业务处理完全成功，才手动ACK；处理失败，不ACK，让消息重新投递。下面是一个模板：

java复制@StreamListener(OrderInput.INPUT)
public void onOrder(@Payload OrderDTO order,
                    @Header(AckHeaders.ACKNOWLEDGMENT_HEADER) Acknowledgment ack) {
    try {
        orderService.handleOrderCreated(order);
        ack.acknowledge();
    } catch (Exception e) {
        log.error("处理订单创建消息失败, orderId={}", order.getOrderId(), e);
        // 不ack，消息会按照重试策略重新投递
    }
}

手动ACK的核心思路是：消息处理成功是ACK的前提，而不是ACK是消息处理完成的标志。这个顺序搞反了，可靠性就无从谈起。

4.3 幂等设计三板斧：唯一键、去重表、状态机

消费端要做到真正的幂等，通常需要从三个层面配合。

第一板斧是唯一键。在业务表上建立业务唯一索引，比如orderId，重复插入时数据库会报冲突，代码里捕获冲突并视为成功。这是成本最低、最可靠的幂等方案。

第二板斧是去重表。如果业务操作的表本身不满足唯一约束的条件，比如要更新一个统计值，重复执行会导致结果不对，那么就需要一张独立的去重表。这张表的主键是业务唯一键，在处理消息时先尝试插入去重记录，插入成功说明这条消息第一次处理，继续业务逻辑；插入失败说明重复消息，直接ACK跳过。

第三板斧是状态机。适用于业务状态流转比较明确的场景。比如订单状态从“待支付”到“已支付”再到“已发货”，消费端处理前先查当前状态，如果已经处于目标状态或后续状态，就认为是重复消息，不需要再处理。这种方式不需要额外的表，但要求业务状态本身有清晰的流转路径。

实际项目里，我通常把第一板斧和第三板斧结合起来用：核心业务表建唯一约束，消息处理逻辑里先做状态判断，双保险。如果还是没有覆盖到的高频重复场景，再补充第二板斧。

5. 流式落地的完整代码：配置、生产者、事务监听器与消费者

5.1 依赖与版本选型

SpringCloud Alibaba体系下，Stream绑定RocketMQ需要引入的依赖是spring-cloud-starter-stream-rocketmq。这个依赖会同时引入SpringCloud Stream和RocketMQ相关的客户端。如果SpringCloud版本是2021.x，对应的SpringCloud Alibaba版本建议使用2021.0.x系列，比如2021.0.5.0。版本不匹配是这类项目最常见的启动失败原因，尤其是RocketMQ客户端版本和Broker端版本差距太大时，会出现各种无法解释的异常。

核心依赖如下：

xml复制<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-stream-rocketmq</artifactId>
</dependency>
<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-spring-boot-starter</artifactId>
</dependency>

在实际项目里，这两个依赖经常被重复引入，如果不注意版本管理，可能同时出现两个不同版本的RocketMQ客户端类，导致NoSuchMethodError。建议在父POM里统一通过dependencyManagement管理版本。

5.2 配置文件：bindings与rocketmq binder结合

配置文件要想清楚一件事：SpringCloud Stream的绑定配置和RocketMQ的专属配置，分别写在不同的段落里。Stream的标准配置在spring.cloud.stream.bindings下，RocketMQ的专属配置在spring.cloud.stream.rocketmq下。

yaml复制spring:
  cloud:
    stream:
      bindings:
        orderOutput:
          destination: order-topic
          content-type: application/json
        orderInput:
          destination: order-topic
          group: order-consumer-group
          consumer:
            acknowledge-mode: MANUAL
            max-attempts: 3
      rocketmq:
        binder:
          name-server: 127.0.0.1:9876
        bindings:
          orderOutput:
            producer:
              group: order-producer-group
              transactional: true

orderOutput对应生产者，orderInput对应消费者。destination都用order-topic，这就是前面说的Binding在同一个逻辑地址上的两条连接。消费者这里配置了acknowledge-mode为MANUAL，max-attempts为3，表示消费失败最多重试3次。

需要注意，producer里的group在事务消息场景下必须配置，因为Broker回查时要通过这个group找到对应的生产者客户端。Broker端的事务回查请求是定向发送的，依赖发送者group来定位。如果不配置或者配置错误，会出现半消息一直没有终态，消费者也收不到消息的情况。

5.3 生产者与事务监听器：本地事务的提交与回查

生产者侧的核心代码是事务监听器。它实现了RocketMQLocalTransactionListener接口，包含两个方法：executeLocalTransaction和checkLocalTransaction。

java复制@Component
public class OrderTransactionListener implements RocketMQLocalTransactionListener {

    @Resource
    private OrderMapper orderMapper;

    @Override
    public RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        try {
            OrderDTO order = (OrderDTO) arg;
            orderMapper.insertOrder(order);
            return RocketMQLocalTransactionState.COMMIT;
        } catch (Exception e) {
            log.error("本地事务执行失败", e);
            return RocketMQLocalTransactionState.ROLLBACK;
        }
    }

    @Override
    public RocketMQLocalTransactionState checkLocalTransaction(Message msg) {
        String orderId = (String) msg.getHeaders().get("orderId");
        OrderDTO order = orderMapper.selectByOrderId(orderId);
        if (order != null) {
            return RocketMQLocalTransactionState.COMMIT;
        }
        return RocketMQLocalTransactionState.UNKNOWN;
    }
}

executeLocalTransaction里执行真实的业务逻辑，这里以插入订单为例。如果插入失败，返回ROLLBACK，半消息会被销毁，下游不会收到任何通知。checkLocalTransaction则是回查逻辑，它依赖消息Header里的orderId，去数据库查订单是否存在。这里有一个小细节：消息发送方需要把orderId塞进消息的Header，而不是依赖消息体里的JSON字段。因为回查时从Message对象里取Header比解析Payload更可靠，也不容易因为序列化版本问题出错。

生产者的调用方式如下：

java复制@Service
public class OrderCommandService {

    @Resource
    private RocketMQTemplate rocketMQTemplate;

    public void createOrder(OrderDTO order) {
        Message<String> message = MessageBuilder.withPayload(JSON.toJSONString(order))
                .setHeader("orderId", order.getOrderId())
                .build();
        rocketMQTemplate.sendMessageInTransaction("order-topic", message, order);
    }
}

这里直接用RocketMQTemplate的sendMessageInTransaction发送事务消息。第三个参数arg会被原样传给executeLocalTransaction，所以可以直接把业务对象传过去，在事务监听器里强制转换成需要的类型，省去二次查询。

5.4 消费者：手动ACK与失败重试的示例

消费者的代码在OrderInput这个Binding上监听消息。这里以手动ACK的方式处理，确保业务处理成功才确认。

java复制@Component
public class OrderConsumer {

    @StreamListener(OrderInput.INPUT)
    public void onOrderCreated(@Payload OrderDTO order,
                               @Header(AckHeaders.ACKNOWLEDGMENT_HEADER) Acknowledgment ack) {
        try {
            // 状态机判断：订单是否已处理过
            if (orderService.isProcessed(order.getOrderId())) {
                ack.acknowledge();
                return;
            }
            // 真实业务：更新库存、发积分、发短信等
            orderService.handleCreatedOrder(order);
            ack.acknowledge();
        } catch (Exception e) {
            log.error("处理订单创建消息失败, orderId={}", order.getOrderId(), e);
            // 不ack，触发重试
        }
    }
}

手动ACK模式下，框架会在消息被ack之前一直持有这条消息的消费状态。如果处理逻辑抛异常，框架会根据max-attempts配置进行重试，重试次数耗尽后就进入死信队列，方便人工排查。这里有一个细节：被@StreamListener标记的方法如果抛出异常，框架会继续执行重试策略。所以在捕获异常时不向上抛出，而是让方法正常返回，消息会被一直算作尚未消费成功，直到达到最大重试次数。如果你在catch块里吞掉异常并且没有ack，消息会在那挂着，提醒你别把“吞异常”和“不重试”混淆，至少要保证有一个兜底的日志和告警。

6. 实际项目中踩过的坑与排查链路

6.1 半消息一直查不到记录，消费者却收到了

这个现象很诡异：通过控制台查询事务消息状态，发现半消息一直处于“未知”状态，但消费者竟然还能收到消息。第一次遇到时排查了很长时间，最后发现问题的根源在于事务监听器没有正确注册。

RocketMQTemplate的sendMessageInTransaction会从Spring容器里找RocketMQLocalTransactionListener类型的Bean，如果项目中注册了多个这样的Bean，或者监听器没有交给Spring管理，就会导致本地事务执行后提交状态丢失。此时Broker端会一直触发回查，但回查接口查不到对应的事务状态，半消息迟迟没有终态。而消费者能收到消息是因为生产者的本地事务已经提交成功了，Broker在特定条件下把半消息置为可消费，但事务状态的标记确实丢失了。

排查路径是这样的：先看Broker日志，确认半消息对应的消息ID是否进入RMQ_SYS_TRANS_HALF_TOPIC；再看RocketMQ控制台的事务消息状态；最后检查Spring容器里RocketMQLocalTransactionListener的实例数量。发现注册了两个监听器处理同一个topic，导致RocketMQTemplate不知道用哪个，引入了混乱。这个坑的教训是：一个topic的事务消息只对应一个事务监听器，多个监听器必须明确区分。

6.2 回查接口返回UNKNOWN后，消息延迟越来越严重

业务高峰期，订单服务负载很高，checkLocalTransaction里查数据库可能超时，返回了UNKNOWN。此时Broker会按照回查间隔不断重试，如果数据库持续未能恢复，消息就会一直延迟，下游的积分发放、短信通知全部被阻塞。

排查时发现，checkLocalTransaction里并没有打日志，导致完全不知道回查发生了什么。后来在回查方法里加了日志和耗时统计，发现数据库查询偶尔超过2秒，超过Broker回查间隔后就会不断触发重复回查。

优化方案分两层：第一，回查SQL要走到索引，查询条件必须命中订单表的主键或者唯一索引，避免全表扫描；第二，UNKNOWN状态不能无限返回，设置一个最大回查次数，超过后主动返回ROLLBACK或者记录告警，避免消息无限悬挂。RocketMQ的Broker端有事务消息回查次数的限制，但代码层面也要有这个意识，不能依赖Broker单方面兜底。

6.3 自动ACK导致的“假消费成功”

消费端使用默认的自动ACK时，出现过一个很有意思的现象：业务逻辑里调用第三方接口超时，代码捕获了异常并打了日志，但没有把异常抛出去。框架认为消费成功，自动ACK，消息就被标记为已消费。实际情况是第三方接口失败了，业务状态没有更新，整条链路看起来一切正常，实际数据已经不准了。

这个事情的教训有两条：第一，消费方法里尽量不要吞异常，除非你明确知道吞掉之后业务状态是对的；第二，可靠性要求高的场景，必须使用手动ACK，把“业务处理成功”和“消息确认”绑定在同一个成功路径上。

后来我把这个服务的所有消费者改成手动ACK，并且在消费方法入口加了一个幂等判断，遇到重复消息直接ACK跳过，框架逻辑才真正清晰起来。

6.4 事务消息与顺序消息：一个容易被忽略的边界

在订单创建场景中，如果订单状态变迁也走消息通知，可能存在顺序要求：创建、支付、发货必须按序处理。事务消息默认不保证顺序，因为半消息的Commit动作在Broker端可能被多个线程并发处理，消息进入业务topic的顺序和提交顺序未必一致。

RocketMQ支持顺序消息，但是顺序消息和事务消息在目前版本中不能同时使用。如果你在事务消息监听器里使用了顺序投递相关配置，会发现要么没效果，要么直接报错。这个边界一开始很容易忽略，后来测试阶段才暴露出来。

实际项目中如果确实需要“事务一致性”和“顺序性”同时满足，我的做法是：事务消息只负责创建订单这个“源头事件”，后续的支付、发货等状态变化通过普通顺序消息做流转，不再套事务语义。因为一旦订单创建这条事实已经落地，后续状态更新本身的可靠性可以通过消费端幂等和重试来兜底，没必要再用事务消息增加复杂度。

6.5 事务消息批量发送的坑

RocketMQ的事务消息不支持批量发送。你可能已经习惯了RocketMQTemplate的syncSend批量发送能力，但当切到事务消息时，只能逐条调用sendMessageInTransaction。这个限制不是Stream层的问题，而是RocketMQ底层对事务消息的实现就是一条半消息对应一个事务状态。

我刚开始优化性能时尝试在循环外把多条订单消息组合成批量发送，运行后一直报错，查了RocketMQ源码才发现事务消息的发送走的不是普通的批量发送逻辑，而是需要单独的消息队列，批量处理会丢失事务上下文。这个限制意味着事务消息的吞吐量天然低于普通消息，如果单次事务需要通知多个下游，建议让下游订阅同一个topic按类型过滤，而不是拆成多条事务消息。

7. 最后再分享一个关于事务消息的实践体会

回到最开始的那个订单积分需求。如果让我重新设计一次，在订单创建链路上，我会这样排布：订单表和积分通知消息使用本地事务表方案兜底，支付成功后的核心账户变动使用RocketMQ事务消息保证一致，普通异步通知比如短信、站内信走Stream的普通消息通道。这样分层的核心考量是：不同业务对一致性的要求不同，用一个方案套所有场景，最后要么过度设计，要么可靠性不足。

事务消息看起来很美，但它的代价是复杂度，这种复杂度体现在业务方必须实现回查接口，还必须把回查逻辑设计成可重复执行的、基于数据库事实的、不依赖内存状态的。回查接口本身就像一个隐藏的定时任务，你得保证它在任何情况下都能返回确定的结果。在我接触过的项目里，事务消息的故障多半不是发送失败，而是回查逻辑写得不对，或者配置不对，导致消息卡在中间态，下游迟迟收不到。

如果你现在正要上手Stream加RocketMQ，我的建议是先从小流量业务开始，把普通消息通道跑通，再把事务消息加到一条非核心链路上，观察回查日志和控制台上的事务状态，确认没问题后再铺开到核心链路。RocketMQ的控制台能查看事务消息的最终状态和回查次数，这个工具在故障排查时非常关键，别等到出问题才想起来看。