RabbitMQ死信与延迟队列的区别与实现

摘要：对于消息中间件RabbitMQ，想必各位小伙伴并不陌生，其广泛应用程度不言而喻，此前我们也在许多课程以及诸多专栏文章中介绍了它的应用，其应用场景也是相当广泛的，像什么消息异步通信、服务模块解耦、高并发流量削峰、订单超时未支付自动失效等等都是实际项目中最为常见的场景。本文我们将重点介绍并实现RabbitMQ的死信与延时队列，并将两者做一个简单的对比！

内容：对于RabbitMQ的死信队列，此前我们在“Java秒杀系统”这一技术专栏中已经有重点介绍过了，在那里我们是将其应用于 “订单超时未支付自动失效”这一业务场景中，简而言之，“死信队列”是一种特殊的“队列”，跟普通的队列相比，具有“延迟处理任务”的特性。

而在消息中间件RabbitMQ的架构组件中，也存在着跟“死信队列”在功能特性方面几乎相同的组件，那就是“延迟队列/延时队列”，同样也具有“延迟、延时处理任务”的功效！

当然啦，这两者还是有一丢丢区别的，最直观的当然是名字上啦，从名字上你就可以看出来两者的“处事风格”是不一样的，具体体现在：

一、创建上的差异：

（1）RabbitMQ的死信队列DeadQueue是由“死信交换机DLX”+“死信路由DLK”组成的，当然，可能还会有“TTL”，而DLX和DLK又可以绑定指向真正的队列RealQueue，这个队列RealQueue便是“消费者”真正监听的对象.

（2）而RabbitMQ的延迟/延时队列DelayedQueue 则是由普通的队列来创建即可，唯一不同的地方在于其绑定的交换机为自定义的交换机，即“CustomExchange”，在创建该交换机时只需要指定其消息的类型为 “x-delayed-message”即可.“消费者”真正监听的队列也是它本人，即DelayedQueue

（画外音：从这一点上看，延迟/延时队列的创建相对而言简单一些！）

二、功能特性上的差异：

（1）死信队列在实际应用时虽然可以实现“延时、延迟处理任务”的功效，但进入死信中的消息却依然保留了队列的特性，即“FIFO” ~ 先进先出，而不管先后进入队列中消息的TTL的值. 即假设先后进入死信的消息为A、B、C，各自的TTL分别为：10s、3s、5s，理论上TTL先后到达的顺序是：B、C、A，然后从死信出来，最终被路由到真正的队列中，即消息被消费的先后顺序应该为：B、C、A，然而现实却是残酷的，其最终消费的消息的顺序为：A、B、C，即“消息是怎么进去的，就怎么出来”，保留了所谓的FIFO特性.

（2）或许是因为死信有这种缺陷，所以RabbitMQ提供了另一种组件，即“延迟队列”，它可以很完美的解决上面死信出现的问题，即最终消费的消息的顺序为：B、C、A，我们将在下面用实际的代码进行实战实现与演练.

三、插件安装上的差异：

（1）死信不需要额外的插件

（2）但是延迟队列在实际项目使用时却需要在Mq Server中安装一个插件，它的名字叫做：“rabbitmq_delayed_message_exchange”，其安装过程可以参考链接：RabbitMQ延迟队列插件安装 - 墨雨生花 - 博客园  里面就提供了Windows环境和Linux环境下的插件的安装过程（很简单，只需要不到3步的步骤.）

四、代码的实战实现~RabbitMQ的死信队列

       说了这么多，想必有些小伙伴有点不耐烦了，下面我将采用实际的代码对上面所介绍的几点区别进行实现与演练（代码都是基于Spring Boot2.0搭建的项目环境实现与测试的）

更多请见：http://www.mark-to-win.com/tutorial/51110.html