RabbitMQ如何保证幂等性

幂等性是分布式系统设计中的一个重要概念，是在做系统或者接口设计时要着重考虑的问题，尤其像支付宝、银行、互联网金融等涉及钱的系统，既要高效，数据也要准确，绝对不能出现多扣款，多打款等问题，幂等性的设计就显得更为重要了。

本文我们就先来解释一下什么是幂等性？然后再看一下在MQ中怎么保证幂等性？

一、什么是幂等？

幂等性的实质是：对于一个资源，不管你请求一次还是请求多次，对该资源本身造成的影响应该是相同的，不能因为重复相同的请求而对该资源重复造成影响。注意关注的是请求操作对资源本身造成的影响，而不是请求资源返回的结果。

如select * from t_user where id>10这条语句，假如在一次查询后数据库进行了insert或update操作，那么第二次再查时返回的结果可能与第一次不同，但这个操作是符合幂等性的，因为我们说过关注的是对资源的影响，不是返回的结果，虽然两次查询的返回结果不同，但select不管执行多少次，对数据库中的数据资源本身都不会产生任何影响。

幂等性包括：

① 一次或多次请求，对资源均不会造成影响，比如select操作；

② 第一次请求对资源产生了影响，后面再发出多个相同的请求，与发出单个请求具有相同的效果，不能重复对资源产生影响。比如支付宝转账，手抖重复提交了2次，第一次扣款成功，余额减少100元，第二次就不能再重复扣款了。

③ 需要说明的是网络超时、服务宕机等问题，不是幂等的范围。

幂等性是系统服务对外的一种承诺。比如我写了一个接口，我承诺我的接口是符合幂等性的，就是说外部的多次调用对我系统造成的影响都是相同的，不会因为多次调用而对系统重复造成影响。这里需要说明的一点是，声明为幂等的服务会认为调用方调用失败是常态，并且允许在调用失败后重试。

二、RabbitMQ的幂等性

那我们回到RabbitMQ中，RabbitMQ中的幂等性又是什么意思呢？我们先来看看在RabbitMQ中，哪些情况可能导致非幂等？

① consumer接收到消息处理完成后，在给Broker返回ack途中网络中断，Broker未收到确认信息，根据RabbitMQ的重试补偿机制，则会把这条消息再重发给其他的消费者或等网络重连后再发送给该消费者，造成了消息的重复消费。

② 或者在开启生产者confirm模式下，生产者已经把消息发送到Broker，但在Broker回传ack确认时网络中断，生产者也会重新发送刚才的消息，造成Broker收到了重复的消息，最终将两条重复的消息发送到消费端，造成了消息的重复消费。

通过以上两种场景我们看出，其实MQ的幂等性保障应该在消费端，要保证MQ的幂等性，就要保证消费者不会重复消费相同的消息。

※ 如何避免消息的重复消费问题？

全局唯一ID + Redis

生产者在发送消息时，为每条消息设置一个全局唯一的messageId，消费者拿到消息后，使用setnx命令，将messageId作为key放到redis中：setnx(messageId,1)，若返回1，说明之前没有消费过，正常消费；若返回0，说明这条消息之前已消费过，抛弃。

※ setnx命令，若给定的key不存在，执行set操作，返回1，若给定的Key已存在，不做任何操作，返回0。