基于数据库防止并发问题

基于数据库防止并发问题

防止并发插入

并发插入会导致数据重复，所以解决并发插入也就是保证幂等。基于数据库的唯一性约束我们就可以保证幂等了。假设交易计费表中唯一键是订单ID+交易类型，则幂等实现流程如下：

1. 根据订单ID和交易类型查询交易计费表

2. 如果已有记录则不用插入，直接返回

3. 如果没有，就执行插入操作

4. 如果有异，则进行重试（MQ重试或者捕获异常再查一次都可以）

5. 没有异常，返回成功

防止并发更新

更新就意味着对临界资源（某一条记录）进行操作，那么很显然我们需要加锁。而数据库中的锁可以分成悲观锁和乐观锁。

悲观锁

悲观锁需要采用加X锁的读，而加X锁的读需要在事务中进行，即需要支持事务的数据库引擎，如MySQL的InnoDB。悲观锁在数据库操作层面来看，有一次加X锁读，一次更新。另外，需要注意加锁是给索引上锁，详见MySQL中行锁真的只锁那一行吗？。

加S锁（Share锁）的读：SELECT … FOR SHARE/SELECT … LOCK IN SHARE MODE。在读取的任何行上设置s锁。其他会话可以读取这些行，比如再次for share读取，但在事务提交之前不能update。

加X锁（eXclusive锁）的读：SELECT… FOR UPDATE。在读取的任何行上设置X锁，不能再加S锁。

悲观锁应用流程如下：

1. 开启事务

2. 尝试加上X锁

3. 加锁失败会阻塞

4. 成功获取锁之后就可以执行后续的update

举个例子：

begin;
select * from order where id = 1 for update;
update order set amount = 10 where id = 1;
commit;

乐观锁

数据库中乐观锁适用于并发冲突较少的时候（所以是“乐观”），这种情况下不需要加锁读，能够提高更新的效率。在创建表时，我们可以在表中新增一列version（版本号），每更新一次+1，每次更新前先查出原纪录得到版本号，然后更新时与当前版本号进行比较，一致才更新。乐观锁在数据库操作层面来看，有一次不加锁读，一次更新。这种乐观锁机制跟CAS类似，但是并不存在ABA的问题，因为只要没有Bug，正常情况下都不会有让version减少的SQL吧…

需要注意的是，乐观锁在冲突多的时候，效率比悲观锁更低，因为大量执行最终会失败的update操作

举个例子：

1. 先查id=1的记录，得到版本号5

2. 更新id=1的记录，在SQL层面比较version是否与预期一致（update order set amount = 10 where id = 1 and version = 5;）

3. 如果version比较成功，数据库返回更新行数 1

4. 如果version比较失败，更新失败，数据库返回更新行数 0

5. 代码里根据返回的更新行数判断更新是否成功

---

如今互联网上各类文章满天飞，但是大部分要不是寥寥数语，让人过目即忘；要不是过多细枝末节又没有实操，让人不知所云。我将从个人学习和工作经历出发，给大家带来深入浅出的技术解析。我的文章力求简短精悍，尽量结合实战，以便大家在碎片时间即可充分吸收，后续还能学以致用。

欢迎大家关注我的微信公众号，所有文章第一时间更新~