RabbitMQ: 消息过期机制与死信队列技术解析

RabbitMQ死信队列应用 目录 1、什么是死信队列 2、死信队列应用场景 3、延迟消息概念 3.1 消息的TTL(Time To Live) 3.2 死信交换器 3.3 延时队列 4、死信队列使用流程图 5、死信队列应用(管理控制台) 6、死信队列应用(Java代码) 6.1 RabbitMQ原生API 6.2 SpringBoot集成RabbitMQ 1、什么是死信队列 DLX, Dead-Letter-Exchange。利用DLX, 当消息在一个队列中因为业务队列处理失败(比如抛异常并且达到了re. 阅读详情

消息过期机制详解


核心概念:TTL(Time-To-Live)
TTL 是消息或队列的生存时间阈值,用于防止消息无限堆积导致 RabbitMQ 资源耗尽(如内存/磁盘溢出)。若不启用 TTL,消息默认永久存储,极端场景下可能引发服务崩溃与业务中断。TTL 分为两类:

  1. 消息级 TTL
    • 为单条消息设置独立过期时间(单位:毫秒)。
    • 通过 expiration 属性实现,需在生产者发送消息时显式配置。
  2. 队列级 TTL
    • 为队列统一设置消息过期时间,作用于队列内所有消息。
    • 通过队列参数 x-message-ttl 实现,需声明队列时配置。

关键注意事项:

  • x-expires ≠ x-message-ttl:
    • x-expires 控制队列空闲销毁时间(例如 15 秒无消息则删除队列),慎用以避免路由失效。
    • x-message-ttl 控制队列内消息的过期时间,需明确区分。
  • TTL 设置原则:
  • 应长于服务最长重启时间(避免服务重启期间消息丢失)。
  • 需覆盖业务高峰期(例如外卖系统设为 2–3 小时,秒杀系统设为 20–30 分钟)。
  • 不推荐单独使用 TTL:直接丢弃消息会导致运维追溯困难,需结合死信队列保留异常消息

死信队列全面解析


死信队列(Dead Letter Queue, DLQ) 并非特殊队列,而是配置了 x-dead-letter-exchange 属性的普通队列,用于收集异常消息(死信)。

死信的触发条件:

  1. 消息被拒绝且不重回队列(NACK/Reject + requeue=false)。
  2. 消息 TTL 过期。
  3. 队列达到最大长度(通过 x-max-length 参数限制)。

死信处理流程:

  1. 生产者发送消息至交换机(Exchange),路由至目标队列。
  2. 若消息在目标队列中触发上述条件,成为死信。
  3. 死信自动转发至 x-dead-letter-exchange 指定的交换机(DLX)。
  4. DLX 将死信路由至绑定的死信队列(DLQ),供后续处理或人工审查。

核心价值:避免异常消息直接丢弃,保留问题排查线索,提升系统可观测性。

核心问题诊断与优化方向


  1. 手动连接管理低效
    原始方案需显式创建ConnectionFactory→Connection→Channel,虽可通过容器托管Channel简化,但仍有优化空间。NestJS推荐方案:使用@golevelup/nestjs-rabbitmq模块自动化连接管理,消除手动创建代码。

  2. 消息监听机制笨重
    需自定义线程池启动监听线程,代码侵入性强。优化方案:通过装饰器声明消费者方法,由框架自动启动监听。

  3. 回调函数显式耦合
    basicConsume需硬编码回调函数,降低可读性。解决方案:注解式消息处理器实现解耦。

  4. 资源声明冗余
    每个服务重复编写queueDeclare/exchangeDeclare声明代码。优化方案:声明式资源配置。

RabbitMQ六大高级特性深度总结


1 ) 消息可靠性保障机制

  1. 生产者确认模式(Publisher Confirms)

    • 单条阻塞确认(waitForConfirms)
    • 批量阻塞确认(waitForConfirmsOrDie)
    • 推荐方案:异步回调确认(addConfirmListener)
    // NestJS实现异步确认 
    import { RabbitRPC } from '@golevelup/nestjs-rabbitmq';
    
    @Controller()
    class ProducerController {
      @RabbitRPC({
        exchange: 'confirm_exchange',
        routingKey: 'confirm.route',
        queue: 'confirm_queue'
      })
      async handleConfirm(channel: Channel) {
        channel.on('return', (msg) => { 
          console.error(`Message returned: ${msg.content.toString()}`);
        });
        channel.publish('exchange', 'route', Buffer.from('msg'), { 
          mandatory: true 
        });
      }
    }
    
  2. Return消息机制
    路由失败时异步返回消息,注意:需关联deliveryTag处理多线程上下文丢失问题。

