12. 消息队列-RabbitMQ-高可用核心机制

文章目录前言一、 消费端限流 (QoS)1. 为什么需要限流2. 核心原理prefetchCount3. 关键前提必须手动 ACK4. Spring Boot 配置示例二、⏳ 消息过期时间 (TTL)1. 两种设置方式2. 过期消息的去向三、⚰️ 死信队列 (DLQ)1. 消息成为“死信”的三种场景2. 死信流转流程四、 高级应用实现延迟队列1. 核心思想2. 典型场景订单超时自动关闭前言限流、TTL、死信队列‌构建高可用、高可靠 RabbitMQ 系统的“三驾马车”。它们分别解决了消费过载、消息过期和异常处理的问题。。一、 消费端限流 (QoS)消费端限流也称为服务质量QoS其核心目的是防止消费者被消息淹没。1. 为什么需要限流想象一个场景你的 RabbitMQ 队列中积压了 10 万条消息此时你启动了消费者服务。如果不限流RabbitMQ 会瞬间将这 10 万条消息全部推送给消费者。如果消费者的处理能力有限例如需要调用耗时的外部 API这会导致内存溢出 (OOM)大量消息堆积在内存中。服务假死CPU 和线程资源被耗尽。系统崩溃整个消费者服务宕机。限流就是给消费者一个“安全阀”让它按照自己的能力去处理消息。2. 核心原理prefetchCountRabbitMQ 通过basic.qos命令实现限流其中最关键的参数是prefetchCount。含义它定义了每个消费者最多能同时持有即已接收但未确认的消息数量。工作流程设置prefetchCount 5。消费者启动后RabbitMQ 会立即推送 5 条消息给它。消费者处理完其中 1 条并发送ACK确认后RabbitMQ 才会再推送第 6 条消息给它。这个过程持续进行确保消费者始终只处理 5 条消息实现了“按需拉取”。3. 关键前提必须手动 ACK限流只在手动确认Manual ACK模式下生效如果使用自动 ACK消息一旦被推送出去就被视为已消费RabbitMQ 会继续疯狂推送prefetchCount设置将完全失效。4. Spring Boot 配置示例在application.yml中通过以下配置即可轻松实现限流spring:rabbitmq:listener:simple:acknowledge-mode:manual# 1. 开启手动ACKprefetch:10# 2. 设置每个消费者最多预取10条消息concurrency:5# 3. 启动5个消费者线程在这个配置下你的应用最多可以同时处理10 * 5 50条消息有效控制了并发量。二、⏳ 消息过期时间 (TTL)TTLTime To Live即消息的生存时间。超过这个时间的消息会被视为“过期”RabbitMQ 会将其丢弃。1. 两种设置方式RabbitMQ 支持两种 TTL 设置它们可以组合使用以较短的时间为准。队列级 TTL作用范围对整个队列生效队列中所有消息的过期时间都相同。设置方式在声明队列时通过x-message-ttl参数设置单位为毫秒。优点性能高。RabbitMQ 只需定期检查队首消息是否过期即可。适用场景所有消息具有相同的有效期如“所有订单30分钟后关闭”。消息级 TTL作用范围对单条消息生效每条消息可以有不同的过期时间。设置方式在发布消息时通过expiration属性设置单位为毫秒。缺点性能开销较大。因为每条消息的过期时间不同RabbitMQ 无法只检查队首需要在消息即将被投递时才判断是否过期懒删除。适用场景不同消息需要不同的有效期。2. 过期消息的去向默认情况下过期消息会被直接删除。但更常见的做法是结合死信队列来处理。三、⚰️ 死信队列 (DLQ)死信队列Dead Letter Queue, DLQ是一个“避难所”用于存放那些无法正常被消费的消息。1. 消息成为“死信”的三种场景消费者拒收消费者处理消息失败调用basicNack或basicReject并设置requeuefalse不重新入队。消息过期消息的 TTL 时间到期。队列满了队列长度超过了设置的最大值x-max-length最早的消息会被挤出成为死信。2. 死信流转流程普通队列 → 死信交换机 (DLX) → 死信队列 (DLQ)在声明普通队列时通过x-dead-letter-exchange参数指定一个死信交换机。当消息在普通队列中成为死信后RabbitMQ 会将其重新发布到这个死信交换机。死信交换机根据路由键x-dead-letter-routing-key将消息路由到最终的死信队列。你可以为死信队列配置专门的消费者用于记录日志、发送告警或进行人工干预。四、 高级应用实现延迟队列将TTL和死信队列结合是 RabbitMQ 实现延迟队列的经典模式。RabbitMQ 本身不直接支持延迟消息但可以通过这个技巧来实现。1. 核心思想让消息在“普通队列”中等待一段时间TTL过期后自动转为死信进入“死信队列”由“死信队列”的消费者进行真正的业务处理。这个“等待时间”就是延迟时间。2. 典型场景订单超时自动关闭创建组件延迟队列一个没有消费者的普通队列设置x-message-ttl1800000(30分钟)并绑定到死信交换机。死信交换机 (DLX)一个普通的 Direct 或 Topic 交换机。死信队列 (DLQ)一个有消费者的队列绑定到死信交换机。工作流程用户下单后生产者向“延迟队列”发送一条消息。由于“延迟队列”没有消费者消息会一直等待。30分钟后消息 TTL 过期成为死信。死信被转发到“死信交换机”再路由到“死信队列”。“死信队列”的消费者收到消息执行业务逻辑如“检查订单支付状态若未支付则关闭订单”。通过这种方式你巧妙地利用 RabbitMQ 的现有特性实现了强大的定时任务功能。