请求后台接口失败怎么办_程序设计中接口的幂等性

接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条．．．,这就没有保证接口的幂等性。

那么如何设计接口才能做到幂等呢？

常见的两种实现方案: 1. 通过代码逻辑判断实现 2. 使用token机制实现 下面以支付系统为例,分别对接口的幂等性进行说明与实现

A: 通过代码逻辑判断实现接口幂等性,只能针对一些满足判断的逻辑实现,具有一定局限性

在不同的业务中不同接口需要有不同的幂等性，特别是在分布式系统中，因为网络原因而未能得到确定的结果，往往需要支持接口幂等性。

1、代码逻辑实现

在上文中提到的订单系统，订单具有自己的状态(orderStatus),订单状态存在一定的流转。订单首先有提交(0)，付款中(1)，付款成功(2)，付款失败(3)，简化之后其流转路径如图：

当orderStatus = 1 时，其前置状态只能是0，也就是说将orderStatus由0->1 是需要幂等性的

update Order set orderStatus = 1 where OrderId = ‘orderid’ and orderStatus = 0

当orderStatus 处于0，1两种状态时，对订单执行0->1 的状态流转操作应该是具有幂等性的。这时候需要在执行update操作之前检测orderStatus是否已经=1，如果已经=1则直接返回true即可。

2、token机制实现步骤:

1. 生成全局唯一的token,token放到redis或jvm内存,token会在页面跳转时获取.存放到pageScope中,支付请求提交先获取token

2. 提交后后台校验token，执行提交逻辑,提交成功同时删除token，生成新的token更新redis ,这样当第一次提交后token更新了,页面再次提交携带的token是已删除的token后台验证会失败不让提交

token特点： 要申请，一次有效性，可以限流

注意： redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用