1. 接口调用存在的问题
现如今我们的系统大多拆分为分布式SOA，或者微服务，一套系统中包含了多个子系统服务，而一个子系统服务往往会去调用另一个服务，而服务调用服务无非就是使用RPC通信或者restful，既然是通信，那么就有可能在服务器处理完毕后返回结果的时候挂掉，这个时候用户端发现很久没有反应，那么就会多次点击按钮，这样请求有多次，那么处理数据的结果是否要统一呢？那是肯定的！尤其在支付场景。
2 什么是接口幂等性
接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条．．．,这就没有保证接口的幂等性
3 实现幂等性的方案
常见的两种实现方案: **1. 通过代码逻辑判断实现 2. 使用token机制实现 ** 下面以支付系统为例,分别对接口的幂等性进行说明与实现
1 通过逻辑：
比如 订单系统 和 支付系统
支付接口 boolean pay(int accountid,BigDecimal amount) //用于付款，扣除用户的
这样两次重复的请求会造成两次扣款
解决： boolean pay(int orderId,int accountId,BigDecimal amount)
逻辑上 扣款时 判断该订单没有支付过即可
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，存在并发问题，不建议使用
