RabbitMQ学习（八）：死信队列

一、死信队列概述

死信，顾名思义就是无法被消费的消息，一般来说，producer 将消息投递到 broker 或者直接到 queue 里了，consumer 从 queue 取出消息 进行消费，但某些时候由于特定的原因导致 queue 中的某些消息无法被消费，这样的消息如果没有 后续的处理，就变成了死信。

有死信自然也有死信队列。

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

二、死信的原因

• 消息 TTL 过期

• 队列达到最大长度(队列满了，无法再添加数据)

• 消息被拒绝(basic.reject 或 basic.nack)并且 requeue=false

三、死信实战（TTL过期）

代码架构图：

正常情况下，消息会进入普通队列，由C1消费；而当成为死信之后，会进入死信队列，由C2消费。

生产者核心代码：

//声明普通交换机
channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT);
//设置消息的 TTL 时间
AMQP.BasicProperties properties = 
    new AMQP.BasicProperties().builder().expiration("10000").build();

for (int i = 1; i <11 ; i++) {
    String message="info"+i;
    channel.basicPublish(NORMAL_EXCHANGE, "zhangsan", properties, message.getBytes());
}

消费者C1核心代码：

//声明死信和普通交换机 类型为 direct
channel.exchangeDeclare(NORMAL_EXCHANGE, BuiltinExchangeType.DIRECT);
channel.exchangeDeclare(DEAD_EXCHANGE, BuiltinExchangeType.DIRECT);
//声明死信队列
channel.queueDeclare("dead-queue", false, false, false, null);
//死信队列绑定死信交换机与 routingkey
channel.queueBind(deadQueue, DEAD_EXCHANGE, "lisi");

//正常队列绑定死信队列信息
Map params = new HashMap<>();
//正常队列设置死信交换机 参数 key 是固定值
params.put("x-dead-letter-exchange", DEAD_EXCHANGE);
//正常队列设置死信 routing-key 参数 key 是固定值
params.put("x-dead-letter-routing-key", "lisi");
channel.queueDeclare("normal-queue", false, false, false, params);
channel.queueBind("normal-queue", NORMAL_EXCHANGE, "zhangsan");

DeliverCallback deliverCallback = (consumerTag, delivery) -> {
    String message = new String(delivery.getBody(), "UTF-8");
};
channel.basicConsume(normalQueue, true, deliverCallback, consumerTag -> {});

消费者C2核心代码：

//声明死信队列
channel.exchangeDeclare(DEAD_EXCHANGE, BuiltinExchangeType.DIRECT);
channel.queueDeclare("dead-queue", false, false, false, null);
channel.queueBind(deadQueue, DEAD_EXCHANGE, "lisi");

DeliverCallback deliverCallback = (consumerTag, delivery) -> {
    String message = new String(delivery.getBody(), "UTF-8");
};
channel.basicConsume(deadQueue, true, deliverCallback, consumerTag -> {});

代码略微改动即可模拟其他两个原因下的死信。