2 ) 消费端核心控制

  1. ACK/NACK机制

    • 自动ACK:消息即时标记消费(易丢失)
    • 手动ACK:业务完成后显式确认
    • 关键实践:NACK+死信队列替代消息重入(避免循环阻塞)
  2. QoS限流控制

    // NestJS设置QoS 
    @RabbitSubscribe({
      exchange: 'qos_exchange',
      routingKey: 'qos.route',
      queue: 'qos_queue',
      channel: 'channelId',
      queueOptions: { 
        prefetchCount: 10 // 每次分发10条消息 
      }
    })
    

消息生命周期管理


  1. TTL(Time-To-Live)机制

    # RabbitMQ命令声明TTL队列 
    rabbitmqadmin declare queue name=ttl_queue arguments='{"x-message-ttl":60000}'
    
  2. 死信队列(DLX)

    死信触发条件管控台参数配置
    消息TTL过期x-dead-letter-exchange
    消费者NACK且不重入队列x-dead-letter-routing-key
    队列达到最大长度x-max-length

工程示例:1


1 ) 方案1:装饰器声明式(推荐)

// app.module.ts 
import { RabbitMQModule } from '@golevelup/nestjs-rabbitmq';
 
@Module({
  imports: [
    RabbitMQModule.forRoot(RabbitMQModule, {
      exchanges: [
        { name: 'dlx_exchange', type: 'direct' },
        { name: 'main_exchange', type: 'topic' }
      ],
      uri: 'amqp://user:pass@localhost:5672',
      channels: {
        'channel-1': { prefetchCount: 10 },
        'channel-2': { default: true }
      }
    })
  ]
})
export class AppModule {}
 
// consumer.service.ts 
@Injectable()
export class ConsumerService {
  @RabbitSubscribe({
    exchange: 'main_exchange',
    routingKey: '*.event',
    queue: 'event_queue',
    queueOptions: {
      deadLetterExchange: 'dlx_exchange',
      messageTtl: 30000,
      maxLength: 100 
    }
  })
  handleEvent(msg: {}, raw: amqplib.ConsumeMessage) {
    if (businessError) {
      throw new Error('触发DLX'); // 异常自动进入死信队列 
    }
    return { ack: true }; // 手动ACK 
  }
}

2 )方案2:编程式动态声明

// dynamic-queue.provider.ts 
import { RabbitMQChannel } from '@golevelup/nestjs-rabbitmq';
 
@Injectable()
export class QueueProvider {
  constructor(
    @InjectRabbitChannel('channel-1') private channel: RabbitMQChannel 
  ) {}
 
  async setup() {
    await this.channel.assertExchange('dynamic_ex', 'fanout');
    await this.channel.assertQueue('dynamic_queue', {
      arguments: { 'x-queue-type': 'quorum' }
    });
    await this.channel.bindQueue('dynamic_queue', 'dynamic_ex', '');
  }
}

3 ) 方案3:混合部署方案

# docker-compose.yml (RabbitMQ集群)
version: '3'
services:
  rabbit1:
    image: rabbitmq:3.11-management 
    environment:
      RABBITMQ_ERLANG_COOKIE: "SECRET"
      RABBITMQ_NODENAME: "rabbit@node1"
    ports:
      - "15672:15672"
      - "5672:5672"
 
  rabbit2:
    image: rabbitmq:3.11-management 
    environment:
      RABBITMQ_ERLANG_COOKIE: "SECRET"
      RABBITMQ_NODENAME: "rabbit@node2"
    links:
      - rabbit1 

工程示例:2


以下提供三种场景的完整实现,使用 @nestjs/microservices 与 amqplib 封装 RabbitMQ 操作:

1 ) 方案 1:消息级 TTL 实现

import { Injectable } from '@nestjs/common';
import { connect, Channel, Message } from 'amqplib';
 
@Injectable()
export class OrderService {
  private channel: Channel;
 
  async setup() {
    const conn = await connect('amqp://localhost');
    this.channel = await conn.createChannel();
  }
 
