高并发重复插入数据的场景之一

场景：淘宝平台推送退款工单时，会在工单状态变更时，再次推送来更新工单数据。但是会出现状态A退款工单推送过来，立马变更状态A为状态B，会再次推送该条状态B的工单，B进来首先查找系统中是否有该条工单，而这时状态A的工单还没有完成插入的逻辑，状态B会认为之前这笔工单没有推送过，会直接执行插入的逻辑，这就导致插入了重复数据。

这里最初的实现方式，实际上就可以算作是数据库乐观锁的方式，乐观的认为数据每次插入，都很大概率不会出现并发，所以每次插入之前，都先查询下数据库是否有这条数据，或者是该条数据上的version是不是最新的。

而解决方案就要采取悲观锁的思想，什么是悲观锁呢？悲观锁认为每次插入数据都会很大概率的出现并发。一般实现悲观锁，从数据库的层面考虑，就是对数据加锁。

解决方案：新增一张数据库表，用工单的id作为主键，每次工单进入系统时，首先在事务中（针对在程序代码中使用事务 + 锁的方式，也有一些坑点 https://blog.csdn.net/u010372981/article/details/81291783 在我的这篇博客中，举例了一种经常会出现的坑点）对这种新增的数据库表进行insert into ... on dumplicate key，产出数据库的锁，再执行业务逻辑的插入，可以理解将几乎并行过来的两条不同状态的相同工单改为串行处理，先进来的工单先锁住，执行插入的逻辑，插入完成之后释放锁，再执行下一条工单数据，执行时先判断系统是否存在这条工单，存在的话就正常执行更新逻辑即可。