RocketMQ Producer消息发送全链路解析与实战调优

说实话，RocketMQ 的 Producer 发送消息这件事，很多人用了很久可能都只停留在“new 一个 DefaultMQProducer，然后 send 一下就完事”的层面。但只要你在生产环境里踩过一次消息丢失、超时，或者因为某个参数配错导致发送链路直接挂掉，你就会意识到：Producer 这一端的水，远比表面上深得多。这篇文章我想从源码、参数、队列路由再到线上排错，完整串一遍“RocketMQ 的 Producer 是如何发送消息的”，尽量讲透每一个关键环节背后的设计原因，而不是只贴几个能跑的 demo。

这篇文章适合谁看？如果你正在用 RocketMQ 做业务消息、事务消息，或者你的系统里消息量不小、经常要排查发送超时和消息积压问题，那我建议你耐心读完。即便你是新手，只要照着文章里的代码和步骤走一遍，也能把 Producer 从启动到发送的整个链路搞清楚。

1. 先说结论：一条消息从 Producer 出发，到底要闯多少关

很多人以为 send 就是“塞给 Broker 就完事”，其实一条消息从你的业务代码里发出，到 Broker 真正落盘、返回发送成功，中间要经历一条很长的链路。我对 RocketMQ Producer 源码研究过不少次，也调过很多线上问题，可以负责任地说：如果不理解这条链路上的每一个环节，你很难定位“消息去哪了”这类问题。

1.1 消息发送的整体链路

一条普通的消息从你的应用进程里发出去，大致要经历下面这些步骤：

1. 业务代码构建 Message 对象，指定 Topic、Tag、Keys，塞入消息体 body。
2. DefaultMQProducer 把发送请求交给底层的 MQClientInstance。
3. Producer 向 NameServer 拉取/刷新 Topic 的路由信息，拿到这个 Topic 对应的 MessageQueue 列表（一个 Topic 下有多个队列，分布在不同的 Broker 上）。
4. 根据队列选择策略（默认是轮询，也可以开启故障延迟、或者自定义队列选择器）挑出一个 MessageQueue。
5. 将要发送的消息封装成 SendMessageRequestHeader 协议头，通过 Netty 通道发送给目标 Broker。
6. Broker 接收到消息后，写入 CommitLog，然后根据配置决定是否刷盘（同步刷盘/异步刷盘），是否需要等待从节点同步完成。
7. Broker 返回 SendResult，包含 status、msgId、offsetMsgId 等信息，Producer 根据返回结果判断发送成功还是失败。

整个链路看起来不复杂，但每个环节都有“坑位”。比如第 2 步，如果 Namesrv 地址配错了、或者路由信息拿不到，你的消息连 Broker 都找不到；第 4 步如果队列选择策略不当，可能导致某个 Broker 负载特别高；第 6 步如果刷盘方式配的是异步，那 Broker 返回成功并不代表数据真的进了磁盘。

1.2 Producer 在 RocketMQ 里的角色定位

RocketMQ 的整体架构里，Producer 就是消息的“源头”。Broker 负责存储和转发，Consumer 负责消费，而 Producer 是数据进入整个 MQ 体系的第一道门。正因为它是源头，所以 Producer 端做得好不好，直接影响后续所有环节的稳定性和数据完整性。

从职责上看，Producer 要解决的核心问题有三个：第一，把业务消息可靠地送到 Broker 并且确认落盘；第二，在保证可靠性的前提下，尽量提升吞吐量，不要在发送环节拖垮业务；第三，在 Broker 异常、网络抖动的时候，有合理的重试和降级策略，不能一次性把消息全丢掉。

我见过不少团队在 Producer 端只做了最简单的同步发送，结果高峰期 Broker 抖动一下，大量消息直接抛异常，业务上也没有兜底，消息就丢了。所以搞懂 Producer 的内部机制，不只是在学 API，而是在为你自己的系统设计消息可靠性方案打基础。

2. 初始化不能马虎：ProducerGroup、Namesrv 与关键参数

先别急着写发送代码。Producer 的初始化阶段如果没做对，后面全是隐患。我见过有人直接把 NamesrvAddr 写死在代码里，后来换了集群，改了配置但没发版，结果消息全部发不出去。初始化阶段的每一个配置背后都有原因，这里一个个说。

2.1 ProducerGroup：不只是一个名字