  async sendMessage() {
    await this.channel.assertQueue('restaurant', { durable: true });
    const message = JSON.stringify({ orderId: '123' });
    
    // 设置单条消息过期时间 (15秒)
    const properties = {
      expiration: '15000', // 单位:毫秒 
    };
    
    this.channel.sendToQueue(
      'restaurant',
      Buffer.from(message),
      properties,
    );
  }
}

2 )方案 2:队列级 TTL + 死信队列集成

import { Injectable, OnModuleInit } from '@nestjs/common';
import { connect, Channel, ConsumeMessage } from 'amqplib';
 
@Injectable()
export class RestaurantConsumer implements OnModuleInit {
  private channel: Channel;
 
  async onModuleInit() {
    const conn = await connect('amqp://localhost');
    this.channel = await conn.createChannel();
 
    // 声明死信交换机(DLX)和死信队列(DLQ)
    await this.channel.assertExchange('dlx.exchange', 'topic', { durable: true });
    await this.channel.assertQueue('dlq.queue', { durable: true });
    await this.channel.bindQueue('dlq.queue', 'dlx.exchange', '#');
 
    // 声明业务队列并绑定死信属性 
    await this.channel.assertQueue('restaurant', {
      durable: true,
      arguments: {
        'x-message-ttl': 15000, // 队列统一过期时间 
        'x-dead-letter-exchange': 'dlx.exchange', // 死信转发目标
        'x-max-length': 5, // 队列最大长度(可选)
      },
    });
 
    this.channel.consume('restaurant', (msg: ConsumeMessage) => {
      try {
        console.log('Processing:', msg.content.toString());
        this.channel.ack(msg); // 正常签收
      } catch (error) {
        this.channel.nack(msg, false, false); // 拒收且不重回队列 → 死信
      }
    });
  }
}

3 )方案 3:动态 TTL 与死信监控

import { Injectable } from '@nestjs/common';
import { connect, Channel } from 'amqplib';
 
@Injectable()
export class DeadLetterMonitor {
  async monitorDeadLetters() {
    const conn = await connect('amqp://localhost');
    const channel = await conn.createChannel();
    
    // 监听死信队列
    channel.consume('dlq.queue', (msg: ConsumeMessage) => {
      const originQueue = msg.properties.headers['x-first-death-queue'];
      const reason = msg.fields.routingKey; // 死信原因:expired/rejected/maxlen
      
      console.error(`[DLQ Alert] From: ${originQueue}, Reason: ${reason}`);
      // 可扩展:告警通知、消息持久化存储等 
      channel.ack(msg);
    });
  }
}

RabbitMQ 周边配置要点


  1. 队列参数修改:

    • 必须删除旧队列:声明队列时若参数变更(如 TTL 值),需先在 RabbitMQ 管控台删除原队列,否则 channel.assertQueue() 会报错。
    • 避免跨服务声明队列:上游服务不应替下游声明队列,避免参数冲突。
  2. 连接与通道管理:

    • 使用 amqplib 时需显式管理连接池,推荐 amqp-connection-manager 库自动重连。
    • NestJS 项目中可通过 @golevelup/nestjs-rabbitmq 模块简化集成。
  3. 死信分析工具:

    • 死信消息携带 x-death 头信息,包含来源队列、过期时间、死信原因(如 expired/rejected/maxlen)。
    • 可通过 msg.properties.headers['x-death'] 解析异常根源。

最佳实践与避坑指南


  1. 特性选用原则

    • 积极采用:ACK机制、死信队列、TTL
    • 谨慎使用:消息重入(易导致循环阻塞)
    • 避免滥用:发送端事务(性能损耗严重)
  2. 管控台调试技巧

    • 直接创建TTL/死信队列验证参数
    • 通过Queues标签页监控Ready/Unacked消息比例
    • 使用Flow Control功能模拟网络分区
  3. NestJS集成要点

    • 使用forRootAsync实现配置动态加载
    • 通过ConnectionManager复用TCP连接
    • 异常消息统一进入DLX后触发告警

关键结论:消费端ACK+死信队列的组合方案侵入性最低且可靠性最高,建议作为核心消息保障机制。通过NestJS的装饰器方案,可将原始代码量减少70%以上,同时提升可维护性。

附录:RabbitMQ命令速查


