RabbitMQ之延迟队列

本文介绍了RabbitMQ实现延迟队列的方法,主要应用于处理如订单超时等场景。传统方法通过定时任务处理,但存在效率和实时性问题。RabbitMQ通过结合TTL和DLX(死信交换机)实现延迟队列,消息过期后进入死信队列进行消费,从而降低服务器和数据库的压力,并确保数据的持久化。文中详细阐述了TTL、DLX的概念和设置,以及实现延迟队列的开发步骤。
摘要由CSDN通过智能技术生成

 前期回顾:


目录

一、延迟队列的应用场景

1. 场景:“订单下单成功后,15分钟未支付自动取消”

   1.传统处理超时订单

   2.rabbitMQ延时队列方案

二、延迟队列中的消息投递和消息消费

2. TTL和DLX

1.TTL

2.DLX和死信队列

3. 延迟队列

4. 开发步骤

5. json转换


一、延迟队列的应用场景

1. 场景:“订单下单成功后,15分钟未支付自动取消”


   1.传统处理超时订单


     采取定时任务轮训数据库订单,并且批量处理。其弊端也是显而易见的;对服务器、数据库性会有很大的要求,
     并且当处理大量订单起来会很力不从心,而且实时性也不是特别好。当然传统的手法还可以再优化一下,
     即存入订单的时候就算出订单的过期时间插入数据库,设置定时任务查询数据库的时候就只需要查询过期了的订单,
     然后再做其他的业务操作 

   2.rabbitMQ延时队列方案


     一台普通的rabbitmq服务器单队列容纳千万级别的消息还是没什么压力的,而且rabbitmq集群扩展支持的也是非常好的,
     并且队列中的消息是可以进行持久化,即使我们重启或者宕机也能保证数据不丢失

二、延迟队列中的消息投递和消息消费


2. TTL和DLX


   rabbitMQ中是没有延时队列的,也没有属性可以设置,只能通过死信交换机(DLX)和设置过期时间(TTL)结合起来实现延迟队列

   1.TTL


     TTL是Time To Live的缩写, 也就是生存时间。
     RabbitMq支持对消息和队列设置TTL,对消息这设置是在发送的时候指定,对队列设置是从消息入队列开始计算, 只要超过了队列的超时时间配置, 那么消息会自动清除。
     如果两种方式一起使用消息的TTL和队列的TTL之间较小的为准,也就是消息5s过期,队列是10s,那么5s的生效。
     默认是没有过期时间的,表示消息没有过期时间;如果设置为0,表示消息在投递到消费者的时候直接被消费,否则丢弃。

     设置消息的过期时间用 x-message-ttl 参数实现,单位毫秒。
     设置队列的过期时间用 x-expires 参数,单位毫秒,注意,不能设置为0。

     消息:生产者 -> 交换机 消息在生产者制造消息的时候就开始计算了TTL  TTL=5
     队列:生产者 -> 交换机 -> 路由键 -> 队列 当消息送达到队列的时候才开始计算TTL  TTL=10
     

   2.DLX和死信队列


     DLX即Dead-Letter-Exchange(死信交换机),它其实就是一个正常的交换机,能够与任何队列绑定。

     死信队列是指队列(正常)上的消息(过期)变成死信后,能够发送到另外一个交换机(DLX),然后被路由到一个队列上,
     这个队列,就是死信队列

     成为死信一般有以下几种情况:
     消息被拒绝(basic.reject or basic.nack)且带requeue=false参数
     消息的TTL-存活时间已经过期
     队列长度限制被超越(队列满)

     

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

酒醉猫(^・ェ・^)

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

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

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

打赏作者

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

抵扣说明:

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

余额充值