创建 Producer 的时候，第一行代码通常是 DefaultMQProducer producer = new DefaultMQProducer("your_group")，这里的字符串就是 ProducerGroup。很多初学者以为这只是一个标识，随便取个名字就行。实际上 ProducerGroup 在 RocketMQ 里有明确的语义：它代表这一类 Producer 的集合。在事务消息里，ProducerGroup 被用来标识事务消息的归属，用于回查事务状态；在普通消息里，如果多个 Producer 实例使用同一个 group 名，它们在客户端视角是等价的。

所以命名上我建议遵循“业务域 + 场景”的规范，比如 order-service-pay-producer，这样在监控、排障、日志里看到一条消息的 group 名称，你就能立刻知道它是哪个业务、哪个场景发出来的。不要所有业务都用一个 group，否则出了问题排查范围会非常大。

2.2 寻址机制：Producer 是怎么找到 Broker 的

Producer 本身不知道 Broker 的地址，它只跟 NameServer 通信。NameServer 是 RocketMQ 的“注册中心”，维护着所有 Broker 的路由信息。Producer 启动后会定期从 NameServer 拉取 Topic 路由，并且把路由信息缓存在本地内存里。

这里有个关键点：NameServer 不是强一致性的元数据中心，它是 AP 模型的。Broker 启动或变更后会向所有 NameServer 注册心跳，但 Producer 拉取到的路由信息可能不是最新的，这时候可能出现“某个 Broker 已经挂了，但本地缓存里还有它的队列”的情况。好在客户端有对应的容错机制，比如发送失败后重试其他 Broker、或者开启故障延迟策略，后面我详细讲。

实际开发中，NamesrvAddr 建议配置多个地址，用分号分隔，比如 192.168.1.10:9876;192.168.1.11:9876。这样单个 NameServer 挂了，客户端还能从其他节点获取路由。另外，从 RocketMQ 4.x 后期版本开始，可以通过 producer.setNamesrvAddr() 或者环境变量 NAMESRV_ADDR 来指定，优先级是代码配置高于环境变量。

2.3 容易被忽略的关键参数

初始化 Producer 的时候，有一堆参数可以调。我遇到过不少人在生产环境只设置了 setNamesrvAddr，其他参数全部用默认值，结果遇到大消息、高并发、Broker 抖动时才发现默认值不够用。下面这几个参数是你在上线前必须过一遍的：

我记得有一次线上排查，业务方发 2MB 的消息，一直报 The message body size over max value，排查半天才发现 maxMessageSize 还是默认值 4MB。这里要注意，4MB 是“所有属性和 body 加在一起的限制”，不是单指 body。消息里如果塞了很多 user properties，也要算在内的。

初始化还有一个很容易被忽略的点：Producer 是重资源对象，一个进程里应该复用同一个实例，不要每条消息都 new 一个 Producer，频繁创建和销毁会不断建立 Netty 连接和拉取路由，非常影响性能。我见过一个项目，在循环里 new Producer 然后 start，结果把 Broker 的连接数打满了，最后只能重启，这个坑必须避开。

3. 消息构建与三种发送方式：选对姿势很重要

初始化做好之后，进入真正发消息的环节。RocketMQ 提供了三种发送方式：同步发送、异步发送、单向发送。三种方式的可靠性、延迟、吞吐量各不相同，选哪个不是拍脑袋，而是要结合业务场景来定。

3.1 Message 对象的核心组成

在写发送代码之前，先看 Message 这个对象。一个完整的 Message 有四个最关键的属性：topic（消息主题）、tags（标签）、keys（业务唯一键）、body（消息体）。这四个属性各有用途：

• topic 决定了这条消息发到哪一类队列里，消费端也必须订阅同一个 topic 才能消费到。
• tags 相当于二级分类。同一个 topic 下可以按 tag 细分，消费端可以通过 tag 做过滤。比如订单 topic 下面有 create、pay、cancel 等 tag，消费者可以选择只订阅 pay。
• keys 是用来检索消息的，一般放业务唯一 ID，比如订单号。线上排查消息的时候，可以通过 keys 在控制台快速查找到消息轨迹。
• body 是真正的业务数据，一般放 JSON 字符串或者字节数组。

我在实际开发中看到的常见错误是把大量信息塞进 user properties，keys 只写了个固定的字符串，结果消息丢了想按业务维度排查，发现所有消息的 keys 都一样，根本没法定位。建议 keys 用 orderId 这类业务唯一的字段，并且一个 keys 字段里可以用空格分隔多个关键字。

