接口幂等性

什么是幂等性

幂等(Idempotent)是一个数学与计算机学的概念,常见于抽象代数中。

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

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

  1. 前端重复提交选中的数据,后台也只会产生对应这个数据的一个反应结果。
  2. 用户发起一笔付款请求,就应该只扣用户一次钱,即使遇到网络重发或系统 bug 重发请求,也应该之扣一次钱。
  3. 发送验证短息也应该只发一次,同样的验证短信不应该发送多次。
  4. 创建业务订单,一个业务请求只能创建一个业务订单,创建多个就会出大问题。

这些等等很多的业务逻辑都需要幂等的特性来支持。

简单来理解就是,幂等就是一个操作,这个操作不管执行多少次,产生的效果和返回的结果都是一样的。比如说有一个 getOne () 函数,无论执行这个函数多少次,它返回的都是 1,这时就可以说它是一个幂等函数。

为什么需要实现幂等性?

在接口调用时一般情况下都能正常返回信息不会重复提交,不过在遇见以下情况时可以就会出现问题,如:

  1. 前端重复提交表单: 在填写一些表格时候,用户填写完成提交,很多时候会因网络波动没有及时对用户做出提交成功响应,致使用户认为没有成功提交,然后一直点提交按钮,这时就会发生重复提交表单请求。
  2. 用户恶意进行刷单: 例如在实现用户投票这种功能时,如果用户针对一个用户进行重复提交投票,这样会导致接口接收到用户重复提交的投票信息,这样会使投票结果与事实严重不符。
  3. 接口超时重复提交: 很多时候 HTTP 客户端工具都默认开启超时重试的机制,尤其是第三方调用接口时候,为了防止网络波动超时等造成的请求失败,都会添加重试机制,导致一个请求提交多次。
  4. 消息进行重复消费: 当使用 MQ 消息中间件时候,如果发生消息中间件出现错误未及时提交消费信息,导致发生重复消费。

幂等性的实现

  1. 查询操作

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

  2. 删除操作

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

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

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

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

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

  5. 悲观锁

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

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

    要注意的是,id 字段一定要是主键或者唯一索引,否则会导致锁表。悲观锁的使用一般伴随事务一起使用,数据锁定事件可能会很长,要根据实际情况慎用。

  6. 乐观锁

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

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

  7. 分布式锁

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

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

  8. select+insert

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

  9. 状态机幂等

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

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

幂等性的不足

  1. 增加了额外控制幂等的业务逻辑,复杂化了业务功能。
  2. 把并行执行的功能改为串行执行,降低了执行效率。

总结

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