前言

RabbitMQ虽然有对队列及消息等的一些持久化设置，但其实光光只是这一个是不能够保障数据的可靠性的，下面我们提出这样的质疑：

（1）RabbitMQ生产者是不知道自己发布的消息是否已经正确达到服务器呢，如果中间发生网络异常等情况呢？消息必然会丢失！

（2）RabbitMQ如果没有设置队列持久化，RabbitMQ服务器重后队列的元数据会丢失，消息自然也会丢失！

（3）RabbitMQ如果消费者设置自动确认，即autoAck为true，那么不管消费者发生什么情况，该消息会自动从队列中移除，实际上消费者有可能挂掉，消息必然会丢失！

（4）RabbitMQ中的消息如果没有匹配到队列时，那么消息也会丢失！

一、设置mandotory参数、AE备份交换器

针对前言中的第（4）个问题，我们可以通过设置mandotory参数与AE备份交换器来解决

1、mandotory参数

1）当为true时，交换器无法根据自身的类型和路由键找到一个符合条件的队列，此时RabbitMQ会调用Basic.Return命令将消息返回给生产者，消息将不会丢失

2）当为false时，消息将会被直接丢弃。

3）RabbitMQ通过addReturnListener添加ReturnLisener监听器监听获取没有被正确路由到合适队列的消息。

channel.basicPublish(EXCHANGE NAME, "", true, MessageProperties.PERSISTENT_TEXT_PLAIN, "mandatory test".getBytes()); 
channel.addReturnListener(new ReturnListener(){ 
public void handleReturn(int replyCode, String replyText, 
String exchange, String routingKey, 
AMQP.BasicProperties basicProperties, 
byte[] body) throws IOException { 
String message = new String(body); 
System.out.println("Basic.Return 返回的结果是: " + message);
}
});

欢迎工作一到五年的Java工程师朋友们加入Java程序员开发： 854393687

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！

2、AE备份交换器

Alternate Exchange，简称AE，不设置mandatory参数，那么消息将会被丢失，设置mandatory参数的话，需要添加ReturnListner监听器，增加复杂代码，如果既不想增加代码又不想消息丢失，则使用AE，将没有被路由的消息存储于RabbitMQ中。当mandatory参数用AE一起使用时，mandatory将失效。在介绍AE之前，也认识RabbitMQ对于消息的过期时间TTL设置以及队列的过期时间TTL设置

2.1 TTL过期时间设置

可以对队列设置TTL与消息设置TTL，其中消息设置TTL经常用于死信队列、延迟队列等高级应用中。

1）设置消息TTL

　　设置TTL过期时间一般有两种当时：一是通过队列属性，对队列中所有消息设置相同的TTL。二就是对消息本身单独设置，每条消息TTL不同。如果一起使用时候，TTL小的为准，当一旦超过设置的TTL时间时，就会变成“死信”。

方式一：针对每条消息设置TTL是通过增加expiration的属性参数实现的，不可能像方式二一样扫描整个队列再判断是否过期，只有当该消息即将被消费时再判定是否过期即可删除，也就是消息即使已经过期，但不一定立马被删除！

AMQP.BasicProperties.Builder builder = new AMQP.BasicProperties.Builder(); 
// 持久化消息
builder deliveryMode(2);
// 设置 TTL=60000ms
builder expiration( 60000 ); 
AMQP.BasicProperties properties = builder. build(); 
channel.basicPublish(exchangeName, routingKey, mandatory, properties, "ttlTestMessage".getBytes());

方式二：通过队列属性设置消息TTL是增加x-message-ttl参数实现的，只需要扫描整个队列头部即可立即删除，也就是消息一旦过期就会被删除！

Map<String, Object> argss = new HashMap<String , Object>(); 
argss.put("x-message-ttl", 6000); 
channel.queueDeclare(queueName, durable, exclusive, autoDelete, argss) ;

2）设置队列TTL

通过在队列中添加参数x-message-ttl参数实现，设置队列被自动删除前处于未被使用状态的时间，注意是队列的使用状态，并不是消息是否被消费的状态