设置 message.setDelayTimeLevel() 可以指定延迟级别，但要注意：这是“延迟级别”，不是“具体的秒数”。RocketMQ 预先定义好了 18 个延迟等级，从 1s 到 2h。如果你需要更灵活的重试延迟，建议在业务侧自己实现，而不是硬套这个字段。

3.2 同步发送：最直接的可靠性保障

同步发送是最简单也最可靠的方式。调用 producer.send(msg) 后，客户端会阻塞等待 Broker 返回结果，返回 SendStatus.SEND_OK 才代表发送成功。下面是标准代码：

java复制DefaultMQProducer producer = new DefaultMQProducer("order-producer");
producer.setNamesrvAddr("192.168.1.10:9876;192.168.1.11:9876");
producer.setRetryTimesWhenSendFailed(2);
producer.setSendMsgTimeout(5000);
producer.start();

Message msg = new Message(
    "order_topic",
    "pay",
    "order_2025010101",
    "hello rocketmq".getBytes(StandardCharsets.UTF_8)
);
SendResult sendResult = producer.send(msg);
if (sendResult.getSendStatus() == SendStatus.SEND_OK) {
    log.info("消息发送成功, msgId={}, offsetMsgId={}",
        sendResult.getMsgId(), sendResult.getOffsetMsgId());
} else {
    // 这里要记日志、入库或者做补偿
}
producer.shutdown();

注意看返回值里的 msgId 和 offsetMsgId，这两个不要混淆。msgId 是客户端生成的消息全局唯一 ID，在客户端就生成了，在控制台查消息轨迹时主要用这个；offsetMsgId 是 Broker 存储消息后返回的物理偏移 ID，包含 Broker 地址和物理偏移量，通常用来直接定位到 CommitLog 的具体位置。两个 ID 对排查问题都很有用，建议日志里都打出来。

如果业务要求消息不能丢，同步发送 + 失败之后把消息落库或者写到本地文件，然后定时补偿重发，是目前最稳的组合拳。因为 RocketMQ 的重试是在内存里的，一旦进程重启，重试的消息就没了。所以“半路拦截 + 持久化 + 定时补偿”是同步发送的兜底方案。

3.3 异步发送：性能与可靠性的平衡点

同步发送有一个明显问题：阻塞等待 Broker 返回，吞吐量上不去。如果单条消息发送耗时 5ms，你端着同步不放，一秒钟最多也就能发 200 条左右（单线程情况下）。对于高并发场景，我们需要异步发送。

异步发送的代码是这样的：

java复制producer.send(msg, new SendCallback() {
    @Override
    public void onSuccess(SendResult sendResult) {
        // 发送成功的回调
        log.info("异步发送成功, msgId={}", sendResult.getMsgId());
    }

    @Override
    public void onException(Throwable e) {
        // 发送异常的回调
        log.error("异步发送失败", e);
        // 这里必须自己做补偿，因为默认异步不重试
    }
});

注意一个关键的坑：retryTimesWhenSendAsyncFailed 默认值是 0，也就是说异步发送失败后，RocketMQ 不会自动重试。所以你在 onException 回调里必须自己处理，常见的做法是记录日志之后把消息丢进本地一张“失败消息表”，由定时任务扫描重发，或者直接发到另一个降级 topic，让专门的重试消费者去处理。

异步发送适合对耗时敏感、但消息不能随意丢弃的场景。比如用户下单成功后，需要同时给积分服务、通知服务发消息，这时候用同步发送逐个等待会加长下单接口的响应时间，用异步回调能明显降低接口 RT。但代价是业务代码变复杂，必须处理好回调里的补偿逻辑。

3.4 单向发送：极致性能，用好场景很关键

单向发送（one-way）是三种方式里性能最高的一种，但可靠性也最低。它只负责把消息发出去，不等待 Broker 返回任何结果，也不注册回调。调用 producer.sendOneway(msg) 之后，客户端把请求交给 Netty 就返回了，至于消息到底有没有到 Broker，完全没有反馈。

什么时候用单向发送？我自己的标准是：允许少量丢失、但对性能要求极其苛刻的场景。比如你只是上报一条操作日志，丢了一两条不影响业务正确性；再比如一个实时统计的计数器，偶尔丢一个数字不影响整体趋势。如果你的业务是“用户下单必须发消息成功才能继续”，那肯定不能用单向发送，否则订单消息丢了，整个订单流程就断了。

