个人博客，欢迎访问：www.live4bug.com
RabbitMQ的死信队列
前言
思考：因为在开发项目时，RabbitMQ的消费端出现了异常（工具类操作文件时，未找到文件路径）。由于在此之前并未对该异常进行预判，导致异常出现后，消费端仍然对MQ的消息进行消费，但是出现异常后无法对MQ进行回复，所以造成后果消费端一直消费该条信息，进入死循环！
从而引发了自己的思考：1. 开发时难免会出现异常，这种异常如果事先未预判，那么在程序运行中，消费端该怎么避免以上出现的死循环；2. 如果事先预判到异常，对其进行了抛出或捕获，消费端又该如何表现？
带着这些问题，我查阅了很多资料...然后就发现了RabbitMQ的“死信”方案。不过好像对我的问题没什么用。但是新知识还是要学，不然怎么知道有用没用呢。
死信队列的概念
死信队列：DLX，dead-letter-exchange
场景：比如，当队列由于一些问题，导致队列中的某些消息过期、消息满载、消息被拒绝。也就是说，一些有问题的消息没有被正确“消费”时，可以借助死信队列，将这些“问题消息”传到死信交换机，再由死信交换机传到死信队列，最后由死信队列对应的消费者，消费这些“问题消息”。
-
死信的产生：
消息被拒绝(basic.reject / basic.nack)，并且requeue = false
消息TTL过期
队列达到最大长度
死信队列的配置
首先要明确，死信队列只是处理“特殊问题”的普通队列。也就是说，A交换机和a队列处理事务A，B交换机和b队列处理事务B...而死信队列的交换机和队列处理事务X，只不过这个X的任务就是去消费那些问题消息。
说到这里，其实也就没白了。死信队列和死信交换机的配置和普通的配置没有区别！
//声明死信交换机
@Bean("dead_exchange")
public Exchange dead_exchange(){
return ExchangeBuilder.topicExchange(DEAD_EXCHANGE).durable(true).build();
}
//声明死信队列
@Bean("dead_queue")
public Queue dead_routing_key(){
return QueueBuilder.durable("dead_queue").build();
}
//对上述进行绑定
@Bean("dead_bind")
public Binding dead_bind(@Qualifier("dead_queue")Queue queue,@Qualifier("dead_exchange")Exchange exchange){
return BindingBuilder.bind(queue).to(exchange).with("dev").noargs();
}
好了，有了“特殊工作者”死信队列，那还得有普通工作者啊。毕竟我们的主要业务都是那些普通工作者做的。
配置普通队列，注意，这里才是配置死信队列成功的关键！！！
@Bean("ex_media_processor")//普通交换机声明
public Exchange EX_MEDIA_VIDEOTASK() {
return ExchangeBuilder.directExchange("ex_media_processor").durable(true).build();
}
//声明队列
@Bean("queue_media_video_processtask")
public Queue QUEUE_PROCESSTASK() {
//注意，这里是死信队列配置成功的关键！！！
Map<String,Object> map = new HashMap<>();
//队列等待时间
map.put("x-message-ttl",5000);
//死信队列的交换机，dead_exchange对应的是死信交换机的名称
map.put("x-dead-letter-exchange","dead_exchange");
//死信队列的路由，dev是我自己取的路由key
map.put("x-dead-letter-routing-key","dev");
Queue queue = new Queue(queue_media_video_processtask,true,false,false,map);
return queue;
}
@Bean
public Binding binding_queue_media_processtask(@Qualifier("queue_media_video_processtask") Queue queue, @Qualifier("ex_media_processor") Exchange exchange) {
return BindingBuilder.bind(queue).to(exchange).with("routingkey_media_video").noargs();
}
定义生产者和消费者
这里由于是自己的项目，我也比较懒...大家就正常配一下就好了。生产者发送消息给普通的交换机"ex_media_processor",消费者绑定并监听普通的队列"queue_media_video_processtask"，此时不必理会死信队列的相关问题，正常操作就好。
死信队列演示
为了使生产者发送的消息变成死信，我们可以这么做：
-
先启动消费端，这时可以看见页面上，死信交换机、死信队列、普通队列都已经上线！
消费端启动-交换机.png第一个红色框是普通交换机，第二个是死信交换机。
消费端启动.png我们刚刚启动的两个队列，第一个是死信队列，第二个红框是普通队列；其中普通队列后标识的DLX代表死信交换机，DLK代表死信路由，也就是说，当前队列已经配置了相关属性。
-
关闭消费端，启动生产端，注意，配置队列和交换机时要配置成持久化的，autoDelete这种配置设成false，这样在关闭消费端时，这些对应的队列、交换机不会消失。
此时，交换机和队列没有任何变化。
-
生产端的生产者向普通交换机发送消息。此时，消息进入普通交换机，普通交换机根据路由分配给对应的普通队列。可是经过了一小段时间(设置的TTL)，该普通队列发现该消息已经过期，所以将该消息转发到死信交换机，死信交换机再根据消息的路由，转发到设定好的死信队列中。
死信队列演示-普通队列.png由上图可以看出，普通队列对于生产者发送的消息的“思考”：队列发现消息后，等待，等待一定时间后，发现该消息已经过期，普通队列决定扔掉它，往哪里扔呢，往曾经设置好的死信路由扔！
死信队列演示-死信队列.png由上图看出，死信队列收到了被扔过来的消息，所以出现了一个缓坡，代表收到。具体的，可以参照时间轴，在14：26：40时，普通队列扔，死信队列接，死信队列从1升成2。注，因为之前测试，所以死信队列里残存了一条历史消息。
至此，死信队列的演示已经完成。大家可以根据具体的业务要求，监听死信队列，对“死信”进行消费处理。所以到了这里，我发现对于我的问题，死信队列是有用的...