设置ttl=30min的队列，时间一到RabbitMQ会保证队列被删除，但是不会保证删除的速度有多快。

Map<String, Object> args = new HashMap<String, Object>{); 
args.put("x-expires", 1800000);
channel.queueDeclare("myqueue", false, false, false, args);

2.2 AE备份交换器的使用

声明交换器的时候，添加alternate-exchange参数实现，或通过策略实现。前者优先级高。从代码角度需要以下三个步骤，具体代码如下：

Map<String, Object> args = new HashMap<String, Object>(); 
args.put("a1ternate-exchange", "myAe"); 
channe1.exchangeDec1are("norma1Exchange", "direct", true, fa1se, args); 
channe1.exchangeDec1are("myAe", "fanout", true, fa1se, nu11) ; 
channe1.queueDec1are( "norma1Queue", true, fa1se, fa1se, nu11); 
channe1.queueB nd("norma1Queue", "norma1Exchange", "norma1Key"); 
channe1.queueDec1are("unroutedQueue", true, fa1se, fa1se, nu11);

1）声明normalExchange类型为direct的交换器、类型为fanout的myAe备份交换器；并且normalExchange的备份交换器为myAe（备份交换器建议使用fanout类型交换器）

2）声明normalQueue队列，声明unrouteQueue队列；

3）通过路由键normalKey绑定normalExchange与normalQueue，不适用路由键绑定unrouteQueue与myAe

二、消费者手动确认

针对前言中第（3）个问题，我们需要在消费者消费完消息后手动进行确认，保证消息数据不丢失！

1、autoAck参数设置

1） 当autoAck参数为false时，手动确认：

RabbitMQ会等待消费者显式地回复确认信号后从内存中移去消息（实际上是先标示删除标记，之后再删除），这是一般推荐使用的方式，因为使用手动确认有足够的时间处理消息，不需要担心消费者进程挂掉之后消息丢失问题。此时的消息就会分为两个部分：一是等待投递给消费者的消息；二是已经投递给消费者但还没有收到消费者确认信号的消息。

2） 当autoAck为true时，自动确认：

RabbitMQ会自动隐式地回复确认信号后从内存中移去消息， RabbitMQ不需要管消费者是否真正消费了这些消息，RabbitMQ会自动把发送出去的消息置为确认，然后直接从内存中删除。

2、重新投递

问：如果选择手动确认，即autoAck为false时，消费者由于某些原因断开了，那么消息的确认会受到影响，那么此时的消息会丢失吗？

这也就是一开始提出来的问题，其实是不必担心消息会被丢失，因为RabbitMQ如果一直没收到消费者的确认信号，并且消费此消息的消费者已经断开，则RabbitMQ会重新安排消息进入队列等待给下一个消费者。也就是RabbitMQ不会设置消息的过期时间（当然也可以设置过期时间，但与之有关系方式消息丢失的特性是死信队列），它只判断是否需要重新安排入队列重新投递，而判断的唯一标准是消费此消息的消费者连接是否已经断开，即RabbitMQ会允许消费一条消息的时间很久很久。

3、消费者拒绝消息

1）使用channel.basicReject方法，但只能拒绝一条。

void basicReject(long deliveryTag, boolean requeue) throws IOException;

deliveryTag：消息的唯一标识

requeue：表示是否可以拒绝的消息重新存入队列

　2）使用channel.basicNack。不同于前者，此方法可以批量拒绝。

void basicNack(long deliveryTag, boolean multiple , boolean requeue) throws IOException;

multiple：设置为true则表示拒绝deliveryTag编号之前所有未被当前消费者确认的消息。

3）问：关键在于，消费者拒绝消费消息后怎么处理？是丢弃，还是重新回到队列呢？

当参数requeue设置为true时候，可以重新进入队列，投递给下一个消费者。如果为false，消息就会把队列中消息立马移除，再结合启用“死信队列”，防止消息丢失并且可以分析异常情况的发生。

欢迎工作一到五年的Java工程师朋友们加入Java程序员开发： 854393687

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！