RocketMQ 死信队列与重试队列：问题消息处理策略与代码实践

最新推荐文章于 2025-12-19 15:39:34 发布
原创 最新推荐文章于 2025-12-19 15:39:34 发布 · 777 阅读 · 10 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#rocketmq #java

在分布式消息中间件的应用中，“消息可靠投递”是绕不开的核心诉求。然而在实际生产环境中，网络波动、消费者业务异常、资源临时不可用等问题，总会导致部分消息无法被正常消费。RocketMQ 提供的重试队列与死信队列机制，正是应对这类“问题消息”的关键解决方案。本文将从核心概念入手，深入剖析两者的工作原理、关联关系，详解问题消息的流转链路，并结合实际代码演示如何在开发中落地相关处理策略。

一、核心概念：重试队列与死信队列是什么？

在理解具体策略前，我们首先要明确两个核心队列的定义与定位——它们并非独立于 RocketMQ 核心架构的组件，而是基于主题（Topic）机制实现的特殊消息存储载体，承担着“容错”与“兜底”的核心作用。

1. 重试队列：给消息“补救”的机会

重试队列，顾名思义，是用于存储“消费失败后需要重新投递”的消息的队列。当消费者消费消息时抛出异常（如业务逻辑报错、数据库连接超时等），且未明确返回“消费成功”状态时，RocketMQ 不会直接丢弃消息，而是将其送入对应的重试队列，等待后续重新投递，从而为消息提供“补救”机会。

核心特点：

  • 主题关联性：重试队列并非全局共享，而是与消费者组（Consumer Group）强绑定，每个消费者组都有专属的重试主题，命名格式为 %RETRY%+ConsumerGroupName（如消费者组为 OrderConsumerGroup，则重试主题为 %RETRY%OrderConsumerGroup）。

  • 延迟投递机制：重试消息并非立即重新投递，而是遵循“指数退避”原则，即每次重试的间隔时间逐渐拉长，避免因瞬时故障导致消息高频重试，加剧系统压力。RocketMQ 默认提供 16 级重试延迟（可通过配置调整），对应延迟时间从 1 秒到 2 小时不等。

  • 生命周期依赖：重试队列的消息最终会流向死信队列（若多次重试仍失败），因此它是死信队列的“前置环节”。

2. 死信队列：问题消息的“最终归宿”

死信队列（Dead-Letter Queue，简称 DLQ）是用于存储“多次重试后仍消费失败”的消息的队列，这些消息被称为“死信消息”（Dead-Letter Message）。死信队列的核心作用是“兜底”——避免问题消息无限重试占用资源，同时留存消息以便后续排查问题（如业务逻辑漏洞、数据格式错误等）。

核心特点：

  • 专属主题：与重试队列类似，死信队列也与消费者组绑定，专属主题命名格式为 %DLQ%+ConsumerGroupName（如 %DLQ%OrderConsumerGroup）。

  • 持久化存储：死信消息会被持久化存储，默认保留时间与普通消息一致（可通过 Broker 配置调整），不会随消费者重启或系统故障丢失。

  • 手动处理：死信队列中的消息不会被 RocketMQ 自动投递，需要开发人员通过人工介入的方式处理（如排查问题后重新发送、修正数据后消费等）。

3. 两者的核心区别与关联

重试队列与死信队列本质上是“流转关系”而非“竞争关系”，核心区别与关联可总结为下表：

维度重试队列死信队列
存储对象消费失败待重试的消息多次重试仍失败的死信消息
处理方式RocketMQ 自动延迟重试投递人工介入处理
生命周期短暂（重试成功则删除，失败则流转至 DLQ）持久（需手动删除或处理）
关联关系死信队列的“上游”，消息重试失败后流入 DLQ重试队列的“下游”，是问题消息的最终存储载体

二、问题消息流转链路：从消费失败到死信的完整过程

理解问题消息的流转链路，是掌握重试与死信机制的关键。下面结合 RocketMQ 的消息消费流程，梳理从“消息消费失败”到“进入死信队列”的完整链路，并明确各环节的触发条件。

