[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

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