RabbitMQ的消息消费是有确认机制的，正常情况下，消费者在消费消息成功后，会发送一个确认消息，消息队列接收到之后，就会将该消息从消息队列中删除，下次也就不会再投递了。

但是如果存在网络延迟的问题，导致确认消息没有发送到消息队列，导致消息重投了，是有肯呢个，所以当我们使用MQ的时候，消费者端自己也需要做好幂等控制来防止消息被重复消费。

那么问题来了，什么是幂等性？如何解决接口幂等的问题呢？

解决接口幂等问题，只需要记住一句口令“一锁、二判、三更新”，只要严格遵守这个过程，那么就可以解决并发问题。

一锁：第一步，先加锁。可以加分布式锁、或者悲观锁都可以。但是一定要是一个互斥锁！

二判：第二步，进行幂等性判断。可以基于状态机、流水表、唯一性索引等等进行重复操作的判断。

三更新：第三步，进行数据的更新，将数据进行持久化。

// 一锁：先加一个分布式锁
@DistributeLock(scene = "ORDER", keyExpression = "#request.identifier", expire = 3000)
public OrderResponse apply(OrderRequest request) {OrderResponse response = new OrderResponse();// 二判：判断请求是否执行成功过OrderDTO orderDTO = orderService.queryOrder(request.getProduct(), request.getIdentifier());if (orderDTO != null) {response.setSuccess(true);response.setResponseCode("DUPLICATED");return response;}// 三更新：执行更新的业务逻辑return orderService.order(request);
}

三步需要严格控制顺序，确保加锁成功后进行数据查询和判断，幂等性判断通过后再更新，更新结束后释放锁。

以上操作需要有一个前提，那就是第一步加锁和第二步判断的时候，需要有一个依据，这个就是幂等号了，通常需要和上游约定一个唯一 ID 作为幂等号。然后通过对幂等号加锁，再通过对幂等号进行幂等判断即可。

一锁这个过程，建议使用 Redis 实现分布式锁，因为他是非阻塞的高效率的互斥锁。非常适合在幂等控制场景中。

二判这个过程，如果有操作流水，建议基于操作流水做幂等，并将幂等号作为唯一性约束，确保唯一性。如果没有流水，那么基于状态机也是可以的。

但是不管怎么样，数据库的唯一性约束都要加好，这是系统的最后一道防线了。万一前面的锁失效了，这里也能控制得住不会产生脏数据。

最后也就是说，我们在发送消息是需要生成一个唯一的标识并且把它放到消息体中，根据这个标识就可以判断两次消息是不是同一条。这样我们在消费者端，接收到消息以后，只需要解析出消息体重的这个唯一标识，就可以通过“一锁、二判、三更新”的方式来判断是否消费成功过了。