1. 核心流转链路

  1. 消息投递：生产者发送消息至目标主题（如 OrderTopic），Broker 将消息持久化后，推送给订阅该主题的消费者（或由消费者主动拉取）。

  2. 消费失败判定：消费者消费消息时，若出现以下情况，RocketMQ 判定为“消费失败”：
    业务逻辑抛出未捕获的异常（如 NullPointerException、自定义业务异常等）；

  3. 消费者明确返回 ConsumeConcurrentlyStatus.RECONSUME_LATER（并发消费）或 ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT（顺序消费）；

  4. 消费超时（消费者长时间未返回消费状态，超过 Broker 配置的 consumeTimeout）。

  5. 进入重试队列：消费失败后，Broker 将消息标记为“待重试”，并根据当前重试次数，确定下一次投递的延迟时间，随后将消息存入该消费者组的专属重试队列。

  6. 重试投递与循环：当延迟时间到达后，Broker 从重试队列中取出消息，重新投递给该消费者组的可用消费者。若再次消费失败，则重复“进入重试队列-延迟投递”的循环。

  7. 触发死信条件：当消息的重试次数达到 Broker 配置的最大值（默认 16 次，可通过 maxReconsumeTimes 调整）后，若仍消费失败，Broker 不再将其送入重试队列，而是直接转入该消费者组的死信队列。

  8. 死信处理：死信消息在死信队列中持久化，等待开发人员通过人工方式排查问题（如查看日志、校验消息数据），并进行后续处理（如重新发送、修正后消费）。

2. 关键配置参数

上述流转过程中，多个环节的行为由 RocketMQ 的配置参数控制，核心参数如下（开发中需根据业务场景调整）：

  • maxReconsumeTimes：消费者组允许的最大重试次数，默认 16 次，超过则进入死信队列；

  • retryDelayLevel：重试延迟级别配置，默认值为 "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h"，共 18 级，可通过 Broker 配置自定义；

  • consumeTimeout：消费超时时间，默认 15 分钟，超过则判定为消费失败并触发重试；

  • dlqTopicNum：死信队列的队列数量，默认与原主题一致，可通过 Broker 配置调整。

三、代码实践：重试与死信机制的开发落地

下面结合 RocketMQ 客户端（Java 版本，基于 RocketMQ 4.9.4），从“生产者配置”“消费者配置（含重试策略）”“死信消息处理”三个核心场景，提供完整的代码示例与配置说明。

1. 环境准备

首先需引入 RocketMQ 客户端依赖（Maven）：


<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-client</artifactId>
    <version>4.9.4</version>
</dependency>

确保 RocketMQ 服务（NameServer、Broker）已正常启动，Broker 配置中开启重试与死信机制（默认已开启，无需额外配置）。

2. 生产者实现：发送普通消息

生产者的核心作用是发送消息至目标主题，无需关注重试与死信逻辑（由 Broker 与消费者控制），代码如下：


import org.apache.rocketmq.client.exception.MQClientException;
import org.apache.rocketmq.client.producer.DefaultMQProducer;
import org.apache.rocketmq.common.message.Message;
import org.apache.rocketmq.remoting.common.RemotingHelper;

public class ProblemMessageProducer {
    // 生产者组名称
    private static final String PRODUCER_GROUP = "ProblemMessageProducerGroup";
    // NameServer 地址
    private static final String NAME_SERVER_ADDR = "127.0.0.1:9876";
    // 目标主题（普通主题）
    private static final String TARGET_TOPIC = "OrderTopic";

    public static void main(String[] args) throws Exception {
        // 1. 初始化生产者
        DefaultMQProducer producer = new DefaultMQProducer(PRODUCER_GROUP);
        producer.setNamesrvAddr(NAME_SERVER_ADDR);
        // 开启消息轨迹（可选，便于排查问题）
        producer.setSendTraceEnable(true);

        // 2. 启动生产者
        producer.start();

        // 3. 构建消息（模拟订单支付消息）
        for (int i = 0; i < 5; i++) {
            String messageBody = "OrderPayMessage: " + i + ", 模拟消费失败场景";
            Message message = new Message(
                    TARGET_TOPIC,          // 主题
                    "PayTag",              // 标签
                    "OrderId-" + i,        // 消息Key（便于定位消息）
                    messageBody.getBytes(RemotingHelper.DEFAULT_CHARSET)
            );
            // 发送消息（同步发送，确保消息可靠）
            producer.send(message);
            System.out.println("发送消息成功，消息Key：" + "OrderId-" + i);
        }

        // 4. 关闭生产者（实际生产中需在服务关闭时调用）
        producer.shutdown();
    }
}

