关于update操作并发问题

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于update操作并发问题相关的知识,希望对你有一定的参考价值。

在高并发的场景下,经常会遇到这种情况:
A请求过来,查询出来一条数据,进行update操作,与此同时B请求也在这个时候过来,对这条数据进行查询,并进行操作。此时就会出现B在A之后进行查询操作,但是实际B的数据却被A覆盖。

表名A,字段名为 number,如下的SQL语句:

甲操作 语句1:select num from store where id=‘1‘;

假设此时甲获取到 num= 99

乙操作 语句2:select num from store where id=‘1‘;

因为甲方还没有update操作,乙获也取到 num= 99
这时候A进行update操作

update store set num =${num} +1 where id=‘1‘;

这时候写入数据库的num即为100
此时B请求也发起了更新操作:

update store set num =${num} +1 where id=‘1‘;

这时候我们的预期本应该是101的,但是实际上B又在数据库写入了100

解决方案:

(1)引入一个版本号的概念,在表A中增加一个version字段

甲操作 语句1:select num,version from store where id=‘1‘;

假设此时甲获取到 num= 99 version =1

乙操作 语句2:select num,version from store where id=‘1‘;

因为甲方还没有update操作,乙获也取到 num= 99 version=1
这时候A进行update操作

update store set num =${num} +1 where id=‘1‘ and version = ${version};

这时候写入数据库的num即为100, version =2
此时B请求也发起了更新操作:

update store set num =${num} +1 where id=‘1‘ and version = ${version} ;

这时候发现条件version = 1不成立,因为上一步操作version已经为2了,所以update无法更新。

(2)解决方式:update A set number=number+1 where id=1; 语句直接处理

表名A,字段名为 number,如下的SQL语句:

语句1:update A set number=number+1 where id=1;
语句2:update A set number=number+2 where id=1;

假设这两条SQL语句同时被mysql执行,id=1的记录中number字段的原始值为99,那么是否有可能出现这种情况:
语句1和2因为同时执行,他们得到的number的值都是99,都是在10的基础上分别加1和2,导致最终number被更新为100或101,而不是102

这个其实就是 关系型数据库本身就需要解决的问题。首先,他们同时被MySQL执行,你的意思其实就是他们是并发执行的,而并发执行的事务在关系型数据库中是有专门的理论支持的- ACID,事务并行等理论,所有关系型数据库实现,包括Oracle, MySQL都需要遵循这个原理。
简单一点理解就是锁的原理。这个时候第一个update会持有id=1这行记录的 排它锁,第二个update需要持有这个记录的排它锁的才能对他进行修改,正常的话, 第二个update会阻塞,直到第一个update提交成功,他才会获得这个锁,从而对数据进行修改。
也就是说,按照关系型数据库的理论,这两个update都成功的话,id=1的number一定会被修改成22。如果不是22, 那就是数据库实现的一个严重的bug。

以上是关于关于update操作并发问题的主要内容,如果未能解决你的问题,请参考以下文章

php并发控制 , 乐观锁

mysql中update的low_priority解决并发问题

通过乐观锁(版本号)降低并发时的锁竞争问题

EFCore乐观并发控制:并发令牌

关于并发

java中怎么实现高并发