接口幂等性设计

简书日更 第1篇： 接口幂等性设计 相关知识

---

1. 接口幂等性涉及的相关问题

经常遇到数据重复的问题

• 表单录入如何防止重复提交

• 微服务架构中，客户端重试如何防止重复提交

幂等性：f(f(x)) = f(x)

幂等元素运行多次，还等于它原来运算的结果

什么情况下需要幂等性

重复提交、接口重试、前端业务操作抖动

并不是所有的业务都需要幂等性，要根据实际业务确定是否需要幂等性

2. 保证幂等性的策略分析

保证幂等性的核心思想：通过一个唯一序号保证幂等（如果一个业务操作我们赋予它一个唯一业务id，如果这个业务操作内容一样，那么这个业务id就不变，这个时候有多个一模一样的业务id到后台，就可以进行判断了）

非并发情况下只需要查询这个业务单号是否有操作过，如果没有执行即可

并发情况整个过程用加锁来实现

3. 业务操作的幂等性分析

• Select：查询操作不需要考虑幂等，对数据不会产生任何影响，天然幂等

• Delete：删除操作，第一次修改成功后就不会有任何返回，后续啊不再执行了，也就不用考虑幂等了，但有一个问题，删除操作无论使用什么条件最后都转换到唯一id进行删除

• Update：这个就需要考虑幂等

  • 如果更新你的工资，20k，30k，update table set salary=30 where id=1001，这就不需要幂等

  • 如果是自增方式：update table set salary+10 where id=1001，需要设计幂等

• Insert：由于是新增操作没有唯一单号，就需要通过token的形式使用幂等

• 混合操作：如果这一组业务有一个唯一单号，就可以使用这个单号进行锁操作，如果没有就需要增肌token进行幂等设计

4. 幂等性的具体设计分析

• 修改操作的幂等设计

  • 修改数据前一定是先查询并获得数据了

  • 获得的数据里要加上版本号version、update_time

  • 修改的时候使用这个version作为条件，如果条件不符更新肯定不成功

  • 更新同时变更version

  • 实际上就是使用了乐观锁和update行锁实现幂等

• insert操作的幂等性设计

  • 根据唯一单号进行设计：比如限购，一个用于只能购买一个（uid+pid）给这个组合设置唯一索引

  • 没有唯一单号：用户提交数据或form表单事重复提交导致的数据重复录入

    • 通过token机制来解决

    • 在用户打开表单的同时生成一个唯一序列的token，提交数据时将token传递给后台

    • 对这个token进行加锁控制，未获得锁的操作全部结束业务

    • 为了保证其他重复提交不获得锁，可以不手动释放锁，待其自动超时释放

• 混合操作方式

  • 一整套混合业务操作可以统一使用token机制来加锁进行重复提交限制