为什么要引入死信队列?
在监听消息消费失败的时候,现在系统的做法都是重推回队列,但是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时间之后,又会转发回原补偿队列,如此便完成了消息的闭环,而且消费频率由原来的毫秒级到现在的秒级,消费频率降低了几千几万倍。