文章内容是学习过程中的知识总结,如有纰漏,欢迎指正
文章目录
一、什么是死信队列?
二、死信队列使用场景
三、死信队列如何使用
四、打车超时处理
1.打车超时实现
以下是本篇文章正文内容
一、什么是死信队列?
先从概念解释上搞清楚这个定义,死信,顾名思义就是无法被消费的消息,字面意思可以这样理解
一般来说,producer将消息投递到broker或者直接到queue里了,consumer从queue取出消息进行消费,但某些时候由于特定的原因导致queue中的某些消息无法被消费,这样的消息如果没有后续的处理,就变成了死信,有死信,自然就有了死信队列;
二、死信队列使用场景
RabbitMQ中的死信交换器(dead letter exchange)可以接收下面三种场景中的消息:
- 消费者对消息使用了
basicReject
或者basicNack
回复,并且requeue
参数设置为false
,即不再将该消息重新在消费者间进行投递 - 消息在队列中超时,RabbitMQ可以在单个消息或者队列中设置
TTL
(最大存活时间)属性 - 队列中的消息已经超过其设置的最大消息个数
三、死信队列如何使用
死信交换器不是默认的设置,这里是被投递消息被拒绝后的一个可选行为,是在创建队列的时进行声明的,往往用在对问题消息的诊断上。
死信交换器仍然只是一个普通的交换器,创建时并没有特别要求和操作,在创建队列的时候,声明该交换器将用作保存被拒绝的消息即可,相关的参数是x-dead-letter-exchange
。
相关代码
@Bean
public Queue taxiOverQueue() {Map<String, Object> args = new HashMap<>(2);// x-dead-letter-exchange 这里声明当前队列绑定的死信交换机args.put("x-dead-letter-exchange", TAXI_DEAD_QUEUE_EXCHANGE);// x-dead-letter-routing-key 这里声明当前队列的死信路由keyargs.put("x-dead-letter-routing-key", TAXI_DEAD_KEY);return QueueBuilder.durable(TAXI_OVER_QUEUE).withArguments(args).build();
}
四、打车超时处理
用户通过调用打车服务将数据放进RabbitMQ的死信队列进行延时操作,等待一段时间后,正常的业务处理还没有处理到我们发起的数据,将会进行超时处理,通过通知服务将我们的处理结构通过websocket方式推送到我们的客户端。
1.打车超时实现
在创建队列的时候配置死信交换器并设置队列的“x-message-ttl”属性。此时该属性为整个队列消息的生存时间,这里有一篇专门讲延时任务的文章。RabbitMQ(高阶使用)延时任务-CSDN博客
@Bean
public Queue taxiDeadQueue() {return new Queue(TAXI_DEAD_QUEUE,true);
}@Bean
public Queue taxiOverQueue() {Map<String, Object> args = new HashMap<>(2);// x-dead-letter-exchange 这里声明当前队列绑定的死信交换机args.put("x-dead-letter-exchange", TAXI_DEAD_QUEUE_EXCHANGE);// x-dead-letter-routing-key 这里声明当前队列的死信路由keyargs.put("x-dead-letter-routing-key", TAXI_DEAD_KEY);// x-message-ttl 声明队列的TTLargs.put("x-message-ttl", 30000);return QueueBuilder.durable(TAXI_OVER_QUEUE).withArguments(args).build();
}
这样所有被投递到该队列的消息都最多不会存活超过30s,超时后的消息会被投递到死信交换器