3. 消费者实现：配置重试策略与消费逻辑

消费者是重试机制的核心载体，需通过配置明确“最大重试次数”“消费失败返回状态”等关键逻辑。下面分别演示并发消费与顺序消费两种场景的实现（死信机制无需额外配置，满足重试次数条件后自动触发）。

3.1 并发消费场景（无顺序要求）

import org.apache.rocketmq.client.consumer.DefaultMQPushConsumer;
import org.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyContext;
import org.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyStatus;
import org.apache.rocketmq.client.consumer.listener.MessageListenerConcurrently;
import org.apache.rocketmq.client.exception.MQClientException;
import org.apache.rocketmq.common.message.MessageExt;

import java.util.List;

public class ConcurrentProblemConsumer {
    // 消费者组名称（重试/死信队列与该组绑定）
    private static final String CONSUMER_GROUP = "OrderConsumerGroup";
    // NameServer 地址
    private static final String NAME_SERVER_ADDR = "127.0.0.1:9876";
    // 订阅的主题与标签
    private static final String SUBSCRIBE_EXPRESSION = "OrderTopic:PayTag";

    public static void main(String[] args) throws MQClientException {
        // 1. 初始化推送式消费者（Push模式，Broker主动推送消息）
        DefaultMQPushConsumer consumer = new DefaultMQPushConsumer(CONSUMER_GROUP);
        consumer.setNamesrvAddr(NAME_SERVER_ADDR);

        // 2. 配置重试策略（核心）
        // 最大重试次数（默认16次，此处设置为3次便于测试死信机制）
        consumer.setMaxReconsumeTimes(3);
        // 消费超时时间（默认15分钟，此处设置为10秒便于测试）
        consumer.setConsumeTimeout(10);

        // 3. 订阅主题与标签
        consumer.subscribe(TARGET_TOPIC, "PayTag");

        // 4. 注册消息监听器（核心消费逻辑）
        consumer.registerMessageListener((MessageListenerConcurrently) (msgs, context) -> {
            for (MessageExt msg : msgs) {
                try {
                    // 模拟消费逻辑（此处故意抛出异常，触发重试）
                    String messageBody = new String(msg.getBody(), "UTF-8");
                    System.out.println("接收到消息：Key=" + msg.getKeys() + ", Body=" + messageBody + ", 重试次数=" + msg.getReconsumeTimes());

                    // 模拟业务异常（如数据库连接失败）
                    if (true) {
                        throw new RuntimeException("模拟消费失败：数据库连接超时");
                    }

                    // 消费成功，返回成功状态
                    return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
                } catch (Exception e) {
                    // 消费失败，判断是否已达到最大重试次数
                    if (msg.getReconsumeTimes() >= consumer.getMaxReconsumeTimes()) {
                        System.out.println("消息已达到最大重试次数，即将进入死信队列：Key=" + msg.getKeys());
                        // 达到最大重试次数，返回成功状态（避免无限循环，Broker会自动转入死信队列）
                        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
                    }
                    // 未达到最大重试次数，返回重试状态
                    return ConsumeConcurrentlyStatus.RECONSUME_LATER;
                }
            }
            return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
        });

        // 5. 启动消费者
        consumer.start();
        System.out.println("并发消费者启动成功，等待接收消息...");
    }
}
3.2 顺序消费场景（需保证消息顺序）

顺序消费的重试逻辑与并发消费类似，但返回状态不同（需使用 ConsumeOrderlyStatus），且重试时会暂停当前队列的消费（避免顺序错乱），代码如下：


import org.apache.rocketmq.client.consumer.DefaultMQPushConsumer;
import org.apache.rocketmq.client.consumer.listener.ConsumeOrderlyContext;
import org.apache.rocketmq.client.consumer.listener.ConsumeOrderlyStatus;
import org.apache.rocketmq.client.consumer.listener.MessageListenerOrderly;
import org.apache.rocketmq.client.exception.MQClientException;
import org.apache.rocketmq.common.message.MessageExt;

import java.util.List;

public class OrderlyProblemConsumer {
    private static final String CONSUMER_GROUP = "OrderOrderlyConsumerGroup";
    private static final String NAME_SERVER_ADDR = "127.0.0.1:9876";
    private static final String TARGET_TOPIC = "OrderTopic";

    public static void main(String[] args) throws MQClientException {
        DefaultMQPushConsumer consumer = new DefaultMQPushConsumer(CONSUMER_GROUP);
        consumer.setNamesrvAddr(NAME_SERVER_ADDR);
        // 顺序消费需设置单线程消费（避免顺序错乱）
        consumer.setConsumeThreadMin(1);
        consumer.setConsumeThreadMax(1);
        // 最大重试次数
        consumer.setMaxReconsumeTimes(3);

        consumer.subscribe(TARGET_TOPIC, "PayTag");

        // 注册顺序消息监听器
        consumer.registerMessageListener((MessageListenerOrderly) (msgs, context) -> {
            // 顺序消费需锁定当前队列（避免并发导致顺序错乱）
            context.setAutoCommit(true);
            for (MessageExt msg : msgs) {
                try {
                    String body = new String(msg.getBody(), "UTF-8");
                    System.out.println("顺序消费消息：Key=" + msg.getKeys() + ", Body=" + body + ", 重试次数=" + msg.getReconsumeTimes());

                    // 模拟消费失败
                    throw new RuntimeException("顺序消费失败：业务逻辑异常");
                } catch (Exception e) {
                    e.printStackTrace();
                    // 顺序消费失败，返回暂停队列状态（触发重试）
                    return ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT;
                }
            }
            return ConsumeOrderlyStatus.SUCCESS;
        });

        consumer.start();
        System.out.println("顺序消费者启动成功，等待接收消息...");
    }
}

4. 死信消息处理：人工介入与重试

当消息进入死信队列后，需开发人员通过以下步骤处理：

  1. 定位死信队列：通过 RocketMQ 控制台（如 RocketMQ-Console），根据消费者组名称找到对应的死信主题（%DLQ%+ConsumerGroupName），查看死信消息的内容、重试次数、异常信息等。

  2. 排查问题原因：根据死信消息的内容，结合业务日志，定位消费失败的根本原因（如数据格式错误、依赖服务不可用、业务逻辑漏洞等）。

  3. 处理死信消息：修复问题后，通过代码将死信消息重新发送至原主题，或直接消费死信消息。下面提供“消费死信消息并重新发送”的代码示例：


import org.apache.rocketmq.client.consumer.DefaultMQPushConsumer;
import org.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyStatus;
import org.apache.rocketmq.client.consumer.listener.MessageListenerConcurrently;
import org.apache.rocketmq.client.exception.MQClientException;
import org.apache.rocketmq.client.producer.DefaultMQProducer;
import org.apache.rocketmq.common.message.Message;
import org.apache.rocketmq.common.message.MessageExt;
import org.apache.rocketmq.remoting.common.RemotingHelper;

import java.util.List;

public class DeadLetterMessageHandler {
    // 死信消费者组（需与原消费者组不同）
    private static final String DLQ_CONSUMER_GROUP = "DLQOrderConsumerGroup";
    // 原生产者组（用于重新发送消息）
    private static final String PRODUCER_GROUP = "ProblemMessageProducerGroup";
    private static final String NAME_SERVER_ADDR = "127.0.0.1:9876";
    // 死信主题（对应原消费者组的死信队列）
    private static final String DLQ_TOPIC = "%DLQ%OrderConsumerGroup";
    // 原目标主题（重新发送的目标）
    private static final String TARGET_TOPIC = "OrderTopic";

