[MySQL]简单理解并发下的CAS比较交换和ABA问题

1.在下面并发业务场景

库存业务,stock(id, num),其中:

id为库存id 是      1

num为库存值是 5

2.并发下查询

select num from stock where id=1

select num from stock where id=1

得到的值都是5 , 没有问题

3.并发修改

---->用户1 :先查询库存是5

update stock set num=2 where id=1

---->用户2 :先查询库存是5

update stock set num=3 where id=1

并发下 , 库存实际上变成了2或者3 , 这就不符合逻辑 ,应该变成0 , 因为卖出了5件商品

4.CAS优化

update stock set num=$num_new where id=1 and num=$num_old

只有当库存是最开始查询出的库存值时才允许修改

5. ABA问题

考虑如下操作:

并发1(上):获取出数据的初始值是A,后续计划实施CAS乐观锁,期望数据仍是A的时候,修改才能成功

并发2:将数据修改成B

并发3:将数据修改回A

并发1(下):CAS乐观锁,检测发现初始值还是A,进行数据修改

并发1在修改数据时,虽然还是A,但已经不是初始条件的A了,中间发生了A变B,B又变A的变化,此A已经非彼A,数据却成功修改,可能导致错误

ABA问题导致的原因,是CAS过程中只简单进行了“值”的校验,再有些情况下,“值”相同不会引入错误的业务逻辑(例如库存),有些情况下,“值”虽然相同,却已经不是原来的数据了。

6.使用版本号机制解决ABA问题

库存的并发读写例子,引入版本号的具体实践如下:

(1)库存表由

stock(id, num)

升级为

stock(id, num, version)

 

(2)查询库存时同时查询版本号

select num, version from stock where id=$id

使用版本号比对并修改 , 版本号可以每次修改都+1

update stock set num=$num_new, version=$version_new where id=$id and version=$version_old

修改失败的要有重试机制 , 客户就无感知了

posted @ 2021-03-11 10:37  陶士涵  阅读(26)  评论(0编辑  收藏