使用RabbitMQ处理死信队列

DLX，全称为Dead-Letter-Exchange，死信交换器。消息在一个队列中变成死信（Dead Letter）之后，被重新发送到一个特殊的交换器（DLX）中，同时，绑定DLX的队列就称为“死信队列”。

在定义业务队列时可以考虑指定一个 死信交换机，并绑定一个死信队列。当消息变成死信时，该消息就会被发送到该死信队列上，这样方便我们查看消息失败的原因。

以下几种情况导致消息变为死信：

对于RabbitMQ 来说，DLX 是一个非常有用的特性。它可以处理异常情况下，消息不能够被消费者正确消费(消费者调用了Basic.Nack 或者Basic.Reject)而被置入死信队列中的情况，后续分析程序可以通过消费这个死信队列中的内容来分析当时所遇到的异常情况，进而可以改善和优化系统。

pom.xml添加依赖

application.properties配置RabbitMQ连接信息

启动类实现

RabbitConfig类实现

GoController类实现

进入死信队列的场景：

运行 main 函数，推送消息给 TestDLXQueue 队列。可以先看到消息先在 TestDLXQueue 队列中。

等到30秒后没有被消费，则会把消息推送到 DLXQueue 死信队列中。

主要过程：

生产者 —>原交换机 amq.direct —>原队列 TestDLXQueue (超过 TTL 之后) —>死信交换机 DLXExchange —>死信队列 DLXQueue —>最终消费者。

创建死信队列 DLX_QUEUE 并和指定交换机 DLX_EXCHANGE 进行绑定（其实也是普通的队列、普通的交换机）。

创建另外一个正常的消息队列 TEST_DLX_QUEUE ，设置队列的 TTL 过期时间，同时通过 x-dead-letter-exchange 属性指定死信队列对应的交换机。

等到30秒后没有被消费，则会把消息推送到 DLX_QUEUE 死信队列中。

所以在 RabbitMQ 3.5.8版本之后，可以利用官方的 rabbitmq-delayed-message-exchange 插件来实现消息的延迟发送，可以避免上面所说的问题。

RabbitMQ实现消息延迟推送

Dead-Letter-Exchange 

利用DLX, 当消息在一个队列中变成死信(dead message)之后, 它能被重新publish到另一个Exchange, 这个Exchange就是DLX 

DLX也是一个正常的Exchange, 和一般的Exchange没有区别, 它能在任何队列上被指定, 实际上就是设置某个队列的属性为死信队列 

当这个队列中有死信时, RabbitMQ就会自动将这个消息重新发布到设置的Exchange上去, 进而被路由到另一个队列 可以监听这个队列中消息做相应的处理, 这个特性可以弥补RabbitMQ3.0以前支持的immediate参数的功能 

消息被拒绝 (basic.reject or basic.nack) 且带 requeue=false 参数

消息的TTL-存活时间已经过期

队列长度限制被超越（队列满）

首先要设置死信队列的exchange和queue, 然后进行绑定

    1. Exchange : dlx.exchange 

    2. Queue : dlx.queue

    3. RoutingKey : #

然后正常声明交换机, 队列, 绑定, 只不过需要在队列加上一个扩展参数即可 : arguments.put(“x-dead-letter-exchange”, “dlx.exchange”)

1. 列信息因消费不及时大量积压，消费方服务先处理不及时会影响到队列的生产者，进而会影响到所有消费此topic的队列

2. 队列的消息超时后消失，生产者和消费者完全无感知，只能靠查落地存储的历史记录，很不方便同时业务无法再消费处理

增加延时队列，通过dead-letter方式实现超过有效期后进入可以被消费的队列中，让消费者处理

计算倒计时，再放入延时队列让消费者处理

可接受队列，延时等待队列，死信队列分别加上特定的前缀

然后通过元注解参数来区分生产者发送的队列类型

在注解监听器监听参数，如果是延时队列发送给延时等待队列，普通队列发送给可接受队列

所有消费者统一消费可接受队列

---