幂等性原本是数学上的概念用在编程领域，则意为对同一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。
幂等性原本是数学上的概念，，即使公式：f(x)=f(f(x)) 能够成立的数学性质。编程领域，则意为对同一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。
用通俗的话讲：就是针对一个操作，不管做多少次，产生效果或返回的结果都是一样的。
如果没有实现接口幂等性会有很严重的后果： 支付接口，重复支付会导致多次扣钱 订单接口，同一个订单可能会多次创建。
这个很好理解，比如用户多次购买同一个产品，这种情况肯定是允许的，如果做了幂等，用户就只能购买一次，这明显是不合理的。
比如把数据清零，这种操作不论执行多少次，结果都是一样的。（与之相反的是累加或者累减，这种操作每次执行都会改变最终结果）
如果把操作按照功能分类，那就是增删改查四种，在 http 协议中则表现为Post、Delete 、Put、Get四种。
这里只简单介绍详细的可以看：https://juejin.cn/post/6844903813799739399
Get 方法用于获取资源，不应当对系统资源进行改变，所以是幂等的。**注意这里的幂等提现在对系统资源的改变，而不是返回数据的结果，即使返回结果不相同但是该操作本身没有副作用，所以幂等。比如：GET http://www.bank.com/account/123456，不会改变资源的状态，不论调用一次还是N次都没有副作用。
Delete 方法用于删除资源，虽然改变了系统资源，但是第一次和第N次删除操作对系统的作用是相同的，所以是幂等的。比如：DELETE [http://www.forum.com/article/1234，调用一次和N次对系统产生的副作用是相同的，即删掉id为1234的帖子；因此，调用者可以多次调用或刷新页面而不必担心引起错误。
比较容易混淆的是HTTP POST和PUT。POST和PUT的区别容易被简单地误认为“POST表示创建资源，PUT表示更新资源”；而实际上，二者均可用于创建资源，更为本质的差别是在幂等性方面。在HTTP规范中对POST和PUT是这样定义的：
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line … If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.
POST所对应的URI并非创建的资源本身，而是资源的接收者。比如：POST http://www.forum.com/articles的语义是在http://www.forum.com/articles下创建一篇帖子，HTTP响应中应包含帖子的创建状态以及帖子的URI。两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI；所以，POST方法不具备幂等性。而PUT所对应的URI是要创建或更新的资源本身。比如：PUT http://www.forum/articles/1234的语义是创建或更新ID为1234的帖子。对同一URI进行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有幂等性。
我们在网上搜索幂等性问题的解决方案，会有各种各样的解法，但是如何判断哪种解决方案对于自己的业务场景是最优解，这种情况下，就需要我们抓问题本质。
经过以上分析，我们得到了解决幂等性问题就是要控制对资源的写操作。
我们从问题各个环节流程来分析解决：
控制动作触发源头，即前端做幂等性控制实现
主要解决方案：
相对不太可靠，没有从根本上解决问题，仅算作辅助解决方案。
控制过滤重复动作，是指在动作流转过程中控制有效请求数量。
分布式锁的主要实现有两种，但原理都是相同的，这里那用Redis 和 Zookeeper举个例子
Token 机制应该是适用范围最广泛的一种幂等设计方案了，具体实现方式也很多样化。但是核心思想就是每次操作都生成一个唯一 Token 凭证，服务器通过这个唯一凭证保证同样的操作不会被执行两次。这个 Token 除了字面形式上的唯一字符串，也可以是多个标志的组合（比如上面提到的状态标志），甚至可以是时间段标识等等。
举个例子，在论坛中发布一个新帖子，这是一个典型的 Post 新增操作，要怎样防止用户多次点击提交导致产生多个同样的帖子呢。可以让用户提交的时候带一个唯一 Token，服务器只要判断该 Token 存在了就不允许提交，便能保证幂等性。
上面这个例子比较容易理解，但是业务比较简单。由于 Token 机制适用较广，所以其设计中要注意的要求也会根据业务不同而不同。
Token 在何时生成，怎么生成？这是该机制的核心，就拿上面论坛系统来说，如果你在用户提交帖子的时候才生成 Token，那用户每次点提交都会生成新的 Token 然后都能提交成功，就不是幂等的了。必须在用户提交内容之前，比如进入编辑页面的时候生成 Token，用户在提交的时候内容带着 Token 一起提交，对于同一个页面无论用户提交多少次，就至多能成功一次。所以 Token 生成的时机必须保证能够使该操作具多次执行都是相同的效果才行。使用 Token 机制就要求开发者对业务流程有较好的理解。
应用流程如下：
1）服务端提供了发送token的接口。执行业务前先去获取token，同时服务端会把token保存到redis中；
2）然后业务端发起业务请求时，把token一起携带过去；
3）服务器判断token是否存在redis中，存在即第一次请求，可继续执行业务，执行业务完成后将token从redis中删除；
4）如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给client，这样就保证了业务代码不被重复执行。
把所有请求都快速地接下来，对接入缓冲管道。后续使用异步任务处理管道中的数据，过滤掉重复的请求数据。
优点：同步转异步，实现高吞吐。
缺点：不能及时返回处理结果，需要后续监听处理结果的异步返回数据。
实现幂等性常见的方式有：悲观锁（for update）、乐观锁、唯一约束。
简单理解就是：假设每一次拿数据，都有认为会被修改，所以给数据库的行或表上锁。
当数据库执行select for update时会获取被select中的数据行的行锁，因此其他并发执行的select for update如果试图选中同一行则会发生排斥（需要等待行锁被释放），因此达到锁的效果。
select for update获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。（注意for update要用在索引上，不然会锁表）
START TRANSACTION; # 开启事务
SELETE * FROM users WHERE id=1 FOR UPDATE;
UPDATE users SET name= 'xiaoming' WHERE id = 1;
COMMIT; # 提交事务
MVCC：多版本并发控制，乐观锁的一种实现，在数据更新时需要去比较持有数据的版本号，版本号不一致的操作无法成功。
不过，乐观锁存在失效的情况，就是常说的ABA问题，不过如果version版本一直是自增的就不会出现ABA的情况。
UPDATE users SET name='xiaoxiao', version=(version+1) WHERE id=1 AND version=version;
缺点：就是在操作业务前，需要先查询出当前的version版本
例如：支付状态流转流程：待支付->支付中->已支付
具有一定要的前置要求的，严格来讲，也属于乐观锁的一种。
状态标识是很常见的幂等设计方式，主要思路就是通过状态标识的变更，保证业务中每个流程只会在对应的状态下执行，如果标识已经进入下一个状态，这时候来了上一个状态的操作就不允许变更状态，保证了业务的幂等性。
状态标识经常用在业务流程较长，修改数据较多的场景里。最经典的例子就是订单系统，假如一个订单要经历 创建订单 -> 订单支付\取消 -> 账户计算 -> 通知商户 这四个步骤。那么就有可能一笔订单支付完成后去账户里扣除对应的余额，消耗对应的优惠卷。但是由于网络等原因返回了错误信息，这时候就会重试再次去进行账户计算步骤造成数据错误。
所以为了保证整个订单流程的幂等性，可以在订单信息中增加一个状态标识，一旦完成了一个步骤就修改对应的状态标识。比如订单支付成功后，就把订单标识为修改为支付成功，现在再次调用订单支付或者取消接口，会先判断订单状态标识，如果是已经支付过或者取消订单，就不会再次支付了。
常见的就是利用数据库唯一索引或者全局业务唯一标识（如：source+序列号等）。
这个机制是利用了数据库的主键唯一约束的特性，解决了在insert场景时幂等问题。但主键的要求不是自增的主键，这样就需要业务生成全局唯一的主键。
全局ID生成方案：
R 和 INCRBY 这样的自增原子命令，保证生成的 ID 肯定是唯一有序的。
https://xie.infoq.cn/article/107fd263605e9d184b78bf093