大家是否知道rabbitmq呢?是的，队列消息，最近火热的框架技术就是springboot了吧,那么我们是如何使用springboot来整合rabbitmq的呢?今天就由小编给大家带来这个知识，让我们一起俩了解下吧

RabbitMQ 实战：死信队列认识与场景实战

死信队列认识

死信队列，又可以称之为“延迟/延时队列”，也是队列的一种，只不过与普通的队列最大的不同之处在于创建时的组成成分不同，创建死信队列的“成分”将不仅仅只是：名称、持久化、自动删除等基本属性，还包含了死信交换机、死信路由甚至还有TTL(Time-To-Live)即队列中消息可生存的时间。

死信队列其实最大的作用是可以实现消息或者数据延迟/延时处理，而且还可以动态的设定延迟的时间，即动态设定 TTL。典型的业务场景很多，在这里就不一一列举了，总之，凡是业务中需要延迟一定时间再处理的数据均可以将其压入死信队列中，等待一定的时间后再执行真正的处理逻辑!

下面是死信队列在创建、绑定、生产消息、消费消息过程的结构流程图，在这里其实已经很明确的指出死信队列的创建跟绑定逻辑 以及 真正监听消费处理消息的队列的绑定逻辑。图中问题的答案为：当入死信队列的消息TTL一到，它自然而然的将被路由到 死信交换机绑定的队列 中被真正消费处理!



死信队列场景实战

有了上面的流程图做指导，接下来，我们将用死信队列实战这样的一个业务场景：用户在商城下单成功并点击去支付后在指定时间未支付时自动失效!于是乎，我们需要创建两个消息模型，在 RabbitmqConfig 实施：

死信队列：用于设定指定的待支付的交易订单号在指定的 TTL(单位为 ms)后何去何从!

真正队列：用于监听消费处理指定的交易订单号，即判断该交易订单号是否已完成，如果否，则失效之!

接下来是我们的生产端的逻辑：用户商城下单的处理!



接下来是等待固定的 TTL：在这里设定的是 10s，当消息入死信队列 10s 后，将自然而然的将消息路由到下一个中转站，即真正的消费监听处理队列进行处理：判断该笔交易订单号是否已经付款，如果否，则失效之!



可以将该服务跑起来，然后发起 controller 的用户下单请求，会发现消息入死信队列后不会立马被消费，等待 10s 会，消息会被路由到真正的消费队列中进行处理，这一现象可以在 MQ 的后端控制台应用中看到!

总结：到此我们的死信队列已经实战完毕，回顾我们所介绍的历程，其实核心重点在于上面的那张 “死信队列的结构流程图”，理解了这个结构流程图中的相关组件及其流程，则在实战各种需要延时处理的业务场景将得心应手，包括如何创建死信队列，如何面向生产端绑定死信队列，如何面向消费端绑定真正的队列等等!而对于死信队列的实战场景，前面也介绍过了：凡是需要等待一定时间或者需要缓一缓特定时间的业务、数据均可以通过死信队列来实现!

好了，今天的知识就讲到这里了，想要了解更多关于Java入门的知识，请继续关注本网站。