三种方式我整理了一个对比：

选型的时候记住一句话：可靠性要求越高，发送耗时越长，吞吐量越低。没有“又快又稳还不用管失败”的免费午餐，必须在业务设计时就定好取舍。

4. 路由与队列选择：消息进了哪个队列，谁说了算

很多人在 Producer 端写的代码就 5 行，觉得消息选队列是 RocketMQ 内部的事。但当你的 Topic 有 16 个队列分布在 4 个 Broker 上，某天下游某个消费实例挂了，你会发现队列路由这个看似底层的东西，直接影响你的消息会不会积压、会不会乱序。这一节把路由和队列选择的机制讲清楚。

4.1 Topic 与 MessageQueue 的映射关系

RocketMQ 里的一个 Topic 会有多个 MessageQueue，分布在不同的 Broker 上。这些队列是存储层面的逻辑概念，每个 MessageQueue 对应一个物理文件目录，Broker 会为每个队列维护消费位点（ConsumerOffset）。

具体来说，你在创建 Topic 时可以指定读写队列数量。比如某个 Topic 设置了 writeQueueNums=16，那么这 16 个队列会尽量均匀地分布在集群的各个 Broker 上（取决于你手动指定的队列分布方式）。Producer 每次发送消息时，要先拿到这个 Topic 的路由数据，也就是一张“队列列表”，然后从里面挑一个目标队列。

这里有一个容易忽略的细节：writeQueueNums 和 readQueueNums 是可以分开设置的。如果你在管理端只把读队列数调大了，写队列数没动，那么 Producer 能写入的队列数还是原来的值；反之如果写多读少，可能出现部分队列写入极快但消费端根本读不到的情况。扩topic队列的时候必须读写一起评估，别只改一边。

4.2 默认的轮询策略与故障延迟策略

默认情况下，Producer 从队列列表中选择队列时，使用的是 SelectMessageQueueByHash 或者轮询的逻辑，具体取决于你是否提供了自定义的 MessageQueueSelector。

如果走默认发送（不带 selector），RocketMQ 内部使用的是一个“递增取模”的轮询策略：每次发送，客户端内部维护的发送序号加一，然后对队列数量取模，得到本次要发送的队列 index。这样可以把消息均匀地打散到所有队列，避免一个队列被热点打满。

但如果某个 Broker 出问题，默认的轮询策略还是会把消息往那个 Broker 的队列上轮询，直到发送超时或失败才换下一个。这在 Broker 故障的瞬间会造成明显的发送耗时抖动。要解决这个问题，可以开启 producer.setSendLatencyFaultEnable(true)。

开启这个开关之后，客户端会启动一套“故障延迟”机制：当发送消息到某个 Broker 出现延迟或者失败时，客户端会在本地记录该 Broker 的“故障延迟时间”，在一段时间内尽量不把消息路由到这个 Broker 上，等故障恢复窗口过去之后再逐渐恢复。这类似于网关里的熔断降级逻辑。对于 Broker 数量较多、且有单点故障风险的集群，这个开关建议打开。注意它只对默认的轮询策略生效，如果你自己实现了 MessageQueueSelector，故障延迟逻辑不会介入。

4.3 顺序消息的队列选择

顺序消息是 RocketMQ 一个很重要的能力，它的核心约束是“同一个业务 Id 的消息必须进同一个队列”，否则消费端无法保证按发送顺序消费。默认的轮询策略做不到这一点，所以需要自定义 MessageQueueSelector：

java复制SendResult sendResult = producer.send(msg, new MessageQueueSelector() {
    @Override
    public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
        // arg 是传入的业务 ID，比如订单号
        String orderId = (String) arg;
        int index = Math.abs(orderId.hashCode()) % mqs.size();
        return mqs.get(index);
    }
}, orderId);

这里的核心思路就是：对业务唯一 ID 做 hash，然后对队列数量取模，保证同一个订单号的消息永远被选到同一个队列。注意这里用的 mqs.size() 是当前拿到的队列总数，如果你动态扩容了队列，同一个订单号的消息可能被 hash 到新队列，顺序就被打破了。所以顺序消息的队列数量，最好在 Topic 创建时就确定下来，轻易不要动。

还有一个常见的坑：你写队列时用了自定义 selector，但如果消息重试的时候，重试请求也会重新走 selector。如果重试时你传入的 arg 不对，或者队列列表变化了，顺序一样保不住。所以重试场景下，最好在业务层就做好补偿，而不是依赖重发把消息发到“原本的队列”。

