并发情况下幂等性(&多次提交问题) 处理

在工作中经常遇到数据重复的问题，产生的脏数据有的影响比较小，有的就影响比较大了。最近遇到这个问题，就记录一下，并附上解决方案。一起干饭！

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

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

1.幂等性概念

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

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

2.什么情况下需要幂等性

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

并不是所有的业务都需要幂等性，要根据实际业务确定是否需要幂等性。在我看来，幂等性的重点还是外界对接口的干扰性问题。

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

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

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

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

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

• 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进行幂等设计

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

• 修改操作的幂等设计

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

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

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

  • 更新同时变更version

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

• insert操作的幂等性设计

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

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

    • 通过token机制来解决

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

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

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

• 混合操作方式

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

6. 利用spring AOP /Redis 实现各种情况下 防止接口重复提交问题

实现各种情况下 防止接口重复提交问题。