一、死信队列概述
死信，顾名思义就是无法被消费的消息，一般来说，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<String, Object> 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 -> {});
代码略微改动即可模拟其他两个原因下的死信。