# 声明死信队列 
rabbitmqadmin declare queue name=dlx_queue arguments='{"x-dead-letter-exchange":"main_dlx"}'
 
# 查看消息阻塞状态 
rabbitmqctl list_queues name messages_unacknowledged 
 
# 清除故障队列 
rabbitmqadmin purge queue name=stuck_queue 

技术总结与最佳实践


  1. TTL 使用场景:

    • 高吞吐系统(如订单/秒杀)需设置合理 TTL 防止积压。
    • 结合业务峰值与服务 SLA 动态调整 TTL 值。
  2. 死信队列设计原则:

    • 必选项:生产环境必须配置 DLQ,避免消息静默丢失。
    • 隔离处理:独立消费者处理死信,避免影响主业务逻辑。
  3. NestJS 生态整合建议:

    • 使用 @nestjs/microservices 的 RabbitMQTransport 标准化消息通信。
    • 封装 RabbitMQModule 统一管理连接、重试策略及异常处理。

初学者提示:

  • TTL(Time-To-Live):消息存活倒计时,超时后自动清除。
  • DLQ(Dead Letter Queue):存储“失败消息”的专用队列。
  • DLX(Dead Letter Exchange):路由死信到 DLQ 的交换机。

通过 TTL 与死信队列的协同设计,可构建高鲁棒性消息系统,确保异常消息可追溯、可恢复,为分布式架构提供核心可靠性保障。

【RabbitMQ】延迟队列之死信交换机 延迟队列是一种特殊类型的消息队列,它允许将消息在一定的延迟时间后才被消费。在传统的消息队列中,消息一旦发送到队列中就会立即被消费者获取并处理。而延迟队列则提供了一种延迟消息处理的机制。 阅读详情

相关推荐

RabbitMQ学习笔记

RabbitMQ是由erlang语言开发,基于AMQP(Advanced Message Queue 高级消息队列协议)协议实现的消息队列,它是一种应用程序之间的通信方法,消息队列在分布式系统开发中应用非常广泛。简单模式,work模式,Publish/Subscribe发布与订阅模式,Routing路由模式,Topics主题模式,RPC远程调用模式(远程调用,不太算MQ;暂不作介绍);安装成功后,在sbin目录下cmd执行启动管理功能默认账号密码 guest1.导入依赖2.编写连接工具类。

m0_74193457的博客 1149

死信队列详解

在消息队列中,执行异步任务时,通常是将消息生产者发布的消息存储在队列中,由消费者从队列中获取并处理这些消息。但是,在某些情况下,消息可能无法正常地被处理和消耗,例如:格式错误、设备故障等,这些未成功处理的消息就被称为“死信”。为了避免这些未成功处理的消息导致程序异常或对系统造成影响,我们需要使用死信队列当我们设置死信队列后,所有无法成功处理的消息将被捕获并重定向到指定的死信交换机中。消费者可以从该交换机中读取并处理这些“死信”。

DevCorner的Pro技术博客 8359

RabbitMQ 高级特性解析:TTL、死信队列与延迟队列的应用实战

通过 RabbitMQ 提供的TTL(生存时间)死信队列(DLX)和延迟队列,我们能够更加灵活地管理消息流。无论是为了控制消息的过期、处理无法消费的消息,还是为了延迟消息的投递,这些特性都极大地增强了消息队列的可扩展性和可靠性。TTL:确保消息和队列不会无限期存在,防止资源浪费。死信队列(DLX):提供一种机制来处理失败的消息,方便进行消息重试、日志记录等。延迟队列:使得任务可以在指定时间后延迟执行,广泛应用于定时任务、消息重试等场景。

这里只有干货:从 Modbus 通信到 MES 对接,从 YOLO 训练到工控机部署,带你搞定工业软件开发全流程。 1061

死信队列

死信队列 什么是死信队列 一般来说,producer将消息投递到queue中,consumer从queue取出消息进行消费,但某些时候由于特定的原因导致queue中的某些消息无法被消费,这样的消息如果没有后续的处理,就变成了死信(Dead Letter),所有的死信都会放到死信队列中。 “死信”消息会被RabbitMQ进行特殊处理,如果配置了死信队列信息,那么该消息将会被丢进死信队列中,如果没有配置,则该消息将会被丢弃。 消费者消费消息 ​ 1)正常消费–>手动ack–>MQ从队列中删除消息

qq_43644198的博客 2万+

