接口实现幂等的几种方式

幂等性的概念

幂等（Idempotent）是一个数学与计算机学的概念，常见于抽象代数中。

f(n) = 1^n // 无论n等于多少，f(n)永远值等于1

一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

在涉及外部系统调用或者提供接口给其他系统调用的时候，实现接口的幂等是很有必要的，比如某个单据业务在不同的系统中都有各自的状态机，如果接口不幂等，外部系统稍微重试或者接口调用顺序乱序，就会导致单据数据出错。

幂等性的技术方案

1. 查询操作

查询一次和查询多次，在数据不变的情况下，查询结果都是一样的，select 是天然的幂等操作。

2. 删除操作

删除操作也是幂等的，删除一次和删除多次都是把数据删除。

3. 建立唯一索引，防止新增脏数据

当表存在唯一索引，并发时新增重复记录就会报错，那么这时候就查询已存在的记录并返回即可。

4. Token 机制，防止页面重复提交

页面数据只能够提交一次，但是由于出现重复点击或者网络重发或 Nginx 重发等情况导致数据被重复提交的情况下，可以采用 Token+Redis（Redis 是单线程的，处理需要排队）的解决方案。处理的流程是，在数据提交前要向服务器申请带有有效时间的 Token，然后 Token 放到 Redis或内存中，当数据正式提交到后台要校验 Token 并删除 Token。然后重复请求过来的时候，肯定就查不到token，就说明是重复请求。

5. 悲观锁

获取数据的时候加锁获取：

select * from table where id = 'xxx' for update;

要注意的是，id 字段一定要是主键或者唯一索引，否则会导致锁表。

悲观锁的使用一般伴随事务一起使用，数据锁定事件可能会很长，要根据实际情况慎用。

6. 乐观锁

乐观锁只是在更新数据的那一刻锁表，其他时间不锁表，所以相对于悲观锁效率更高。

乐观锁的实现方式多种多样，可以通过 version 或者其他状态条件。

7. 分布式锁

还是拿插入数据的例子，如果是分布式系统，构建全局唯一索引比较困难，例如唯一性的字段无法确定。那么这时候就可以引入分布式锁，通过第三方的系统（Redis 或 Zookeeper），在业务系统插入数据或更新数据，获取分布式锁，然后做操作，之后再释放锁。这样其实是把多线程并发锁的思路引入了多个系统，也就是分布式系统中的解决思路。

要注意的是，某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志（用户 ID + 后缀等）获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁（分布式锁需要第三方系统提供)）。

8.select+insert

对于一些并发不高的后台系统，或者一些任务 Job，为了支持幂等，支持重复执行，简单的处理方法是先查询下一些关键数据，判断是否已经执行过，然后再进行业务处理就可以了。但是要注意的是核心高并发流程不要用这种方法，因为效率较低。

9. 状态机幂等

在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机（状态变更图），就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候如果状态机已经处于下一个状态，却来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。

要注意的是，订单等单据类业务，存在很长的状态流转，一定要深刻理解状态机，对业务系统设计能力提高有很大帮助。

总结

幂等性在设计系统的时候一定要考虑进去，尤其是像支付宝、银行、互联网金融公司等涉及的都是钱的系统，既要高效，也要准确，所以不能出现多扣款、多打款等问题，不然这样会很难处理，用户体验也不会好。