Rabbit MQ 消息确认机制与死信队列应用

前言:

RabbitMQ中间件的引入对于整个系统来说是一把双刃剑，在对系统进行解耦的同时也降低了消息的可靠性，但是对于某些系统来说我们又必须保证我们的消息是不会丢失的，因此rabbitmq给提供了以下一些功能来保证消息的可靠性，本文我们主要讲解消息可靠性中的 发送端确认机制 以及 消费端确认机制。

1.发送端确认机制:

 

 

2.1 ConfirmCallback方法
ConfirmCallback 是一个回调接口，消息发送到 Broker 后触发回调，确认消息是否到达 Broker 服务器，也就是只确认是否正确到达 Exchange 中。

我们需要在生产者的配置中添加下面配置，表示开启发布者确认。

2.2 ReturnCallback方法
通过实现 ReturnCallback 接口，启动消息失败返回，此接口是在交换器路由不到队列时触发回调，该方法可以不使用，因为交换器和队列是在代码里绑定的，如果消息成功投递到 Broker 后几乎不存在绑定队列失败，除非你代码写错了。

使用此接口需要在生产者配置中加入一下配置，表示发布者返回。

 代码Compent类

2.消费端确认机制 

配置

Compent配置类

 

返回ACK. 消费失败重新入队.

死信队列使用

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

以上是个人的通俗解释，专业术语解释的比较正规点大家可以参考，主要想搞清楚这个概念，不同的消息中间件大概都有自身对于死信或者死信队列的处理方式，下面重点要说说。

消息变成死信有以下几种情况

消息被拒绝(basic.reject / basic.nack)，并且requeue = false
消息TTL过期
队列达到最大长度
死信的处理方式
死信的产生既然不可避免，那么就需要从实际的业务角度和场景出发，对这些死信进行后续的处理，常见的处理方式大致有下面几种，

丢弃，如果不是很重要，可以选择丢弃
记录死信入库，然后做后续的业务分析或处理
通过死信队列，由负责监听死信的应用程序进行处理
综合来看，更常用的做法是第三种，即通过死信队列，将产生的死信通过程序的配置路由到指定的死信队列，然后应用监听死信队列，对接收到的死信做后续的处理。

                         

演示死信队列处理，这里设定产生死信的场景是设置队列中的消息有效期为10s，超出时间未被消费者接收，就会自动添加到死信队列，消费者端监听死信队列，并进行业务处理。

代码演示

生产者端

生成两个交换机绑定不同的队列，正常队列与死信队列。普通队列的死信消息 路由的队列

普通队列simpleQueue的死信投递到死信交换机`dead-letter-exchange`后再投递到死信队列。

消费者端

普通队列直接拒收消息,并不进行重新入队

测试

 普通队列的消息被拒绝后转发到死信队列。