死信队列与延迟队列区别与问题优化

延时队列

延时队列.队列内部是有序的,最重要的特性就体现在它的延时属性上,延时队列中的元素是希望在指定时间到了以后或之前取出和处理,简单来说, 延时队列就是用来存放需要在指定时间被处理的元素的队列, 延时队列其实就是特殊的死信队列

基于死信队列存在的问题:

如果在消息属性上设置TTL的方式,消息可能并不会按时"死亡",因为RabbitMQ只会检查第一个消息是否过期,如果过期则丢到死信队列,如果第一个消息的延时时长很长, 而第二个消息的延时时长很短,第二个消息并不会优先得到执行,而是在第一个消息过期后才会执行

死信队列应用场景

为保证订单业务消息数据不丢失,需要使用到RabbitMQ的死信队列机制,当消息消费发生异常时,将消息投入死信队列中,还比如说:用户在商城下单成功并点击去支付后在指定时间内未支付时自动失效

特点

由于某些特定的原因导致queue中的某些消息无法被消费

死信的来源

消息TTL过期
队列达到最大长度
消息被拒绝(basic.reject或basic.nack)并且requeue-false

死信的设置

 //正常队列设置死信交换机
        arguments.put("x-dead-letter-exchange",DEAD_EXCHANGE);
        //设置死信Routingkey
        arguments.put("x-dead-letter-routing-key","lisi");
		//设置正常队列的长度限制
        arguments.put("x-max-length",6);
        
   

一般死信的过期时间不在消费者处设置, 而是在生产者处设置,这样不至于把过期时间写死, 便于更灵活的把控时间

死信队列中存在问题的解决方案

基于插件的延迟队列方式可以很好的解决死信队列中每次只会监测第一个消息的过期时间, 基于插件的延迟队列不会受先后顺序影响,而只受其延迟时间影响, 延迟时间短的 , 便会先发送出去
方案的实现流程
与死信队列中需要声明两个队列 两个交换机不同的是 通过基于插件的延迟队列, 只需声明一个普通队列 一个延迟消息类型交换机即可

上面这个延迟消息类型通过在linux中开启延迟插件后才会显示, 然后就可以在代码中进行交换机的声明定义,
通过一个生产者, 一个延迟消息交换机, 一个普通队列, 一个消费者, 即可实现延迟队列的效果, 且弥补了死信队列中遗留的问题

总结

延时队列在需要延时处理的情景下非常有用,使用RabbitMQ来实现延时队列可以很好的利用RabbitMQ的特性,如:消息可靠发送,消息可靠投递,死信队列来保障消息至少被消费一次以及未被正常处理的消息不会被丢弃,另外 通过RabbitMQ集群的特性, 可以很好的解决单点故障问题, 不会因为某个节点挂掉导致延时队列不可用或者消息丢失, 总的来说,死信队列只是在作为延时队列的时候存在一些小问题,但在其他方面的使用是非常完美的
当然, 延时队列还有很多其他选择, 如利用java的DelayQueue, 利用Redisdzset,利用quartz或者利用kafka的时间轮, 都各有特点, 看需要适用的场景