1. 死信队列&死信交换器：
DLX 全称（Dead-Letter-Exchange）,称之为死信交换器，当消息变成一个死信之后，如果这个消息所在的队列存在x-dead-letter-exchange参数，那么它会被发送到x-dead-letter-exchange对应值的交换器上，这个交换器就称之为死信交换器，与这个死信交换器绑定的队列就是死信队列。
说实在的，死信队列和普通队列没啥区别，都需要自己创建Queue、Exchange，然后通过RoutingKey绑定到Exchange上。只不过死信队列的RoutingKey和Exchange要作为参数，绑定到正常的队列上。
2. 死信消息：
- （1）消息被拒绝（Basic.Reject或Basic.Nack）并且设置 requeue 参数的值为 false
- （2）消息过期了
- （3）队列达到最大的长度
3. 过期消息：
在 rabbitmq 中存在2种方法可设置消息的过期时间:
- 第一种通过对队列进行设置，这种设置后，该队列中所有的消息都存在相同的过期时间;
- 第二种通过对消息本身进行设置，那么每条消息的过期时间都不一样。
如果同时使用这2种方法，那么以过期时间小的那个数值为准。当消息达到过期时间还没有被消费，那么那个消息就成为了一个 死信 消息。
- （1）队列设置：在队列申明的时候使用** x-message-ttl **参数，单位为 毫秒；
- 队列中这个属性的设置要在第一次声明队列的时候设置才有效，如果队列一开始已存在且没有这个属性，则要删掉队列再重新声明才可以。
- 队列的 ttl 只能被设置为某个固定的值，一旦设置后则不能更改，否则会抛出异常。
- （2）单个消息设置：是设置消息属性的 expiration 参数的值，单位为 毫秒。
说明：
对于第一种设置队列属性的方法，一旦消息过期，就会从队列中抹去；而在第二种方法中，即使消息过期，也不会马上从队列中抹去，因为每条消息是否过期是在即将投递到消费者之前判定的。
为什么这两种方法处理的方式不一样?
因为第一种方法里，队列中己过期的消息肯定在队列头部，RabbitMQ只要定期从队头开始扫描是否有过期的消息即可。而第二种方法里，每条消息的过期时间不同，如果要删除所有过期消息势必要扫描整个队列，所以不如等到此消息即将被消费时再判定是否过期,如果过期再进行删除即可。这样只判断队列头是否过期的方法的优势是，不用时刻扫描整个队列的所有消息去判断哪个过期，这样会非常耗资源。
另外，还需要注意的一点是，如果不设置TTL，表示消息永远不会过期，如果将TTL设置为0，则表示除非此时可以直接投递该消息到消费者，否则该消息将会被丢弃。
4. 延时队列
延时队列，顾名思义，不是及时的队列，也就是发送者发出的消息要延迟一段时间，消费者才能接受到。有一个很典型的应用场景就是订单30分钟内未支付就关闭订单，还有一种场景，账单24小时未确认，就发送提醒消息。
在rabbitmq中是不存在延时队列，如果需要使用的话，就需要安装延时队列插件。另外，我们也可以通过过期队列消息和死信队列来模拟出延时队列。消费者监听死信交换器绑定的队列，而不要监听消息发送的队列，就可以模拟出延时队列了。
使用延时队列插件，可以参考文章
（https://www.cnblogs.com/geekdc/p/13550620.html），使用过期队列消息和死信队列模拟延时队列，实现流程如下图，具体代码实现可自行搜索，这个资料也比较多。
使用过期消息和死信队列模拟延时队列
通过过期消息和死信队列来模拟出延时队列：
前面讲了过期消息有两种实现方法，第一种是通过对队列进行设置，第二种是通过对消息本身进行设置。
第一种方法通过队列设置，需要在队列声明的时候设置才有效。而如果使用这种方法，那么每增加一个新的时间需求，就要增加一个队列，显然这种方法不够灵活。
既然第一种方法不够灵活，那么咱通过第二种方法就可以实现灵活性。然而事情并没有那么简单，因为前面已经讲了，如果使用在消息属性上设置TTL的方式，消息可能并不会按时“死亡“，因为RabbitMQ只会检查队列头部的消息是否过期，如果过期则丢到死信队列，所以如果队列中第一个消息的延时时长很长，而第二个消息的延时时长很短，则第二个消息并不会优先得到执行。
所以总结一下，可以看得出来，通过过期消息和死信队列虽然可以模拟延时队列，并无法达到一个灵活通用的延迟队列。