5. 失败重试与可靠性保障：网络不可靠，代码要可靠

网络这个东西，在分布式环境下永远不可靠。消息发送要么超时，要么 Broker 返回异常，要么路由信息过期。所以 RocketMQ 的 send 方法内部内置了重试机制，但很多人的理解有偏差。这一节把重试机制、ACK 机制和可靠性相关的设计讲透。

5.1 同步发送的重试机制

同步发送默认重试 2 次，也就是总共会尝试 3 次。这里的“重试”并不是对同一个队列傻傻地重发，而是“换一个队列”甚至“换一个 Broker”重发，具体看队列选择和故障延迟逻辑。重试之间的间隔不固定，由底层的 MQFaultStrategy 控制。

重试几次合适？这要看你的下游消费逻辑有没有做幂等。如果消息会重复投递（消费端一定要有幂等设计），那重试次数可以适当多一些；反之，如果业务上完全接受不了重复，那么重试次数可以设置为 0，靠业务侧持久化 + 定时补偿来保证。另外，重试会占用发送线程时间，sendMsgTimeout 是一个总超时，不是单次超时。如果设置 3s，重试 2 次，那整体可能最多花 3s 就返回，而不是 3 次各 3s。

5.2 异步发送的重试机制

前面提过，异步发送默认 retryTimesWhenSendAsyncFailed=0，也就是不重试。这个设计其实很合理：异步本身就是为了低延迟，如果 Broker 已经开始出问题，回调里的重试往往会继续失败，反而占用系统资源。推荐的做法是在回调里做一次“快速判断”：

• 如果失败原因很明确，比如路由不存在、消息过大，这类是不可重试的，应该马上记录异常并进入补偿流程。
• 如果是超时、网络抖动、Broker 返回系统繁忙这类临时错误，可以自己实现一个小的重试计数器，重试 1-2 次，再不行才进入补偿流程。

但注意，回调里再调 send 是线程安全的吗？是的，DefaultMQProducer 是线程安全的，可以在回调里继续调用 send。不过要控制重试频率，避免回调里疯狂发同一批消息把 Broker 打挂。

5.3 ACK 机制与 flush 策略

RocketMQ 的 Broker 返回“发送成功”，到底代表什么？这取决于消息写到 CommitLog 之后的刷盘方式：

• 如果是同步刷盘（SYNC_FLUSH），Broker 会把消息真正写入磁盘后才返回 ACK，消息基本不会因为机器断电丢失。
• 如果是异步刷盘（ASYNC_FLUSH），Broker 先把消息写入 PageCache，然后立即返回 ACK，后台线程再定期把 PageCache 刷到磁盘。这种情况下，如果机器断电或者操作系统崩溃，最近一小段已经写入 PageCache 但还没刷盘的日志可能丢失。

特别要留意的是“主从同步”对 ACK 的影响。RocketMQ 支持在 Broker 侧配置 brokerRole=SYNC_MASTER，此时需要等消息同步到从节点后，Broker 才给 Producer 返回成功；如果配置的是 ASYNC_MASTER，则主节点写完本地日志就返回了，从节点异步复制，主库一旦宕机且数据还没同步过去，这部分消息就丢了。

所以在极端可靠性场景下，Producer 侧只是第一道关口，你还需要跟 Broker 团队确认刷盘方式和主从模式。我见过一个团队用了 RocketMQ 做资金流水记录，Broker 配的是异步刷盘 + 异步复制，结果一次断电丢失了几分钟的流水，最后通过业务侧对账才补回来。对于资金类业务，这个配置一定要谨慎。

6. 实操踩坑与调优实录

最后这部分，把我实际遇到的高频问题和新手最容易踩的坑做一个集中记录。你会发现很多问题不是 RocketMQ 本身有 bug，而是对它的机制理解不到位。

6.1 cluster authorization failed 排查

这个错误应该是 RocketMQ 新手问得最多的问题之一，也是容易让人一头雾水的启动报错。第一次看到 cluster authorization failed 的人往往会以为集群权限出问题了，但它在 90% 的情况下都跟权限没有直接关系。字符串本身的含义是“集群鉴权失败”，可以分三种情况来排查：

