在说死信队列之前，我们先介绍下为什么需要用死信队列。
如果想直接了解死信对接，直接跳入下文的"死信队列"部分即可。
ack机制和requeue-rejected属性我们还是基于上篇《Spring Boot系列——7步集成RabbitMQ》的demo代码来说。
在项目springboot-demo我们看到application.yaml文件部分配置内容如下
... listener: type: simple simple: acknowledge-mode: auto concurrency: 5 default-requeue-rejected: true max-concurrency: 100 ...其中
acknowledge-mode
该配置项是用来表示消息确认方式，其有三种配置方式，分别是none、manual和auto。
none意味着没有任何的应答会被发送。
manual意味着监听者必须通过调用Channel.basicAck()来告知所有的消息。
auto意味着容器会自动应答，除非MessageListener抛出异常，这是默认配置方式。
default-requeue-rejected
该配置项是决定由于监听器抛出异常而拒绝的消息是否被重新放回队列。默认值为true。
我一开始对于这个属性有个误解，我以为rejected是表示拒绝，所以将requeue-rejected连起来是拒绝重新放回队列，后来查了资料明白这个属性的功能才想起来rejected是个形容词，其表示的应该是被拒绝的消息
所以如果该属性配置为true表示会重新放回队列，如果配置为false表示不会放回队列。
下面我们看看acknowledge-mode参数和default-requeue-rejected参数使用不同的组合方式，RabbitMQ是如何处理消息的。
代码依然使用springboot-demo中的RabbitApplicationTests发送消息，使用Receiver类监听demo-queue队列的消息。
对于Receiver类添加了一行代码，该代码模拟抛出异常
@Component public class Receiver { @RabbitListener(queues = "demo_queue") public void created(String message) { System.out.println("orignal message: " + message); int i = 1/0; } }acknowledge-mode=none, default-requeue-rejected=false
该配置不会确认消息是否正常消费，所以在控制台没有抛出任何异常。通过在RabbitMQ管理页面也没有看到重新放回队列的消息
acknowledge-mode=none, default-requeue-rejected=true
同样该配置不会确认消息是否正常消费，所以在控制台没有抛出任何异常。而且即使default-requeue-rejected配置为true因为没有确认所以也没有看到重新放回队列的消息
acknowledge-mode=manual, default-requeue-rejected=false
该配置需要手动确认消息是否正常消费，但是代码中并没有手动确认，个人理解是因为没有收到ack，所以消息又回到了队列中。
acknowledge-mode=manual, default-requeue-rejected=true
该配置需要手动确认消息是否正常消费，但是代码中并没有手动确认，所以消息被重新放入到队列中了，并且在控制台发现还抛出了异常（这块不是很清楚，default-requeue-rejected设置true和false带来的不同效果，有了解的麻烦下方留言指教）。
acknowledge-mode=auto, default-requeue-rejected=false
该配置采用自动确认，从结果来看，是自动确认了。
从控制台打印的结果可以看出Receiver方法执行了3次，分别是前面两条放回队列的消息以及这次发送的消息，所以3条消息都消费了。
同时因为default-requeue-rejected设置为false，所以即使消费抛出异常，也没有将消息放回队列。
acknowledge-mode=auto, default-requeue-rejected=true
该配置同样采用自动确认，从结果看出，没有抛出异常（这块也不是很理解），且因为default-requeue-rejected设置为true，所以消息重新回到队列。