延迟队列
在我们的上一篇文章使用delayedQueue实现你本地的延迟队列
中提到了延迟队列的作用.
但是我们知道,利用delayedQueue实现的是一个单机的,而且是内存中的延迟队列,他并没有一个集群的支持,并且需要在对泵机的时候,消息消费异常的时候做相应的逻辑处理。
那么这样做的话,我们需要的工作量还是很大的,有没有什么东西是让我们不做这一部分的工作也能实现延迟队列的功能?
当然有了。答案是:rabbitMq
利用rabbitMq来实现延迟队列的功能
那么如何利用rabbitMq来实现延迟队列的功能呢?
请先注意一点,RabbitMQ本身没有直接支持延迟队列功能,但是可以通过以下特性模拟出延迟队列的功能。那么这是通过哪些特性呢,那就让我们来认识一下这两个特性吧.
Per-Queue Message TTL
RabbitMQ可以对消息和队列设置TTL(过期时间)。
RabbitMQ针对队列中的消息过期时间(Time To Live, TTL)有两种方法可以设置。第一种方法是通过队列属性设置,队列中所有消息都有相同的过期时间。第二种方法是对消息进行单独设置,每条消息TTL可以不同。如果上述两种方法同时使用,则消息的过期时间以两者之间TTL较小的那个数值为准。消息在队列的生存时间一旦超过设置的TTL值,就成为dead message,消费者将无法再收到该消息。
Dead Letter Exchanges
利用DLX,当消息在一个队列中变成死信后,它能被重新publish到另一个Exchange,这个Exchange就是DLX。消息变成死信一向有以下几种情况:
- 消息被拒绝(basic.reject or basic.nack)并且requeue=false
- 消息TTL过期
- 队列达到最大长度
DLX也是一下正常的Exchange同一般的Exchange没有区别,它能在任何的队列上被指定,实际上就是设置某个队列的属性,当这个队列中有死信时,RabbitMQ就会自动的将这个消息重新发布到设置的Exchange中去,进而被路由到另一个队列,publish可以监听这个队列中消息做相应的处理,这个特性可以弥补RabbitMQ 3.0.0以前支持的immediate参数中的向publish确认的功能。
结合以上两个特性,就可以模拟出延迟消息的功能.
基于x-dead-letter-routing-key的单条消息延迟队列的java代码实现
生产者(发送)端代码: