幂等性

使用消息MQ的好处：

• 系统解耦
• 增加系统在高并发的稳定性

消息生产失败
一般来说，从生产者到MQ中间件是通过网络调用的，有可能因为各种网络原因导致失败
解决方式：简单重试，重试2-3次

MQ消息存储失败
MQ收到消息后，先存在到缓冲区中，再异步写入磁盘，如果机器在中途突然断电，是有可能会丢失消息的。
解决方式：采用分布式部署方式，消息在多个机器上写入成功才会返回消息生产成功，因为多个机器同时断电的可能性较低，所以这是一个兼顾成本与可靠性的方法。

消费者处理失败
消费也是通过网络调用，也有可能因为网络原因导致失败。例如MQ可能已经成功消费了，但是在通知MQ中间件的时候失败了，这个时候带来的结果就是消息重复消费。在生产者重试的时候，也会遇到消息重复消费的问题。
解决方式：接口设计成幂等性。

幂等性

• 一次（或多次）请求对资源没有副作用（比如查询数据库操作，没有增删改，因此没有对数据库有任何影响）。
• 第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。

什么时候需要接口需要设计幂等性

• 前端因操作抖动而造成重复提交情况
• 后台因为网络出错请求重发，如支付请求重发

幂等的不足

• 增加服务器的处理成本，所以除了业务上的特殊要求外，尽量不提供幂等的接口。

防重复提交策略

• 加乐观锁，为了防止ABA问题，加一个版本号比对，版本号自增。
• 防重表加锁，或加分布式锁，分布式锁会更为高效，因为在缓存中。
• token令牌方式，一个订单只会生成一个token令牌，根据一个令牌进行一次支付操作。
• 支付缓冲区，把支付的操作放到一个快速接单的缓冲管道中异步执行，过滤掉重复的待支付订单，但不能及时地返回支付结果。