    public static void main(String[] args) throws MQClientException {
        // 1. 初始化死信消息消费者
        DefaultMQPushConsumer dlqConsumer = new DefaultMQPushConsumer(DLQ_CONSUMER_GROUP);
        dlqConsumer.setNamesrvAddr(NAME_SERVER_ADDR);
        // 订阅死信主题
        dlqConsumer.subscribe(DLQ_TOPIC, "*");

        // 2. 初始化生产者（用于重新发送死信消息）
        DefaultMQProducer producer = new DefaultMQProducer(PRODUCER_GROUP);
        producer.setNamesrvAddr(NAME_SERVER_ADDR);
        producer.start();

        // 3. 注册死信消息监听器
        dlqConsumer.registerMessageListener((MessageListenerConcurrently) (msgs, context) -> {
            for (MessageExt dlqMsg : msgs) {
                try {
                    // 1. 打印死信消息信息（用于排查问题）
                    String dlqBody = new String(dlqMsg.getBody(), "UTF-8");
                    System.out.println("接收到死信消息：Key=" + dlqMsg.getKeys() + ", Body=" + dlqBody + ", 原重试次数=" + dlqMsg.getReconsumeTimes());

                    // 2. 排查问题后，重新构建消息并发送至原主题
                    Message newMessage = new Message(
                            TARGET_TOPIC,
                            dlqMsg.getTags(),
                            dlqMsg.getKeys(),
                            dlqBody.getBytes(RemotingHelper.DEFAULT_CHARSET)
                    );
                    // 发送消息（同步发送，确保可靠）
                    producer.send(newMessage);
                    System.out.println("死信消息重新发送成功：Key=" + dlqMsg.getKeys());

                } catch (Exception e) {
                    e.printStackTrace();
                    // 死信消息处理失败，可记录日志后重试
                    return ConsumeConcurrentlyStatus.RECONSUME_LATER;
                }
            }
            return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
        });

        // 4. 启动死信消费者
        dlqConsumer.start();
        System.out.println("死信消息消费者启动成功，等待处理死信消息...");
    }
}

四、生产环境最佳实践与注意事项

重试与死信机制的落地并非“配置即完事”，需结合生产环境的特点，规避潜在风险，提升消息处理的可靠性。

1. 合理配置重试参数

  • 重试次数：避免设置过大（如默认 16 次），对于瞬时故障（如网络抖动），3-5 次重试已足够；对于必然失败的消息（如数据格式错误），过多重试只会浪费资源。建议根据业务场景设置（如支付类消息重试 3 次，日志类消息重试 1 次）。

  • 延迟级别：根据依赖服务的恢复能力调整，如依赖的数据库通常在几秒内可恢复，可将前几次重试延迟设置为 1s、5s、10s；若依赖的是第三方接口（可能长时间不可用），可适当拉长后续重试延迟。

2. 做好消息日志与监控

  • 日志记录：在消费者代码中，务必记录消息的 Key、重试次数、消费结果（成功/失败原因），便于后续排查死信消息的问题。

  • 监控告警：通过 RocketMQ 监控工具（如 Prometheus + Grafana、RocketMQ-Console），对“重试消息数”“死信消息数”设置阈值告警（如死信消息数超过 10 条则触发短信告警），确保问题及时被发现。

3. 死信消息的常态化处理

  • 定期排查：建立死信消息的定期排查机制（如每日下班前查看死信队列），避免死信消息堆积。

  • 自动化处理：对于部分可自动修复的死信消息（如依赖服务临时不可用），可开发自动化脚本，定时扫描死信队列，将消息重新发送至原主题；对于无法自动修复的，再人工介入。

4. 避免消息无限重试的坑

在消费者代码中，若未正确处理“达到最大重试次数”的场景，可能导致消息无限重试。核心规避点：

  • 在异常捕获逻辑中，判断 msg.getReconsumeTimes() 是否达到 maxReconsumeTimes，若达到则返回“消费成功”状态（Broker 会自动将消息转入死信队列）；

  • 避免在消费逻辑中出现“静默失败”（如捕获异常后不返回任何状态），这会导致 Broker 判定为消费超时，触发无限重试。

五、总结

RocketMQ 的重试队列与死信队列机制，构成了“问题消息”处理的完整闭环——重试队列负责“容错补救”，死信队列负责“兜底留存”。在实际开发中，我们需明确两者的核心作用与流转链路，通过合理配置重试参数、完善消费逻辑、建立死信处理机制，确保消息的可靠消费。

核心要点回顾：

  • 重试队列与消费者组绑定，采用延迟投递机制，为失败消息提供补救机会；

  • 死信队列是问题消息的最终归宿，需人工介入处理，避免资源浪费；

  • 代码开发中，需正确返回消费状态、配置重试次数，避免无限重试；

  • 生产环境中，需结合监控告警与定期排查，确保问题消息及时处理。

通过本文的理论与实践内容，希望能帮助开发者更好地掌握 RocketMQ 的问题消息处理机制，提升分布式系统的可靠性。