• 第一种，Broker 确实开启了 ACL 功能（aclEnable=true），但你的 Producer 没有配置 AclClientRPCHook。这时候客户端发出的请求没有携带 accessKey 和 secretKey，Broker 校验不过，直接拒绝。解决办法是在启动 Producer 的时候加上对应的权限 Hook。
• 第二种，Broker 开启了 ACL，但客户端配置的 accessKey 和 secretKey 对应的权限不足，比如没有该 Topic 的写权限。这时候要去 ACL 配置文件中确认权限矩阵。
• 第三种，网络环境的坑。客户端通过 VIP 或者负载均衡器访问 Broker 时，Broker 看到的 channel 对端 IP 是代理 IP 而不是真实客户端 IP，而 ACL 配置里可能只允许了真实 IP。排查时可以先关闭 ACL 做一次连通性测试，再逐步打开 ACL 定位具体拦截点。

我的习惯是在新环境上线前，先关闭 ACL 验证基础链路，确认消息能正常收发后再开启 ACL，避免第一步就被权限挡在门外，分不清是权限问题还是路由问题。

6.2 发送超时与消息积压

发送超时是生产环境最常见的问题。如果 sendMsgTimeout 默认 3s，但你发现经常出现 SendException 或者超时，不要急着把超时时间调大，而是先看超时的原因：

• 如果是目标 Broker 所在机器 CPU 飙高、磁盘写不进去，调大超时时间只能让请求更长时间地阻塞在客户端线程里，线程池可能被打满。
• 如果是网络抖动，调大超时时间有效果，但更好的是开启 sendLatencyFaultEnable=true，让客户端自动避开那些响应慢的 Broker。
• 如果是路由信息里已经没有可用的队列（比如 Topic 写队列数为 0，或者所有 Broker 都不可用），那调超时没用，得先恢复 Broker 或检查 Topic 配置。
• 如果单条消息体特别大（接近 4MB），发送耗时也会明显上升，大消息建议走专门的“大消息通道”，或者拆包发送。

消息积压问题往往也和 Producer 发送模式强相关。比如你用同步发送且单条耗时高，吞吐量上不去，消费端再快下游也是空的。这时候要考虑改异步发送、开启批量发送、或者优化单条消息大小。

6.3 参数调优建议

最后给一个我自己在生产环境验证过的参数组合，作为起步参考。不同业务的网络环境、Broker 配置、消息大小都不一样，不要盲目照搬，但可以作为一个起点：

批量发送也是一个值得尝试的优化点。RocketMQ 的 producer.send(Collection<Message> msgs) 支持一次发送一批消息，但有几个条件：这批消息必须属于同一个 topic、必须都没有设置延迟级别、必须都设置了相同的 waitStoreMsgOK，而且总大小不能超过 maxMessageSize。我自己常用的方式是攒够 100 条或者 1MB 再批量发送，吞吐量能提升不少，但要注意这批消息的数量和总体积一个都不能超，否则直接抛异常。

还有一个很多老手都会逛一圈的细节：客户端日志和监控。RocketMQ 的客户端自己会输出发送耗时等关键指标，默认的 logback 配置里会有 RocketmqClient 的 logger。我建议在监控系统里至少盯三个指标：发送成功率、发送平均耗时、待发送队列积压量。这仨一旦有异常，基本就能第一时间发现问题。

最后分享一个我踩过的小坑

文章写到最后，分享一次让我印象深刻的线上事故。那时我们的支付回调通知用的就是 RocketMQ 同步发送，某天大促流量上来，Broker 所在的磁盘快满了，CommitLog 写入变慢，大量消息发送超时。因为我们把 retryTimesWhenSendFailed 调到了 4，重试次数多，每条消息在 Producer 线程里阻塞的时间更长，最终 Producer 的发送线程池被打满，整个支付系统的响应时间都受到了影响。

后来我们做了一个很关键的调整：把“发送结果强依赖 Broker 返回”变成了“发送 + 落库补偿”双保险。Producer 发送消息之前，先把消息写入本地的 outbox 表，发送成功之后标记为完成；如果发送失败或者超时，就由定时任务扫描 outbox 表做补偿重发。这个改动之后，我们再也没因为 Broker 抖动导致业务消息彻底丢失，同时 Producer 的发送耗时也不再是业务接口的关键路径。

所以我在实际使用中的体会是：RocketMQ 的 Producer 本身已经做了很多事，但真正决定消息可靠性的，往往是你围绕 Producer 设计的那一层“业务兜底”。把发送链路看成端到端的数据通道，而不是一句 API 调用，这样你才有底气去应对生产环境的各种意外。