幂等性解决方案

幂等性解决方案

1.防重表

数据库建立唯一性索引，可以保证最终插入数据库的只有一条数据（比如订单表对订单号进行唯一索引，所有重复提交可能产生同一个订单号的都会被拆除。当然，订单号要按你自己的设定走，一般订单号设计会是时间戳加迭代。那么如果是这样，创建仍然不能保证幂等，具体根据业务需求来判定建立的唯一索引位置）

2.token令牌机制

分为两个阶段，获取token和使用token。每次接口请求前先获取一个token，然后再下次请求的时候在请求的header体中加上这个token，后台进行验证，如果验证通过删除token，下次请求再次判断token。如果使用上redis缓存，流程图会是这样。在这里插入图片描述

3.先查询后判断

首先通过查询数据库是否存在数据，如果存在证明已经请求过了，直接拒绝该请求，如果没有存在，就证明是第一次进来，直接放行。

支付缓冲区

把订单的支付请求都快速地接下来，一个快速接单的缓冲管道。后续使用异步任务处理管道中的数据，过滤掉重复的待支付订单。优点是同步转异步，高吞吐。不足是不能及时地返回支付结果，需要后续监听支付结果的异步返回。（一般支付都是采用这种方式）

悲观锁或者乐观锁。

悲观锁可以保证每次for update的时候其他sql无法update数据(在数据库引擎是innodb的时候,select的条件必须是唯一索引,防止锁全表)
乐观锁，一般通过version来做乐观锁，这样既能保证执行效率，又能保证幂等。例如： UPDATE tab1 SET col1=1,version=version+1 WHERE version=#version# 不过，乐观锁存在失效的情况，就是常说的ABA问题，不过如果version版本一直是自增的就不会出现ABA的情况。（ABA可以查看这篇文章链接,关于CAS机制可以看这篇链接）

分布式锁

防重表可以使用分布式锁代替，比如Redis。订单发起支付请求，支付系统会去Redis缓存中查询是否存在该订单号的Key，如果不存在，则向Redis增加Key为订单号。查询订单支付已经支付，如果没有则进行支付，支付完成后删除该订单号的Key。通过Redis做到了分布式锁，只有这次订单订单支付请求完成，下次请求才能进来。相比去重表，将放并发做到了缓存中，较为高效。思路相同，同一时间只能完成一次支付请求。