RabbitMq对消息丢失的处理方案

RabbitMQ生产者消息丢失场景:

生产者消息丢失,写消息的过程中,消息没到rabbitmq在网络传输过程中就丢失;或者是消息到了rabbitmq,但是mq内部出错,目前没有保存消息.

生产者消息丢失解决方案:

1.通过事务机制（不推荐，同步操作，会阻塞，效率低下）

2.confirm机制（异步确认方式）

如果你要确保说写rabbitmq的消息别丢，可以开启confirm模式，在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq中，rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了。如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。

事务机制和cnofirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是confirm机制是异步的，你发送个消息之后就可以发送下一个消息，然后那个消息rabbitmq接收了之后会异步回调你一个接口通知你这个消息接收到了。

RabbitMQ消息丢失场景:

rabbitmq接受到消息,缓存到内存中,还没被消费,此时rabbitmq挂了,存到内存中的数据丢失.

RabbitMQ消息丢失解决方案:

第一步:设置创建queue设置为持久化(只会持久化queue元数据,但不会持久化queue中的数据);

第二步:发送消息时,设置deliveryMode设置为2(此时queue中的数据也将被持久化);

第三步:配合confirm机制使用（推荐使用异步监听机制，不推荐事务机制）,当消息被持久化后才通知生产者ack;

RabbitMQ消费者丢失数据场景:

消费者接收到消息,但是还没操作,消费者自己挂了,但是rabbitmq以为该条消息已经被消费.

消费者丢失数据解决方案:

将autoAck关闭,在处理完消息后再手动提交ack;

 

我们知道，如果要保证消息的可靠性，需要对消息进行持久化处理，然而消息持久化除了需要代码的设置之外，还有一个重要步骤是至关重要的，那就是保证你的消息顺利进入Broker（代理服务器），如图所示： 

正常情况下，如果消息经过交换器进入队列就可以完成消息的持久化，但如果消息在没有到达broker之前出现意外，那就造成消息丢失，有没有办法可以解决这个问题？ 

RabbitMQ有两种方式来解决这个问题：

1. 通过AMQP提供的事务机制实现；
2. 使用发送者确认模式实现；（推荐使用，速度要比使用事务快10倍）

一、事务使用（