重复插入问题

很多业务场景下，我们需要记录有唯一性，不允许重复插入。一般业务代码的逻辑通常是先查询，表记录存在则返回，不存在则插入数据。

但是在高并发场景下，多个线程同时进行查询，都查询到没有记录，随后都进行插入，这样就会出现需要唯一记录的重复插入。

解决方案

方案一： 使用悲观锁/分布式锁

该方案实现简单，但很影响性能。

方案二： 唯一性约束

使用 唯一性约束 ，业务代码通过捕获唯一性约束冲突的异常进行处理。但如果表设计中存在状态字段，唯一约束是某种状态的约束，那么添加唯一性约束的方式就不可行了。

方案三： 更改 sql

insert into [Table] (a,b) select 'v1','v2' from [Table] 
where not exist (select id from [Table] where a = 'v1' and b = 'v2');

这种方式是比较简单的，业务代码可以通过返回值来做后续逻辑处理。

方案四： 做接口访问次数限制

这种方案是限制接口在短时间内被多次调用，如果业务上能确定接口不可能在很短时间内使用相同参数调用，完全可以做限制。

缺点是需要额外设计接口重复调用拦截处理。

方案五： insert on duplicate key update

mysql中支持这个语法：

insert into table1 (xx,xxx) values (xx,xxx) on duplicate key update

在添加数据时，mysql发现数据不存在，则直接insert。如果发现数据已经存在了，则做update操作。不过要求表中存在唯一索引或 PRIMARY KEY，这样当这两个值相同时，才会触发更新操作，否则是插入。

此外，insert on duplicate key update 在高并发的情况下，可能会产生死锁。

方案六： insert ignore

mysql中支持这个语法：

insert ignore into table1 (xx,xxx) values (xx,xxx)

在insert语句执行的过程中：mysql发现如果数据重复了，就忽略，否则就会插入。它主要是用来忽略，插入重复数据产生的 Duplicate entry 'XXX' for key 'XXXX'异常的。不过也要求表中存在唯一索引或 PRIMARY KEY。

另外，使用 insert ... ignore 也有可能会导致死锁。

方案七： 防重表

添加一张防重表，表中设置不可重复字段为唯一索引列。

业务中在添加数据前，先添加防重表。如果添加成功，说明可以正常添加商品；如果添加失败，说明有重复数据。

高并发下更新同一行数据

方案一： 使用悲观锁

悲观锁当前只有一个线程执行操作，排斥外部请求的修改。遇到加锁的状态，就必须等待。结束了唤醒其他线程进行处理。虽然可以解决数据安全问题，但在高并发下，很多请求都在锁等待，某些线程可能永远没机会抢到锁，性能极差。

方案二： FIFO缓存队列

直接将请求放入队列中，就不会导致某些请求永远获取不到锁。解决了锁的问题，全部请求采用“先进先出”的队列方式来处理。高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，但队列内的请求可能会越来越多，系统响应时间还是会大幅下降。

方案三： 使用乐观锁

通过使用 “版本号（version）”机制。这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功。综合来说，这是一个比较好的解决方案。