首先看看幂等的定义。
一个HTTP方法是幂等的，指的是同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。换句话说就是，幂等方法不应该具有副作用（统计用途除外）。在正确实现的条件下，GET，HEAD，PUT和DELETE 等方法都是幂等的，而 POST 方法不是。所有的 safe 方法也都是幂等的。
幂等性只与后端服务器的实际状态有关，而每一次请求接收到的状态码不一定相同。例如，第一次调用DELETE 方法有可能返回 200，但是后续的请求可能会返回404。DELETE 的言外之意是，开发者不应该使用DELETE方法实现具有删除最后条目功能的 RESTful API。
需要注意的是，服务器不一定会确保请求方法的幂等性，有些应用可能会错误地打破幂等性约束。
是不是有点抽象？
再看看英文的定义
Idempotence (UK: /ˌɪdɛmˈpoʊtəns/,[1] US: /ˌaɪdəm-/)[2] is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application. The concept of idempotence arises in a number of places in abstract algebra (in particular, in the theory of projectors and closure operators) and functional programming (in which it is connected to the property of referential transparency).
嗯，看上去问题更加复杂了。
举个例子
其实幂等就是一个操作或者接口，不管你调多少次，每次执行的结果都跟第一次一样。
比如数学上，1这个数字就是幂等的，无论你用什么数字跟1乘，乘多少次，最后的结果都跟第一次是一样的。
试想这样的一种场景：在电商平台上支付后，因为网络原因导致系统提示你支付失败，于是你又重新付款了一次，等完成后检查网银发现被系统扣了两次款，这是一种什么样的体验？
造成上述问题的原因可能有很多，比如第一次付款时实际支付成功，但是信息返回时网络中断导致系统误判；又比如第一次付款的确失败了，但第二次付款时发生意外，导致支付请求被重复发送等等。在一次支付的过程中，每个环节都有可能会发生问题，我们要如何规避这类问题引发的风险？
幂等性是解决这类问题的方案之一，所以在电商，银行，互联网金融等对数据准确性要求很高的领域中，这一特性具有十分重要的地位。
所以对于一些重要的接口或者操作，我们是要求后台保证其幂等性的。因为客户端可能有重试机制，另外中间人攻击可能会进行请求的重放，这些都有可能导致接口被多次调用，像上面的扣款操作，如果接口没有实现幂等，那么后果是相当不堪设想的。
实现幂等的思路
- MVCC: 多版本并发控制，乐观锁的一种实现，在数据更新时需要去比较持有数据的版本号，版本号不一致的操作无法成功；
- select version from table where orderid=?;
- update table set version = version+1 wehre orderid=? and version=查询结果。
- 去重表： 利用数据库表单的特性来实现幂等，常用的一个思路是在表上构建唯一性索引，保证某一类数据一旦执行完毕，后续同样的请求再也无法成功写入。 比如博客上面要想防止一个人重复点赞，可以设计一张表，将博客id与用户id绑定建立唯一索引，每当用户点赞时就往表中写入一条数据，这样重复点赞的数据就无法写入。
- TOKEN机制: 这种机制就比较重要了，适用范围较广，有多种不同的实现方式。其核心思想是为每一次操作生成一个唯一性的凭证，也就是token。一个token在操作的每一个阶段只有一次执行权，一旦执行成功则保存执行结果。对重复的请求，返回同一个结果。以电商平台为例子，电商平台上的订单id就是最适合的token。当用户下单时，会经历多个环节，比如生成订单，减库存，减优惠券等等。每一个环节执行时都先检测一下该订单id是否已经执行过这一步骤，对未执行的请求，执行操作并缓存结果，而对已经执行过的id，则直接返回之前的执行结果，不做任何操作。这样可以在最大程度上避免操作的重复执行问题，缓存起来的执行结果也能用于事务的控制等。
- 例如接口中增加唯一字段seq
重点？
-
幂等不仅仅只是一次（或多次）请求对资源没有副作用（比如查询数据库操作，没有增删改，因此没有对数据库有任何影响）。
-
幂等还包括第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。
-
幂等关注的是以后的多次请求是否对资源产生的副作用，而不关注结果。
-
网络超时等问题，不是幂等的讨论范围。
幂等性是系统服务对外一种承诺（而不是实现），承诺只要调用接口成功，外部多次调用对系统的影响是一致的。声明为幂等的服务会认为外部调用失败是常态，并且失败之后必然会有重试。
如何测试？
- 首先在需求分析的时候我们要有能力识别出需要实现幂等的接口，提前要求开发同学去实现；
- 测试过程中由于幂等的特性是多次调用的结果相同，那么可以用自动化的方式去反复调用，这样会比较高效；
- 异常情况需要考虑到，比如除了第一次调用之外的调用是否有性能问题，稍微修改一些无关紧要的参数是否会破坏幂等之类的；
总结：
幂等是保证一个相同的请求，只会完成一次处理。处理过程中会遇到：重复提交、网络超时未反馈结果、再次请求导致资源再次变化等
