幂等性的概念
幂等（Idempotent）是一个数学与计算机学的概念，常见于抽象代数中。
f(n) = 1^n // 无论n等于多少，f(n)永远值等于1在编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法是指可以使用相同参数重复执行，并能获得相同结果的函数 / 方法。这些函数 / 方法不会影响系统状态，因此不用担心重复执行会对系统造成改变。
常见的场景：
1. 前端重复提交选中的数据，后台也只会产生对应这个数据的一个反应结果。
2. 用户发起一笔付款请求，就应该只扣用户一次钱，即使遇到网络重发或系统 bug 重发请求，也应该之扣一次钱。
3. 发送验证短息也应该只发一次，同样的验证短信不应该发送多次。
4. 创建业务订单，一个业务请求只能创建一个业务订单，创建多个就会出大问题。
其他场景：
- 网络波动, 可能会引起重复请求
- 用户重复操作,用户在操作时候可能会无意触发多次下单交易,甚至没有响应而有意触发多次交易
- 应用使用了失效或超时重试机制(Nginx重试、RPC重试或业务层重试等)
- 页面重复刷新
- 使用浏览器后退按钮重复之前的操作,导致重复提交表单
- 使用浏览器历史记录重复提交表单
- 浏览器重复的HTTP请求
- 定时任务重复执行
- 用户双击提交按钮
这些等等很多的业务逻辑都需要幂等的特性来支持。简单来理解就是，幂等就是一个操作，这个操作不管执行多少次，产生的效果和返回的结果都是一样的。比如说有一个 getOne () 函数，无论执行这个函数多少次，它返回的都是 1，这时就可以说它是一个幂等函数。
幂等性的技术方案
1. 查询操作
查询一次和查询多次，在数据不变的情况下，查询结果都是一样的，select 是天然的幂等操作。
2. 删除操作
删除操作也是幂等的，删除一次和删除多次都是把数据删除。
3. 建立唯一索引，防止新增脏数据（适合用于执行新增操作的接口）
当表存在唯一索引，并发时新增重复记录就会报错，那么这时候就查询已存在的记录并返回即可。
4.Token 机制，防止页面重复提交
页面数据只能够提交一次，但是由于出现重复点击或者网络重发或 Nginx 重发等情况导致数据被重复提交的情况下，可以采用 Token+Redis（Redis 是单线程的，处理需要排队）的解决方案。处理的流程是，在数据提交前要向服务器申请带有有效时间的 Token，然后 Token 放到 Redis 或 JVM 内存中，当数据正式提交到后台要校验 Token 并删除 Token。
（还有另外两种实现：
1.原理上通过session token来实现的(也可以通过redis来实现)。当客户端请求页面时，服务器会生成一个随机数Token，并且将Token放置到session当中，然后将Token发给客户端（一般通过构造hidden表单）。 下次客户端提交请求时，Token会随着表单一起提交到服务器端。
2.token机制【这种我觉得实现得复杂了有点，没有上面这种来的简单】
3.关于token的详细实现方式也可以参考：分布式系统中接口的幂等性
）
这里还存在一种session机制：在session存放特殊标志（和token机制有点类似）
在服务端,生成一个唯一的标识符,将它存入session,同时前端获取这个标识符的值将它写入表单的隐藏中,用于用户输入信息后点击一起提交,在服务器端,获取表单中隐藏字段的值,与session中的唯一标识符比较,相等说明是首次提交,就处理本次请求,然后将session中的唯一标识符移除,不相等则表示是重复提交,不再做处理。
5. 悲观锁
获取数据的时候加锁获取：
select * from table where id = 'xxx' for update;
要注意的是，id 字段一定要是主键或者唯一索引，否则会导致锁表。
悲观锁的使用一般伴随事务一起使用，数据锁定事件可能会很长，要根据实际情况慎用。
6. 乐观锁
乐观锁只是在更新数据的那一刻锁表，其他时间不锁表，所以相对于悲观锁效率更高。
乐观锁的实现方式多种多样，可以通过 version 或者其他状态条件。
（1.通过版本号实现update tablexxx set name=#name#,version=version+1 where version=#version#如下图(来自网上)；
2.通过条件限制 update tablexxx set avaiamount=avaiamount-#subAmount# where avai_amount-#subAmount# >= 0 要求：quality-#subQuality# >= ，这个情景适合不用版本号，只更新是做数据安全校验，适合库存模型，扣份额和回滚份额，性能更高；）
7. 分布式锁
还是拿插入数据的例子，如果是分布式系统，构建全局唯一索引比较困难，例如唯一性的字段无法确定。那么这时候就可以引入分布式锁，通过第三方的系统（Redis 或 Zookeeper），在业务系统插入数据或更新数据，获取分布式锁，然后做操作，之后再释放锁。这样其实是把多线程并发锁的思路引入了多个系统，也就是分布式系统中的解决思路。
要注意的是，某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志（用户 ID + 后缀等）获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁（分布式锁需要第三方系统提供)）。
注: 获取锁最好设置个超时时间,防止意外没有释放到锁
8.select+insert
对于一些并发不高的后台系统，或者一些任务 Job，为了支持幂等，支持重复执行，简单的处理方法是先查询下一些关键数据，判断是否已经执行过，然后再进行业务处理就可以了。但是要注意的是核心高并发流程不要用这种方法，因为效率较低。
9. 状态机幂等
在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机（状态变更图），就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候如果状态机已经处于下一个状态，却来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。
要注意的是，订单等单据类业务，存在很长的状态流转，一定要深刻理解状态机，对业务系统设计能力提高有很大帮助。
（状态机的核心我觉得应该是这个解释：针对更新操作,比如业务上需要修改订单状态,例如订单状态有待支付、支付中、支付成功、支付失败、订单超时关闭等,在设计的时候最好只支持状态的单向改变(不可逆),也就是在更新的时候where条件里可以加上status = {状态},多次调用的话实际上也只会执行一次。）
10. 缓冲队列
将请求都快速地接收下来后放入缓冲队列中,后续使用异步任务处理队列中的数据,过滤掉重复的请求,该解决方案优点是同步处理改成异步处理、高吞吐量,缺点则是不能及时地返回请求结果,需要后续轮询得处理结果。
11、对外提供接口的api如何保证幂等
如银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，seq序列号；source+seq在数据库里面做唯一索引，防止多次付款(并发时，只能处理一个请求) 。 重点：对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号seq，这个两个字段在提供方系统里面做联合唯一索引，这样当第三方调用时，先在本方系统里面查询一下，是否已经处理过，返回相应处理结果；没有处理过，进行相应处理，返回结果。注意，为了幂等友好，一定要先查询一下，是否处理过该笔业务，不查询直接插入业务系统，会报错，但实际已经处理了。
另外的一种比较简单解释可以看看：这里
总结
幂等性应该是一个合格程序员的基因，在设计系统的时候一定要考虑进去，尤其是像支付宝、银行、互联网金融公司等涉及的都是钱的系统，既要高效，也要准确，所以不能出现多扣款、多打款等问题，不然这样会很难处理，用户体验也不会好。
参考：
1.浅谈高并发下接口幂等性解决方案
2.怎么实现接口幂等性
3.接口幂等性解决方案
4.如何保证幂等
5.实现接口幂等性的几种方案
6.高并发下接口幂等性解决方案
7.分布式系统中接口的幂等性