幂等性
就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。
举个最简单的例子，支付场景，用户购买商品后支付，支付扣款成功，但是返回结果的时网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条。
在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等。
什么情况下需要保证接口的幂等性？
在增删改查4个操作中，尤为注意就是增加或者修改。
A: 查询操作
查询对于结果是不会有改变的，查询一次和查询多次，在数据不变的情况下，查询结果是一样的。select是天然的幂等操作。
B: 删除操作
删除一次和多次删除都是把数据删除。(注意，删除的数据存在和不存在，会导致数据库返回结果不一样，所以，不考虑返回结果的前提下，删除操作也是具有幂等性的)
C: 更新操作
修改在大多场景下结果一样，但如果是增量或减量修改则需要保证幂等性，如:
将表中id为XXX的记录的A字段值更新为1,这种操作不管执行多少次都是幂等的；
把表中id为XXX的记录的A字段值增加1,这种操作就不是幂等的。
D: 新增操作
新增在重复提交的场景下会出现幂等性问题，如以上的支付问题
支付场景的幂等设计示例：
方法1：
单次支付请求，也就是直接支付了，不需要额外的数据库操作了，这个时候发起异步请求创建一个唯一的ticketId，就是门票，这张门票只能使用一次就作废，具体步骤如下：
1、异步请求获取门票
2、调用支付，传入门票
3、根据门票ID查询此次操作是否存在，如果存在则表示该操作已被执行过，直接返回结果；如果不存在，支付扣款，保存结果。
4、返回结果到客户端
如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样。
方法2：
分布式环境下各个服务相互调用。
先扣款，再更新订单。用户调用支付，扣款成功后，更新对应订单状态，然后再保存流水。而在这个地方就没必要使用门票ID了，因为会比较显的麻烦（订单涉及支付状态：未支付，已支付），步骤如下：
1、查询订单支付状态
2、如果已支付，直接返回结果
3、如果未支付，则支付扣款并保存流水
4、返回支付结果
如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的
幂等也称之为冲正，旨在保证客户端与服务端的交易一致性，避免多次扣款。
Token 令牌机制实现步骤：
- 生成全局唯一的token,存到redis或其他缓存系统中,token会在页面跳转时获取，存放到页面配置信息中,支付请求提交先获取token。
- 提交后,后台校验token，执行提交逻辑,提交成功同时删除token，生成新的token更新redis ,这样当第一次提交后token更新了,页面再次提交携带的token是已删除的token后台验证会失败不让提交。
token特点：一次有效性，可以限流
注意：redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用。
网友评论