我最近看了公司的界面文档，提到了幂等性，现在查了相关知识后，我知道幂等性。 把参考的博文贴在这里。
我们的系统大多被分割为分布式SOA或微服务，一个系统包含多个子系统服务。 一个子系统服务经常调用另一个服务，而服务调用服务只能使用RPC通信或rest风格的。 既然是通信，在服务器处理结束并返回结果时就有可能切断。 此时，用户方面发现长时间没有反应，多次点击按钮。 如果这样多次提出请求，处理数据的结果是否统一？ 那是肯定的！ 特别是再支付的场景。
幂等性：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付。 用户购买商品后支付，成功扣款，但结果返回时，网络异常。 此时，钱已经被吸引了。 用户再次单击按钮。 此时，将进行第二次扣款。 结果返回，用户查了余额，发现了多馀的扣款，流水记录也变成了两条。 在传统的单APP应用系统中，只需要将数据操作放入事务中，并且在出现错误时立即回滚，但在响应客户端时可能会发生网络中断或异常。
在这四个操作中，在尤为注意就是增加或者修改中，查询对结果没有更改，只删除一次，用户多次单击的结果相同，修改在大多数场景中结果相同，在重复提交的场景中增加
那么，如何设计接口才能进行幂等呢？
方法1 )一次申请即直接支付，无需额外的数据库操作。 此时，启动异步请求并创建唯一的ticketId。 是票。 这张票只能使用一次就失效了。 具体步骤如下。
1、要求异步取票
2、呼叫付款，把票搬进去
3、根据票券ID查询是否存在本次操作，如果存在，表示执行了该操作，直接返回结果； 如果不存在，支付扣款，保存结果
4、将结果返回客户端
步骤4通信失败，即使用户再次提出请求，最终的结果也相同.
方法2 :分布式环境下各服务相互调用
这里以我们的系统为例。 我们付款的时候先扣款，然后更新订单。 这里涉及订单服务和支付服务。 用户调用支付并成功提取后，更新对应订单的状态，然后保存流水。 在此位置不需要使用票证ticketId。 因为会出现空闲的麻烦(支付状态)、未支付、已支付)
步骤：
1、查询订单支付情况
2、已支付的，直接返还结果
3、未付款时，支付扣款，保存流水
4、返回支付结果
如果步骤4中的通信失败，用户再次开始请求，则最终结果相同
对于曾经支付过款项的朋友，乘方等也称为冲正，保证客户端和服务端交易的一致性，避免多次被扣款。
以下是对幂等的接口文档的描述，根据请求id号来判断是否是相同的请求。
原文链接： https://www.cn blogs.com/vveiliang/p/6643874.html