接口调用问题
目前，我们的系统大多分为分布式SOA或微服务，一个系统包含多个子系统服务，一个子系统服务往往调用其他服务。 另一方面，服务调用服务只是使用RPC通信或rest风格的服务，既然是通信，则服务器在处理结束后返回结果时有可能挂起。 此时，如果发现客户端长时间没有反应，肯定会多次点击按钮，请求处理数据的结果！ 特别是在支付场景中。 什么是接口幂等性
接口幂等性是指用户对同一操作发起的一次请求或多次请求的结果匹配，不会发生多次单击的副作用。 举个最简单的例子，就是支付。 用户购买商品后支付，成功扣款，但结果返回时，网络异常。 此时，钱已经被吸引了。 用户再次单击按钮。 这时，进行了第二次扣款，结果回来了。 用户查了余额后回来，找到了很多扣款。 流水记录也变成了两个。 这不需要保证接口的幂等性。 在什么情况下，接口
在追加、删除、重新审视的4个操作中，应该特别注意的是追加或修正。
A:查询操作
查询结果保持不变。 一次查询和多次查询，如果数据不变，则查询结果相同。 select是天然幂等操作B:删除操作
删除一次和多次都是删除数据。 (请注意，返回的结果可能不同。 已删除的数据不存在。 返回0。 已删除的数据有多个。 返回的结果有多个。 如果不考虑返回的结果，则删除操作也具有幂等性。 ) C:更新操作
修改在大多数场景中的结果相同，但增量修改需要乘方等保证。 例：
无论执行多少次，将表中id为XXX的记录的a字段值设置为1的操作都是按幂执行的
将表中id为XXX的记录的a字段的值增加1的操作不是幂等
D:新操作
增加重复提交的场景时，会发生上述支付问题等乘方等问题
那么，如何设计接口才能进行幂等呢？
两种常见的实现方案： 1.基于代码逻辑判断的实现使用token机制实现以下，以支付系统为例，分别说明和实现接口的幂等性
A:通过码逻辑判定来实现接口的幂等性，但只能针对满足判定的逻辑来实现，具有一定的局限性
用户购买商品的订单系统和支付系统订单系统负责记录用户的购买记录已经订购的分销状态，支付系统用于支付，提供以下接口，订单系统和支付系统
用于布尔支付(int account id，BigDecimal amount )//支付，用于用户的
在这种情况下，虽然支付系统已经被提取，但由于订单系统是网络的，所以无法得到正确的结果。 因此，订单系统需要重试。 从上图可以看出，支付系统没有实现接口的幂等性，订单系统的第一次调用和第二次调用，用户分别被扣两次钱，不符合幂等性原则(同一订单，无论调用多少次) 如果需要支持幂等性，则必须将支付接口更改为以下接口：
布尔支付(int orderid，int accountId，BigDecimal amount ) )。
使用orderId确定订单的唯一性。 如果支付系统检测到订单已支付，则在第二次呼叫中不会被提取，而是直接返回结果。
不同的业务需要不同的接口幂等性，尤其是分布式系统，由于网络原因不能得到确定的结果，往往需要支持接口幂等性。
随着分布式系统和微服务的普及，由于网络原因，呼叫系统得不到适当的结果而进行重试，需要呼叫系统具有幂等性。 举例来说，在上述支付系统中，保证同一订单的支付幂等性，且一旦确定订单的支付状态，后续操作将返回相同结果，且对用户的扣款也仅为一次。 这种接口幂等性简化了数据级别上的操作：
udateuseramountsetamount=amount -‘value’，pay status=‘paid’where orderid=‘orderid’andpaystatus=‘un pay’
其中，value是用户减少的订单，paystatus为支付状态，paid为已支付，unpay为未支付，orderid为订单编号。
在上述订单系统中，订单有自己的“状态”，订单的状态有一定的流程。 订单首先有提交(0)、支付中(1)、支付成功(2)、支付失败(3)，简化后的流程路径如下。
orderStatus=1时，其前置状态只有0。 也就是说，必须从0-1开始对orderStatus求幂
updateordersetorderstatus=1where orderid=‘orderid’and order status=0
如果订单状态处于0、1两种状态，则对订单执行0-1的状态流操作应该具有幂等性。 在这种情况下，在执行更新操作之前，必须检测orderStatus是否为=1，如果为=1，则必须原样返回true。
但是，此时如果orderStatus=2，则在订购状态0-1下操作不成功，幂等性对相同的要求，也就是说
同一个requestid保持幂等。这时候再执行update Order set orderStatus = 1 where OrderId = ‘orderid’ and orderStatus = 0
接口会返回失败，系统没有产生修改，如果再发一次，requestid是相同的，对系统同样没有产生修改。
B: 使用token机制实现接口幂等性,通用性强的实现方法
token机制实现步骤: 1. 生成全局唯一的token,token放到redis或jvm内存,token会在页面跳转时获取.存放到pageScope中,支付请求提交先获取token 2. 提交后后台校验token，执行提交逻辑,提交成功同时删除token，生成新的token更新redis ,这样当第一次提交后token更新了,页面再次提交携带的token是已删除的token后台验证会失败不让提交 token特点： 要申请，一次有效性，可以限流 注意： redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用