RabbitMQ高级用法之死信队列

为什么要引入死信队列？

在监听消息消费失败的时候，现在系统的做法都是重推回队列，但是mq消息消费和重推再消费的时间几乎是没有延时的，那么如果有的消息是异常消息时，就会不断的消费→消费失败，推回队列→再消费，这个循环过程每秒可达几千次，如果不人工介入，会记录大量的log，有炸磁盘的风险，并且有的消息处理会牵涉到数据库表的操作，那么也会白白浪费过多的I/O资源。

消息变为死信的几种情况

• 消息被拒绝（basic.rejec/basic.nack）且requeue=false，channel.basicNack(envelope.getDeliveryTag(), false, false)
• 消息TTL过期
• 队列达到最长长度

死信队列的应用

额外提供两个队列，死信队列和补偿队列

• 原队列的监听在消费失败的时候不再做requeue操作，直接ack并且将错误消息转存到自己的补偿队列中
• 补偿队列设置死信交换机，如果消费失败，则转发到对应的死信队列中，补偿队列的死信队列设置如下：

x-dead-letter-exchange:	bs_common_dlx_exchange （通用的死信交换机）
x-dead-letter-routing-key:	bs_dlx_supplier_queue（rountingKey）

在补偿队列消费失败时，将消息直接nack掉，此时满足条件会消息会转发到死信队列中
死信队列设置如下,这样死信队列和补偿队列就会互为死信队列

x-dead-letter-exchange:	bs_common_recompense_exchange（补偿交换机）
x-dead-letter-routing-key:	bs_supplier_recompense_queue（rountingKey）
x-message-ttl:	30000（消息过期时间，若设置了此时间，消息在队列中达到ttl，如果设置了死信队列，则会转发消息至死信队列）

补偿队列设置了死信队列，补偿队列消费失败时。nack掉消息，消息会进入死信队列，而死信队列又设置了死信队列为原补偿队列，消息在死信队列中度过TTL时间之后，又会转发回原补偿队列，如此便完成了消息的闭环，而且消费频率由原来的毫秒级到现在的秒级，消费频率降低了几千几万倍。