重复提交【接口幂等性】

接口的作用：幂等性防止接口重复提交

实现接口幂等性的方式：

方式一：通过令牌校验的方式

方式二：通过分布式锁的方式

分布式事务和分布式锁

当一个资源可能被争抢时，就需要使用分布式锁，防止超卖/重复提交现象发生

例如：假如支付接口，需要在钱包中扣钱；此时，支付接口所在的服务有两个节点，用户点击两次支付，两个接口都会执行支付操作；此时钱包就会被争抢，需要使用分布式锁，防止钱包金额变成负数

在购买完成后，订单表会自增加一条记录，商品表记录会减少商品数量，钱包会减少金额，此时就涉及到分布式事务

分布式事务和普通事务的原子性要求是一样的：要么全部成功，要么全部失败；此时当业务发生异常时，就需要全部回滚；

被争抢的资源如何分类

资源分为个人资源和公有资源

如果是用户个人的资源需要，先锁定预扣除

如果是公用的资源，需要先完成前置逻辑，再锁定扣除；如果先行逻辑执行完成，公用资源消耗完毕或者失败，需要补偿个人资源

首先指定一个场景

假设一个商城系统发起一个秒杀活动，活动中的商品是手表，共有100块，每块秒杀价50元

此时共有10000个用户发起秒杀，每个用户有1-100元范围的资产，有百分之90的用户资产低于50元

图一：此时所有的用户争抢分布式锁，但是只有一个人可以拿到分布式锁，其他 9999 人都需要等待；如果此时拿到分布式锁的人没有支付能力，那么将会造成订单流失

图二：此时所有的用户都需要预扣除钱包，扣除成功后才可以获取手表库存的分布式锁；此时可以支撑 1个人拿到分布式锁，其他人只能等待或退出秒杀操作；系统依然会造成订单流失【预扣除机制】

图三：此时可以支