深入剖析RabbitMQ死信队列与TTL:构建高可靠延时消息系统的核心机制

本文深入解析RabbitMQ死信队列与TTL机制,详细讲解如何构建高可靠的延时消息系统。通过电商订单超时关闭等典型应用场景,展示TTL设置、死信队列配置及Spring Boot集成方案,帮助开发者掌握延时队列的核心实现与优化技巧,提升消息系统的可靠性与灵活性。

weixin_34364071的博客 306

多摄像头同步技术:帧同步信号在Sensor与解串器间的传递机制

本文深入探讨了多摄像头系统中帧同步信号的两种核心传递机制:由解串器统一发号施令或由主Sensor作为“带头大哥”。文章对比了两种方案在同步精度、硬件复杂度、成本及适用场景上的差异,并提供了实战配置要点与调试心法,为车载环视、ADAS及工业检测等应用提供关键的技术选型与实施指导。

weixin_29193359的博客 435

【RabbitMQ】死信(延迟队列)的使用

持久化exchange要持久化queue要持久化message要持久化消息确认启动消费返回(@ReturnList注解,生产者就可以知道哪些消息没有发出去)生产者和Server(broker)之间的消息确认消费者和Server(broker)之间的消息确认。

无法自律的人的博客 5420

INCA文件刷写全流程:从ES581驱动安装到XCP协议实战(附避坑指南)

本文详细解析INCA文件刷写的全流程操作,从ES581驱动安装到XCP协议配置,提供实战经验与避坑指南。涵盖A2L文件校验、工作区优化、XCP参数调优及自动化刷写技巧,帮助工程师高效完成ECU开发中的文件刷写任务。

egg99的博客 945

死信队列实现超时订单自动关闭:原理、实战与避坑指南

消息队列的延迟消息机制常用于异步通信与任务调度,其核心原理是通过TTL与死信交换机将过期消息路由至死信队列,从而实现延迟触发。在电商交易系统中,这一机制能有效解决订单超时未支付导致的库存占用问题,提升系统实时性与扩展性。典型应用场景包括超时关单、库存回滚及状态机幂等处理。本文围绕死信队列的底层机制与工程实践,详细拆解超时关单的完整链路,涵盖队列声明、TTL配置、消费者幂等及生产环境加固,并分享实战踩坑与排查经验。

weixin_42626599的博客 283

树莓派CM4 PCIe扩展方案与ASM1184e芯片应用

PCIe(Peripheral Component Interconnect Express)是计算机硬件中重要的高速串行总线标准,广泛应用于存储、网络等设备连接。其核心原理是通过差分信号实现高带宽传输,PCIe Gen2 x1的理论带宽可达5Gbps。在嵌入式开发中,PCIe扩展技术能有效解决单板计算机接口不足的问题,特别适合树莓派等微型平台。ASMedia ASM1184e作为PCIe交换芯片,可将单个接口扩展为多个,支持热插拔且免驱动,极大提升了工程灵活性。通过PCIe交换机方案,开发者能在树莓派CM

weixin_42602368的博客 424

MICROSAR OS:第一个task是如何执行起来的?

MICROSAR OS是Vector公司开发的符合AUTOSAR OS规范的实时操作系统。本文介绍MICROSAR

humu7733的博客 2575

RabbitMQ 死信队列(DLX)全面解析:是什么、工作流程、应用场景与实战配置

在 RabbitMQ 实际生产环境中,消息消费失败、消息过期、队列溢出是非常常见的问题。如果这些消息不做处理,就会导致业务数据丢失、系统异常。而**死信队列(DLX)**就是专门用来解决这类问题的核心机制。本文将用通俗定义、完整流程图、核心场景、实战代码、生产避坑全方位讲解死信队列,让你彻底掌握 DLX 的原理与使用。死信交换机,也叫死信队列。当消息在一个队列中变成死信(Dead Message)后,会被重新转发到另一个交换机(死信交换机),绑定这个交换机的队列就是死信队列。

✨ 欢迎来到【Seal ^_^ 的优快云博客】!✨ 1857

Android影像系统架构专家面试指南

