WEB 资源或 API 方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。幂等性是系统的接口对外一种承诺(而不是实现), 承诺只要调用接口成功, 外部多次调用对系统的影响是一致的。幂等性是分布式系统设计中的一个重要概念，对超时处理、系统恢复等具有重要意义。声明为幂等的接口会认为外部调用失败是常态, 并且失败之后必然会有重试。例如，在因网络中断等原因导致请求方未能收到请求返回值的情况下，如果该资源具备幂等性，请求方只需要重新请求即可，而无需担心重复调用会产生错误。实际上，我们常用的 HTTP 协议的方法是具有幂等性语义要求的，比如：get 方法用于获取资源，不应有副作用，因此是幂等的；post 方法用于创建资源，每次请求都会产生新的资源，因此不具备幂等性；put 方法用于更新资源，是幂等的；delete 方法用于删除资源，也是幂等的。
常见用来保证幂等的手段：
1.MVCC 方案
多版本并发控制，该策略主要使用 update with condition（更新带条件来防止）来保证多次外部请求调用对系统的影响是一致的。在系统设计的过程中，合理的使用乐观锁，通过 version 或者 updateTime（timestamp）等其他条件，来做乐观锁的判断条件，这样保证更新操作即使在并发的情况下，也不会有太大的问题。例如
select * from tablename where condition=#condition# // 取出要跟新的对象，带有版本 versoin
update tableName set name=#name#,version=version+1 where version=#version#
在更新的过程中利用 version 来防止，其他操作对对象的并发更新，导致更新丢失。为了避免失败，通常需要一定的重试机制。
2.去重表
在插入数据的时候，插入去重表，利用数据库的唯一索引特性，保证唯一的逻辑。
3.悲观锁
select for update，整个执行过程中锁定该订单对应的记录。注意：这种在 DB 读大于写的情况下尽量少用。
4. select + insert
并发不高的后台系统，或者一些任务 JOB，为了支持幂等，支持重复执行，简单的处理方法是，先查询下一些关键数据，判断是否已经执行过，在进行业务处理，就可以了。注意：核心高并发流程不要用这种方法。
5.状态机幂等
在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。
6. token 机制，防止页面重复提交
业务要求：页面的数据只能被点击提交一次
发生原因：由于重复点击或者网络重发，或者 nginx 重发等情况会导致数据被重复提交
解决办法：
- 集群环境：采用 token 加 redis（redis 单线程的，处理需要排队）
- 单 JVM 环境：采用 token 加 redis 或 token 加 jvm 内存
处理流程：
- 数据提交前要向服务的申请 token，token 放到 redis 或 jvm 内存，token 有效时间
- 提交后后台校验 token，同时删除 token，生成新的 token 返回
token 特点:要申请，一次有效性，可以限流
7. 对外提供接口的 api 如何保证幂等
如银联提供的付款接口：需要接入商户提交付款请求时附带：source 来源，seq 序列号。source+seq 在数据库里面做唯一索引，防止多次付款，(并发时，只能处理一个请求)
总结： 幂等性应该是合格程序员的一个基因，在设计系统时，是首要考虑的问题，尤其是在像支付宝，银行，互联网金融公司等涉及的都是钱的系统，既要高效，数据也要准确，所以不能出现多扣款，多打款等问题，这样会很难处理，用户体验也不好 。
