使用订单号orderNo做为去重表的唯一索引，每次请求都根据订单号向去重表中插入一条数据。第一次请求查询订单支付状态，当然订单没有支付，进行支付操作，无论成功与否，执行完后更新订单状态为成功或失败，删除去重表中的数据。后续的订单因为表中唯一索引而插入失败，则返回操作失败，直到第一次的请求完成（成功或失败）。可以看出防重表作用是加锁的功能。
通过唯一索引的方式，进行，当相同的数据，往唯一的索引表插入的时候，就会报错。
例子：
创建一个测试表
创建唯一索引
ALTER IGNORE TABLE test03 ADD UNIQUE INDEX id_uid(id,uid);再次插入数据，发现相同的数据不能插入
INSERT INTO test03(id,uid) VALUES (1,1),(1,2),(1,1),(1,2),(1,1);这种方式其实和下方的redis方式形式上差不多，而且下方的方式更快。
分布式锁这里使用的防重表可以使用分布式锁代替，比如Redis。订单发起支付请求，支付系统会去Redis缓存中查询是否存在该订单号的Key，如果不存在，则向Redis增加Key为订单号。查询订单支付已经支付，如果没有则进行支付，支付完成后删除该订单号的Key。通过Redis做到了分布式锁，只有这次订单订单支付请求完成，下次请求才能进来。相比去重表，将放并发做到了缓存中，较为高效。思路相同，同一时间只能完成一次支付请求。
token令牌这种方式分成两个阶段：申请token阶段和支付阶段。 第一阶段，在进入到提交订单页面之前，需要订单系统根据用户信息向支付系统发起一次申请token的请求，支付系统将token保存到Redis缓存中，为第二阶段支付使用。 第二阶段，订单系统拿着申请到的token发起支付请求，支付系统会检查Redis中是否存在该token，如果存在，表示第一次发起支付请求，删除缓存中token后开始支付逻辑处理；如果缓存中不存在，表示非法请求。 实际上这里的token是一个信物，支付系统根据token确认，你是你妈的孩子。不足是需要系统间交互两次，流程较上述方法复杂。
支付缓冲区把订单的支付请求都快速地接下来，一个快速接单的缓冲管道。后续使用异步任务处理管道中的数据，过滤掉重复的待支付订单。优点是同步转异步，高吞吐。不足是不能及时地返回支付结果，需要后续监听支付结果的异步返回。
RestfulApi幂等性详解我们要注意幂等是面向资源的。这个 HTTP GET 方法可能会每次得到不同的返回内容，但并不影响资源。
GET方法HTTP GET 方法，用于获取资源，不管调用多少次接口，结果都不会改变，所以是幂等的。只是查询数据，不会影响到资源的变化，因此我们认为它幂等。
POST方法HTTP POST 方法是一个非幂等方法，因为调用多次，都将产生新的资源。因为它会对资源本身产生影响，每次调用都会有新的资源产生，因此不满足幂等性。
PUT方法因为它直接把实体部分的数据替换到服务器的资源，我们多次调用它，只会产生一次影响，但是有相同结果的 HTTP 方法，所以满足幂等性。
Delete方法HTTP DELETE 方法用于删除资源，会将资源删除。调用一次和多次对资源产生影响是相同的，所以也满足幂等性。
所以对于restful来说，只有post是不满足的。