浅谈接口幂等问题

解决

• 解决接口幂等问题，只需要记住一句口令”一锁、二判、三更新”，只要严格遵守这个过程，那么就可以解决并发问题。
  • 一锁：第一步，先加锁。可以加分布式锁、或者悲观锁都可以。但是一定要是一个互斥锁！
  • 二判：第二步，进行幂等性判断。可以基于状态机、流水表、唯一性索引等等进行重复操作的判断。
  • 三更新：第三步，进行数据的更新，将数据进行持久化。
  • 三步需要严格控制顺序，确保加锁成功后进行数据查询和判断，幂等性判断通过后再更新，更新结束后释放锁。
  • 以上操作需要有一个前提，那就是第一步加锁、和第二步判断的时候，需要有一个依据，这个就是幂等号了，通常需要和上游约定一个唯一ID作为幂等号。然后通过对幂等号加锁，再通过幂等号进行幂等判断即可。
• 一锁这个过程，建议使用Redis实现分布式锁，因为他是非阻塞的高效率的互斥锁。非常适合在幂等控制场景中。
• 二判这个过程，如果有操作流水，建议基于操作流水做幂等，并将幂等号作为唯一性约束，确保唯一性。如果没有流水，那么基于状态机也是可以的。
• 但是不管怎么样，数据库的唯一性约束都要加好，这是系统的最后一道防线。万一前面的锁失效了，这里也能控制得住不会产生脏数据。
• 安全性欠佳做法
  • 唯一键
  • 防重表（唯一性字段）
  • token防重
  • 状态机
  • 乐观锁（版本号）
  • （还可以）悲观锁（分布式锁/for update + 判断是否符合条件 + 更新）（一锁二判三更新）

扩展

• 请求幂等：每次请求，如果参数一样，结果也要一样。

• 业务幂等：同一次业务请求，再拿到最终状态之后的每次请求，结果要保证一样。再没拿到最终状态之前，每一次请求需要正常执行业务逻辑，直到推进到最终状态。

• 比如，一次支付请求，如果支付返回处理中，或者系统异常等，我们需要重试，继续调用，直到他明确的返回支付成功，或者明确的无法成功的支付失败结果。