RocketMQ死信队列问题排查与实战解决方案
qq_35716689的博客
07-07 1047
本文深入剖析RocketMQ死信队列常见问题，从现象描述、定位流程、根因分析到实战解决与预防措施，全方位提供可运行的代码示例与生产环境优化建议，帮助后端开发者高效排查与应用死信队列。
RocketMQ 之死信队列
FireFox1997
08-03 4215
死信队列是一种特殊的消息队列，用于存储无法被正常消费的消息。这些消息在达到一定的重试次数或超时时间后，会被转移到死信队列中，供系统管理员或开发人员后续处理。通过死信队列机制，可以避免消息在消费失败时丢失，并提供了一种处理异常消息的途径。RocketMQ 的死信队列机制通过捕获无法正常消费的消息，提供了一种可靠的消息处理和错误恢复手段。在实际应用中，通过合理配置和使用死信队列，可以有效提升系统的稳定性和数据一致性。未来的开发中，充分利用死信队列机制，可以更好地应对复杂的业务需求和异常处理场景。
Apache RocketMQ消费者重试机制：死信队列与消息重投策略
gitblog_00991的博客
09-09 856
在分布式系统中，消息消费失败是常见问题。以电商订单场景为例，消费者处理支付结果通知时，可能因数据库连接超时、下游服务不可用等导致消费失败。若缺乏可靠重试机制，可能造成订单状态不一致、交易数据丢失等严重问题。RocketMQ提供的消费者重试机制，通过**分级延迟重试**与**死信队列（Dead-Letter Queue）** 组合策略，有效解决了这一痛点，确保消息至少被消费一次（At-Least-O...
RocketMQ - 消息重试与死信队列
weixin_46619605的博客
06-27 944
RocketMQ - 消息重试与死信队列
RocketMQ重试队列与死信队列以及流程原理
code_fly
08-27 1129
‌。
Apache RocketMQ死信队列监控：消息数量与告警配置
gitblog_00556的博客
09-09 663
### 1.1 死信队列定义与产生机制 死信队列（DLQ）是存储处理失败或无法正常消费消息的特殊队列。当消息满足以下条件时，会被自动投递到死信队列： - **重试次数耗尽**：消息消费失败后，达到最大重试次数（默认16次）仍未成功 - **消费被拒绝**：消费者明确返回`RECONSUME_LATER`且重试次数耗尽 - **消息过期**：超过消息最大生存时间（TTL）未被消费 Rocket...
RocketMQ 消息重试与死信消息处理方案
Takumilove的博客
07-17 1057
通过本文，我们学习了如何在 RocketMQ 中实现消息重试机制，并使用死信队列来处理无法被正常消费的消息。结合实际场景，可以根据消息的重要性和业务逻辑设计更为灵活的重试策略，以确保消息的可靠性和系统的稳定性。希望本文能够为你在分布式系统中处理消息异常提供有价值的参考！
RocketMQ中如何处理消息重试和死信队列？
qq_33240556的博客
09-23 1537
消息重试：通过返回触发自动重试，可以配置最大重试次数和重试时间间隔。死信队列：当消息重试失败后，消息会被发送到死信队列，可以配置专门的消费者来处理死信队列中的消息。通过这种方式，RocketMQ 能够有效地处理消息重试和死信队列，提高系统的可靠性和稳定性。
RocketMQ重试队列与死信队列简介
HollisChuang's Blog
11-28 2114
1、消费者异常了怎么办？假设我们使用RocketMQ作为消息中间件，传输订单相关的数据，消费者拿到数据后，执行一些后续处理，比如调用物流系统，准备发货。如果这时候，物流系统的数据库宕机了，...
RocketMQ - 死信队列处理：无法消费消息的重试与恢复
千淘万漉虽辛苦，吹尽狂沙始到金
12-11 1万+
在 RocketMQ 中，死信消息是指那些在消费者端连续多次消费失败，且已达到最大重试次数限制的消息。这类消息不会被丢弃，而是被自动转移到一个特殊的 Topic 中——即死信队列（DLQ）。📌 注意：RocketMQ 的死信队列是按消费者组（Consumer Group）隔离的，每个组拥有独立的 DLQ。可通过try {// 业务异常：1 分钟后重试（等级 3）});通过# DLQ 消息数 > 0（✅ 可访问）死信队列不是“垃圾桶”，而是 RocketMQ 为你留下的最后一道防线。
202531 | RocketMQ 消息过滤 + 消息重试机制 + 死信消息 + 重复消费问题
weixin_43422022的博客
05-05 909
概念是否必填作用举例Topic✅ 是消息的一级分类（业务主题）OrderTopicTag✅ 是Topic 下的逻辑子类（操作类型）Key❌ 可选消息的唯一标识（方便追踪）RocketMQ 提供了可靠的消息重试机制，用于保障消息在发送与消费过程中的稳定性和可靠性。生产者重试机制（Producer Retry）消费者重试机制（Consumer Retry）对比项生产者重试消费者重试重试触发条件消息发送失败消费逻辑失败默认重试次数2 次（共尝试 3 次）
RocketMQ篇二（消息重试、死信队列、死信消息、消息幂等、延迟消息、顺序消息、消息过滤、回溯消费、事务消息）
xingze的博客
07-17 7850
1. 消息重试 1.1 如何让消息进行重试 1.2 重试消息如何处理 2. 死信队列、死信消息 3. 消息去重/消息幂等（防止消息重复消费） 4. 定时消息（延迟消息） 5. 顺序消息 6. 消息过滤 7. 回溯消费 8. 事务消息
【RocketMQ】消息重试、重试次数设置、死信队列
热门推荐
m0_45406092的博客
09-28 2万+
文章目录1. 死信队列1.1 死信特性1.2 查看死信消息参考 1. 死信队列 上一篇《RocketMQ：消息重试》中我们提到当一条消息消费失败时，RocketMQ会进行一定次数的重试。重试的结果也很简单，无非就是在第N次重试时，被成功消费。或者就是经过M次重试后，仍然没有被消息。这通常是由于消费者在正常情况下无法正确地消费该消息。此时，RocketMQ不会立即将消息丢弃，而是将其发送到该消费者对应的特殊队列中去。 在RocketMQ中，这种正常情况下无法被消费的消息被称为死信消息（Dead-Lette
SpringBoot优雅的封装不同研发环境下（环境隔离）RocketMq自动ack和手动ack
qq_37557563的博客
08-12 2355
SpringBoot优雅的封装不同研发环境下（环境隔离）RocketMq自动ack和手动ack,并提供具体示例，亲测有效
车载系统应用开发集成系统API
yangyulong0622的博客
12-16 457
车载开发中，为了快速迭代常将系统应用剥离为普通应用开发，但调用系统API时反射效率低。解决方法是通过集成framework.jar，但会遇到编译报错问题。通用方案是在gradle中配置bootstrapClasspath引入jar包。当使用高版本JDK时，必须强制指定模块使用JDK8并关闭lint检查才能生效。关键步骤：先加载jar包到工程，再设置模块JDK版本为1.8。
JAVA设计模式之观察者模式
pingguocu3的博客
12-17 347
在我们开发的过程中，经常会遇到一些当什么什么事情发生的时候，然后做什么什么事。比如某种商品的物价上涨时会导致部分商家高兴，而消费者伤心。平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。著作权归作者所有,转载或内容合作请联系作者。
使用idea启动一个springboot项目
最新发布
qq_51389137的博客
12-19 1205
5.装配置maven配置到idea下载项目依赖。4.装navicat。
【FastAPI】FastAPI依赖注入完全指南
weixin_63434398的博客
12-18 2738
本文全面介绍FastAPI的依赖注入机制，主要包含两大注入方式：原生自动注入和Depends自定义注入。原生注入支持Request/Response等框架对象以及路径/查询参数等自动解析，而Depends则用于自定义依赖项注入。文章详细讲解依赖注入的核心思想、实现方式、生命周期管理、高级技巧，并通过完整认证系统案例展示实战应用。最后剖析Depends底层原理，并与Spring框架进行对比，帮助开发者彻底掌握FastAPI这一核心特性，实现代码解耦和高效开发。
任务总执行时长
y245166349的专栏
12-17 404
任务编排服务负责对任务进行组合调度。参与编排的任务有两种类型，其中一种执行时长为taskA，另一种执行时长为taskB。任务一旦开始执行不能被打断，且任务可连续执行。服务每次可以编排num个任务。请编写一个方法，生成每次编排后的任务所有可能的总执行时长。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

canjun_wen

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值