传音控股招聘影像系统架构专家,要求8年以上开发经验,5年架构设计经验,精通Android Camera开发及性能优化。该职位需负责手机影像软件架构设计、技术选型及跨平台适配,重点解决"快稳省"体验优化。面试评估聚焦三大维度:技术方面考察HAL层架构设计、多帧合成优化等能力;系统开发关注低光降噪等场景的算力平衡;团队管理侧重跨部门协作与项目交付。候选人需展现对CamX-CHI等架构的深入理解,具备量化分析性能指标的能力,并能主导旗舰机影像项目全周期落地。

郑伟强dev的专栏 945

死信队列(DLQ)深度解析:过期消息、拒绝消息的优雅处理方案

本文深入解析了死信队列(DLQ)在分布式系统中的关键作用与实现机制。死信队列作为消息队列的特殊路由机制,为异常消息提供"不丢失、可追溯、可重试"的安全处理方案。文章详细阐述了三种主要死信产生场景:消息TTL过期、消费端拒绝消息以及队列消息堆积超限。通过RabbitMQ实例,展示了死信队列的完整配置流程,包括普通队列与死信交换机的绑定、死信队列的创建等核心环节。死信队列的设计有效解决了分布式系统中消息失效导致的业务中断问题,为系统可靠性提供了重要保障。

码路同行 924

用Obsidian搭建个人知识库:AI时代如何构建你的第二大脑

AI 时代,真正有价值的不只是获取知识,而是沉淀属于自己的知识体系。本文从 Obsidian 安装、目录设计、双向链接、插件推荐到 AI 联动、多端同步,手把手教你打造高效、可持续进化的个人知识库,让知识真正为你所用。🧠

XiaoqiangClub的博客 473

Win7 x64位系统下几乎完美使用安装RTX3050 6G显卡驱动详细教程

RTX3050 6G显卡驱动安装指南:由于该显卡发布时间晚于驱动,需手动修改安装文件。首先在NVIDIA官网下载驱动并解压,通过设备管理器获取硬件ID(PCI\VEN_10DE&DEV_2584),然后在解压目录的.inf文件中添加对应的设备标识。安装完成后可能出现设备管理器感叹号问题,推荐通过命令提示符启用测试模式(bcdedit /set testsigning on)解决,此方法无需每次启动按F8,但会显示测试模式水印。文中提供了详细的图文操作步骤和两种解决方案。

m0_67194883的博客 2898

RabbitMQ: 高级特性详解之消息返回机制与消费端确认机制

RabbitMQ消息处理机制:生产者通过设置mandatory=true实现消息返回机制,当路由失败时触发回调处理;消费端采用手动ACK模式确保消息可靠处理,支持重试与死信队列。NestJS集成方案提供基础生产消费功能,并扩展死信队列处理,通过set_policy配置DLX实现异常消息隔离。关键点包括通道生命周期管理、异步回调处理和业务幂等性设计,确保消息可靠投递与处理。

Wang的专栏 2530

【即插即用模块】卷积篇 | TCSVT 2025 | MFACB:多尺度膨胀融合,快速扩大感受野,多尺度特征精准捕捉!

本文提出了一种新型多尺度融合膨胀卷积模块MFACB,用于增强语义分割任务中的特征表达能力。该模块通过三分支串联膨胀卷积结构快速扩大感受野,采用双路径融合机制(基础信息路径+多尺度信息路径)实现高效上下文聚合。相比传统卷积块,MFACB在保持轻量化的同时显著提升了多尺度特征捕捉能力,实验表明其性能优于基础残差块。该模块支持自定义膨胀率和步长调整,可灵活嵌入不同网络阶段,适用于需要特征增强的视觉任务。

主要更新底层视觉(去噪、超分等)相关的科研内容,形式为【论文精读】+【论文复现】 311

RabbitMQ面试精讲 Day 7:消息持久化与过期策略

持久化需要Exchange、Queue、Message三级配置TTL可以设置在队列或消息级别死信队列是处理过期消息的有效方式持久化会显著影响性能,需要合理优化完整的可靠性需要端到端设计。

在未来等你的专栏 1248

Probability and Statistics - 4th edition

Probability and Statistics - 4th edition

假人有限元模型

假人模型,车辆碰撞假人有限元模型,适合做乘员安全的研究者利用

RabbitMQ的高级特性和消息补偿机制

学习技术是一条慢长而艰苦的道路,不能靠一时激情,也不是熬几天几夜就能学好的,必须养成平时努力学习的习惯。所以:贵在坚持!最后再分享的一些BATJ等大厂20、21年的面试题,把这些技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,由于篇幅有限,上面只是以图片的形式给大家展示一部分。Mybatis面试专题MySQL面试专题并发编程面试专题《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!

