HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
幂等性，通俗的说就是一个接口，多次发起同一个请求，必须保证返回结果必须准确，比如订单接口，不能多次创建订单，支付宝回调接口可能会多次回调，你要保证你的业务处理准确且操作只能执行一次。
在分布式场景中，假如你的某个服务部署了5台机器，前端请求调用，因为某些原因可能重复请求了俩次，因为负载均衡算法落到了俩台机器上，可能会导致重复的业务处理逻辑；又比如说 在使用微服务组件，例如zuul,feign等 在超时的情况下会有重试机制，也可能会导致重试请求多次，如果业务方没有做好幂等性，就会导致业务处理出错，比如多次创建订单，多次扣款，这些坑都会导致很严重的问题。
那么怎么保证幂等性呢，保证幂等性主要就是要保证每一次请求都必须要有一个唯一的标识，比如订单id，比如支付流水号，或者前端请求可以生成一个唯一的随机串，都可以作为唯一标识，对于第一次请求的时候，就必须要将唯一标识存放到数据库MySQL或者redis等存储中。后端服务收到请求，在进行业务处理之前，必须要先检查这个唯一标识是否存在，如果存在，就可以判定已经此次请求已经处理过，不需要进行重复处理。
在实际开发中保证接口幂等性主要有以下几个方案,可供参考。
（1） 对于要操作的数据，在表中建立唯一索引字段。特别适用于进行一些新增数据，插入操作，比如创建订单，在MySQL业务表中建立唯一索引字段，当请求过来的时候，如果是多次重试，就违反了表中索引字段的唯一性，就会报错，业务自然会回滚。
（2） 还是基于MySQL数据库，在业务表中增加版本号字段，调用方每次请求数据的时候可以先获取version版本号，然后多传入一个version版本号字段，业务方在处理请求的时候，会去查新数据库中的version版本号，判断一下俩个version的值是否相同，如果version不相同，说明本次请求已经处理过了，直接返回。
（3） 基于业务状态进行判断，设计接口的时候，对于每一个业务操作能否操作，设置可以执行的状态，比如使用状态机模式，便于检查业务对象的状态，接受到请求要进行一些业务处理时，可以先行判断业务对象的状态，是否满足执行操作的条件，如果当前操作已经执行过了，那么状态就会发生变化，也就不能进行当前操作，直接返回。
（4） 可以在外部存储中设置一个单独的去重表，比如使用redis，每次请求过来，生成唯一的key。重复请求过来的时候判断一下这个key是否存在，如果存在，说明存在重复调用，直接返回。
实现接口的幂等性 是业务接口方必须保证的基础功能，特别是服务与服务间的调用，可以使得服务接口在异常请求情况下，仍然保证接口的准确性，数据的准确性。
