RabbitMQ如何防止消息丢失及重复消费

一、消息如何丢失：

1.1、生产者没有成功把消息发送到MQ：

丢失原因 ：因为网络传输的不稳定性，当生产者在向MQ发送消息的过程中，MQ没有成功接收到消息，但是生产者却以为MQ成功接收到了消息，不会再次重复发送该消息，从而导致消息的丢失。

解决办法 ： 有两个解决办法：事务机制和confirm机制，最常用的是confirm机制（发布确认机制）。

注意：RabbitMQ的事务机制是同步的，很耗型能，会降低RabbitMQ的吞吐量。confirm机制是异步的，生成者发送完一个消息之后，不需要等待RabbitMQ的回调，就可以发送下一个消息，当RabbitMQ成功接收到消息之后会自动异步的回调生产者的一个接口返回成功与否的消息。

confirm（发布确认）机制

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

1.2、RabbitMQ接收到消息之后丢失了消息

丢失的原因 ：RabbitMQ接收到生产者发送过来的消息，是存在内存中的，如果没有被消费完，此时RabbitMQ宕机了，那么再次启动的时候，原来内存中的那些消息都丢失了。

解决办法 ：开启RabbitMQ的持久化。当生产者把消息成功写入RabbitMQ之后，RabbitMQ就把消息持久化到磁盘。结合上面的说到的confirm机制，如果开启了消息的持久化，只有当消息成功持久化磁盘之后，才会回调生产者的接口返回ack消息，否则都算失败 。存入磁盘的消息不会丢失，就算RabbitMQ挂掉了，重启之后，他会读取磁盘中的消息，不会导致消息的丢失。

1.3、消费者弄丢了消息

丢失的原因 ：如果RabbitMQ成功的把消息发送给了消费者，那么RabbitMQ的ack机制会自动的返回成功，表明发送消息成功，下次就不会发送这个消息。但如果就在此时，消费者还没处理完该消息，然后宕机了，那么这个消息就丢失了。

解决的办法 ：简单来说，就是必须关闭 RabbitMQ 的自动 ack，采用手动ack （消息应答机制）。这样的话，如果你还没处理完，不就没有 ack了！ 那 RabbitMQ 就认为你还没处理完，这个时候 RabbitMQ 会把这个消费分配给别的 consumer 去处理，消息是不会丢的。RabbitMQ消息丢失之后的处理：消息自动重新入队。

消息应答机制 ： 为了保证消息在消费过程中不丢失，rabbitmq 引入消息应答机制，消息应答就是：消费者在接收到消息并且处理该消息之后，告诉 rabbitmq 它已经处理了，rabbitmq 可以把该消息删除了。

消息应答机制，分为两种：自动应答、手动应答。

二、如何防止重复消费

幂等性
当消费者消费完消息之后，通常会发送一个ack应答确认信息给生产者，但是这中间有可能因为网络中断等原因，导致生产者未能收到确认消息，由此这条消息将会被 重复发送给其他消费者进行消费，实际上这条消息已经被消费过了，这就是重复消费的问题。

消息幂等性，其实就是保证同一个消息不被消费者重复消费两次。

消费者端实现幂等性，意味着消息永远不会消费多次，即使收到了多条一样的消息。通常有两种方式来避免消费重复消费：
方式1: 消息全局 ID 或者写个唯一标识(如时间戳、UUID 等) ：每次消费消息之前根据消息 id 去判断该消息是否已消费过，如果已经消费过，则不处理这条消息，否则正常消费消息，并且进行入库操作。(消息全局 ID 作为数据库表的主键，防止重复)

方式2: 利用 Redis 的 setnx 命令：给消息分配一个全局 ID，消费该消息时，先去 Redis 中查询有没消费记录，无则以键值对形式写入 Redis ，有则不消费该消息。

参考文献