2303_77877769的博客 1127

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

【Spring Boot RabbitMQ死信队列TTL深度解析】:掌握消息延迟处理的终极方案

掌握Spring Boot RabbitMQ死信队列的TTL,精准实现消息延迟处理。适用于订单超时、任务调度等场景,通过设置TTL和死信交换机路由过期消息,保障系统可靠性与灵活性。配置简单、易于维护,是构建高可用消息系统的理想方案,值得收藏。

CodeTrick的博客 613

LinePhone3.2.7(android端最新版本) sip客户端

SIP客户端For android:LinePhone3.2.7(最新版本),官网地址:http://www.linphone.org/

揭秘RabbitMQ死信队列TTL机制:如何精准控制消息过期时间

掌握Spring Boot RabbitMQ死信队列的TTL机制,精准控制消息过期与延迟处理,适用于订单超时、任务调度等场景。通过设置消息TTL和死信交换机实现可靠路由,提升系统健壮性,值得收藏。

CompiLume的博客 373

RabbitMQ 消息过期机制(TTL):队列 TTL 与消息 TTL 的区别

RabbitMQ 的 TTL(Time To Live,生存时间)机制用于控制消息或队列的存活时间,防止消息无限期滞留。TTL 分为队列级别和消息级别,两者在作用对象、设置方式、行为结果上存在关键区别。下面我将逐步解释这些区别,确保内容基于真实可靠的 RabbitMQ 实现(版本 3.8+)。通过以上解释,您应该能清晰区分队列 TTL 和消息 TTL。实际应用中,根据需求选择合适的机制:如果需管理队列生命周期,用队列 TTL;如果需控制消息时效,用消息 TTL。如有具体场景问题,欢迎提供更多细节!

2501_93894306的博客 816

C# RabbitMQ 失败消息重新投递 设置消息投递次数与间隔时间 死信队列使用方法

1.1、了解 RabbitMQ 失败消息重新投递机制 Rabbit 失败消息重新投递机制 1.2、了解什么是消息确认机制 MQ消息确认类似于数据库中用到的 commit 语句,用于告诉broker本条消息是被消费成功了还是失败了; 平时默认消息在被接收后就被自动确认了,需要在创建消费者时、设置 autoAck: false 即可使用手动确认模式; 1.3、了解什么是死信队列 死信队列是用于接收普通队列发生失败的消息,其原理与普通队列相同; > 失败消息如:被消费者拒绝的消息、TTL.

rcr676的博客 4112

RabbitMQ:RabbitMQ无法路由消息处理机制深度解析:从死信队列到生产实践

RabbitMQ中无法路由的消息处理机制是消息可靠性的重要保障,其核心流程如下:fill:#333;color:#333;color:#333;fill:none;是否是否是否是否生产者发布消息路由成功?进入队列配置了备用交换器?转发到备用交换器设置了mandatory标志?触发ReturnListener回调消息被静默丢弃备用交换器有匹配队列?进入备用队列进入死信队列或丢弃。

weixin_43290370的博客 895

RabbitMQ之死信队列

图片代码消费者拒绝TTL过期队列满监控DLQ深度分析死信原因检查消费者日志/错误调整TTL或处理逻辑扩容消费者或削峰C/F/G修复代码安全重试消息确认业务恢复。1.​独立消费者组​DLQ 消费者需与主业务隔离(避免占用正常资源)3.​熔断机制​若重试成功率 < 10%,暂停重试并发出告警。2.​闭环处理​:分析 → 修复 → 重试 → 验证。1.​监控先行​:DLQ 深度 >0 即告警。3.​安全重试​:渐进延时 + 重试次数控制。4.​防止污染​:隔离 DLQ 消费者资源。步骤 4:安全重试(3种方案)

YangChingyuk的博客 1044
上一篇: RabbitMQ: 高级特性详解之消息返回机制与消费端确认机制
下一篇: RabbitMQ: 消息监听机制深度解析之从 SimpleMessageListenerContainer 到工程实现
Wang's Blog
博客等级 码龄12年 7438粉丝 2422原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

Wang's Blog

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

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

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

打赏作者

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

抵扣说明:

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

余额充值