接口幂等性的解决方案

幂等性概念

• 是一个数学与计算机学概念，常见于抽象代数中。
• 在编程中.一个幂等操作的特点是其任意多次执行所产生的结果均与一次执行的结果相同。
• 大白话：就是同一个操作因为网络或者其他原因，多次调用同一个接口，从而导致脏数据的产生

保证接口的幂等性是什么意思

• 保证同一个操作只调用一次接口
• 保证同一个操作调用多次接口产生的结果和调用一次接口是相同的

哪些操作需要我们解决幂等性

• 查询：查询一次或者多次，在数据不变的情况下，查询结果永远相同，无需考虑
• 删除：删除一次或者多次可能返回结果不一样，不影响结果，无需考虑
• 新增：新增一次或者多次就是一条数据和多条数据的区别，需要考虑
• 修改：修改某个值为固定值一次和多次不影响，但是每次修改值加1，一次和多次就不一样了，需要考虑

接口幂等性的解决方案

1：唯一索引

• 解决新增幂等性，保证多次调用产生结果和一次调用结果相同
• 同一个新增操作，先查询在新增，第一次新增查询唯一索引字段为空，允许插入，之后每次新增之前查询唯一索引值已存在，直接返回结果。或者直接新增发现唯一索引冲突报错，直接返回结果

2：token机制

• 解决新增和修改幂等性，保证同一个操作只调用一次业务api接口
• 生成全局唯一token返回给客户端，第一次调用接口客户端带上token，走完接口之后更新或者删除token值，客户端再次访问服务器token校验就会失败，因为服务器的token已经被修改或者删除。
• 单机token可以存储在session里面，服务化的架构可以存在redis里面

3：悲观锁或者乐观锁 配合 查询之后在操作

• 解决修改幂等性，保证多次调用产生结果和一次调用结果相同
• 先锁住需要操作的记录，比如：查询id=1的土地状态为未交易，锁住id=1的土地，修改完之后土地状态为已完成，释放id=1的锁。同样的请求再次过来查询发现土地状态为已完成，直接返回结果提示该土地状态为已完成，无法进行交易。
• 使用悲观锁或者乐观锁保证并发，防止第一个请求未修改订单状态而第二个请求就进行订单状态的查询，杜绝这种情况的发生
• 此种方案有局限性，比如阅读量+1这种操作没有什么状态的转换可以判断，就无法使用此种方案

4：分布式锁

• 如果是分布式系统的话，构建全局唯一索引会比较困难，比如唯一性的字段就没有办法确定。这时候可以引入分布式锁，通过第三方的系统（Redis或Zookeeper），在业务系统插入数据或者更新数据前，需要先获取分布式锁，然后才能做操作，操作完成之后就释放锁。这样其实是把单机系统里面多线程并发锁的思路引入了多个系统的场景，也就是分布式系统中的解决思路。
• 要点：某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志（用户ID+后缀等）获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁（分布式锁要第三方系统提供）。

5：对外提供接口的api保证幂等性

• 如银联提供的付款接口：商户提交付款请求时传入参数：source来源，seq序列号
• source+seq这2个字段必传，且组合必须是唯一，在数据库里面做唯一索引
• 每次调用时，在数据库里面查询是否存在source+seq的唯一索引值，如果存在说明已经付款完生成订单，不允许再次操作
• 其实也是唯一索引的使用

                                                                                                             你曾是少年