RocketMQ怎么保证消息不丢失详解

原创于 2025-12-20 14:28:34 发布 · 652 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#java-rocketmq #rocketmq #java

RocketMQ 专栏收录该内容

4 篇文章

订阅专栏

RocketMQ 怎么保证消息不丢失：端到端详细做法（生产者→Broker→消费者）

结论先讲清楚：RocketMQ 天然提供的是 “至少一次（At-least-once）” 投递语义：不丢的代价通常是 可能重复。
所以“消息不丢失”= 端到端链路都做到可确认、可恢复、可重试，并在业务侧做 幂等/去重。

0. 先把“丢消息”拆开看：到底可能丢在哪？

一条消息从发送到被业务真正“生效”，大概经过 3 段：

生产者发送阶段：消息还没可靠到达 Broker（网络抖动、超时、客户端崩溃）
Broker 存储阶段：消息到了 Broker 但没落盘/没复制完成（异步刷盘、异步复制、机器掉电）
消费者处理阶段：消息被拉到了消费者，但业务没处理成功或 offset 提交不当（消费成功标记丢、异常没重试）

要做到“不丢”，每段都要有对应的“确认点（ack）”和“恢复手段”。

1. 生产者侧：保证“发出去一定可追踪、可重试、可补偿”

1.1 禁用 OneWay（单向）发送

sendOneway 没有任何发送结果，只适合日志/监控这种“丢了也无所谓”的场景。
需要可靠性：用 同步 send 或 异步 send + 回调确认。

1.2 同步发送：以 sendResult 为准，失败就重试/落库补偿

同步发送示例（最常用、最稳）：

DefaultMQProducer producer = new DefaultMQProducer("pg_order");
producer.setNamesrvAddr("127.0.0.1:9876");

// 发送超时，建议结合网络情况调整
producer.setSendMsgTimeout(3000);

// 同步失败重试次数（注意：重试可能导致重复，需要幂等）
producer.setRetryTimesWhenSendFailed(3);

// 异步发送失败重试次数（若你使用 async）
producer.setRetryTimesWhenSendAsyncFailed(3);

producer.start();

Message msg = new Message(
        "TOPIC_ORDER",
        "CREATE",
        ("orderId=1001").getBytes()
);

// 建议设置业务唯一键：用于追踪/去重
msg.setKeys("ORDER_1001");

SendResult result = producer.send(msg);
if (result.getSendStatus() != SendStatus.SEND_OK) {
    // 这里不要“吞掉”，必须进入补偿链路
    throw new RuntimeException("send failed: " + result);
}

producer.shutdown();

关键点：

必须检查 SendResult 和 SendStatus，别只 try-catch。
失败不能只打日志：至少要进入重试/补偿（见 1.4）。

1.3 异步发送：回调必须处理失败分支

异步发送的坑：很多人只写成功回调，失败回调里“打印一下就算了”——这就是丢消息。

producer.send(msg, new SendCallback() {
    @Override
    public void onSuccess(SendResult sendResult) {
        // OK
    }

    @Override
    public void onException(Throwable e) {
        // 必须做补偿：重试/落库/报警
    }
});

1.4 本地消息表/Outbox：最硬的“不丢”方案（强烈推荐）

如果你要做到“服务宕机/重启也不丢”，只靠 client 重试不够。推荐经典 Outbox（本地消息表）：

流程：

在业务 DB 事务里：写业务数据 + 写一条“待发送消息”（消息表状态=NEW）
事务提交后：后台任务扫描 NEW 状态消息，发送到 MQ
发送成功：更新消息表状态=SUCCESS；失败：记录失败次数，继续重试 + 告警
下游消费：用 msgKey/业务单号做幂等

优点：

生产者宕机也不会丢（因为消息在 DB 里）
能做可视化、补发、审计

示意表结构：

CREATE TABLE t_outbox_msg (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  biz_key VARCHAR(64) NOT NULL,         -- 如 orderId
  topic VARCHAR(64) NOT NULL,
  tag VARCHAR(64),
  body TEXT NOT NULL,
  status TINYINT NOT NULL,              -- 0 NEW / 1 SUCCESS / 2 FAIL
  retry_count INT NOT NULL DEFAULT 0,
  next_retry_time DATETIME,
  create_time DATETIME NOT NULL,
  update_time DATETIME NOT NULL,
  UNIQUE KEY uk_biz_key (biz_key)
);

这套方案本质上：把“是否发出去”变成一件 可恢复的状态机，而不是“希望 MQ 不出错”。

1.5 事务消息：适合“跨系统一致性”

RocketMQ 有事务消息（半消息 + 本地事务 + 回查），适合：

你需要“业务提交了就一定最终发出消息”
且允许“最终一致”

但是事务消息并不是万能银弹：你仍然要处理 回查、幂等、补偿。

2. Broker 侧：保证“收到就持久化、并且最好复制到至少 1 台机器”

Broker 侧的核心是两件事：

刷盘策略（落盘）
主从复制策略（高可用）

2.1 刷盘：ASYNC_FLUSH vs SYNC_FLUSH

ASYNC_FLUSH（异步刷盘）：性能高，但机器突然掉电可能丢“尚未刷到磁盘”的数据
SYNC_FLUSH（同步刷盘）：Broker 收到消息后，刷盘完成才返回成功给生产者，可靠性更高，但吞吐更低

在追求“不丢”的场景（支付、订单状态等），建议优先 SYNC_FLUSH。

broker.conf 示例：

# 同步刷盘：更可靠（推荐关键链路）
flushDiskType=SYNC_FLUSH

2.2 主从复制：ASYNC_MASTER vs SYNC_MASTER

异步复制：Master 返回成功时，Slave 可能还没复制到，Master 宕机会丢
同步复制（SYNC_MASTER）：Master 必须等 Slave 复制完成才返回成功（更可靠，性能降低）

broker.conf 示例：

# 同步复制：更可靠（推荐关键链路）
brokerRole=SYNC_MASTER

实战建议：关键 Topic 用“同步刷盘 + 同步复制”，非关键 Topic 用异步提升性能。

2.3 多副本/一致性：DLedger（可选但很强）

如果你需要更强的高可用（类似 Raft 多副本），可以考虑 RocketMQ 的 DLedger（基于 Raft 的 CommitLog 复制）。
优点：

不是传统主从“单 Slave”，可以 N 副本
Leader 挂了可自动选主

代价：

运维复杂度更高
性能略受影响（但换来更强可靠性）

2.4 磁盘“写满”也是一种“隐形丢消息”

Broker 磁盘使用率到阈值后，可能拒绝写入或进入保护模式。要做：

监控磁盘使用率、CommitLog 目录
合理设置保留策略与告警阈值

3. 消费者侧：保证“处理成功才 ACK，失败能重试，最终能落到 DLQ”

3.1 正确 ACK：处理成功才返回 CONSUME_SUCCESS

Push 模式下（MessageListenerConcurrently）：

consumer.registerMessageListener((MessageListenerConcurrently) (msgs, ctx) -> {
    for (MessageExt msg : msgs) {
        try {
            // 1) 业务处理（落库/调用下游）
            handle(msg);

            // 2) 幂等（强烈建议）：比如用 msg.getKeys()/业务单号做去重
        } catch (Exception e) {
            // 返回稍后重试：RocketMQ 会重新投递
            return ConsumeConcurrentlyStatus.RECONSUME_LATER;
        }
    }
    return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
});