解决超卖问题,常见的方式,利用redis 的原子性去递减;利用队列,队列入队计数。或者直接打到mysql 层。由mysql 保证不超卖,有几个玩法。利用属性不一样,挺有意思,记录下。
该文章后续仍在不断的更新修改中, 请移步到原文地址http://www.dmwan.cc/?p=139&preview=true
首先,mysql 隔离级别是RR,或者是串行,但是不可能用串行,太慢。
其次,为什么会出现超卖问题?因为这个select and update 是个非原子操作,是两步操作。
最后,怎么解决这个问题? 就在原子性上做文章,比如redis 的 lua 封装,将指令封装成原子操作。或者mysql 的互斥锁,再或者,干脆允许超卖,业务层做二次检查。
第一种,mysql 在select 的时候不加互斥锁,这个时候的做法:
1:开启事务
2:查询库存,并显示的设置写锁(排他锁):SELECT * FROM table_name WHERE …
3:生成订单
4:去库存,隐示的设置写锁(排他锁):UPDATE goods SET counts = counts – 1 WHERE id = 1
5:commit,释放锁
这里提下mysql 的RC 和RR 区别,mysql 是如何实现可重复读的? RR隔离级别是在事务开始时刻,确切地说是第一个读操作创建read view的;RC隔离级别是在语句开始时刻创建read view的。一个read view 可以理解成一份快照(底层只是事务id 列表),所以,RC 隔离级别下,多次读可能受其他事务commit 导致读取数据不一致。
那么 RR 级别下,select 和 update 的时候, 数据是一个version的,但是上面做法的问题,就在于,几个事务begin 后,都读到数据为1,就开始 update ,就会导致数据最终为负数,这种方式,避不了为负数。
我们可以做个二次容错,检查update 后数据为负数后,直接回滚这次事务即可。
第二种方式是select 的时候就加行锁,select for update ,直接锁住这条记录,不让其他事务读。所以对这个数据,都成串行,这个缺点就是会影响性能,但是不会出现超卖的情况了。
1:开启事务
2:查询库存,并显示的设置写锁(排他锁):SELECT * FROM table_name WHERE … FOR UPDATE
3:生成订单
4:去库存,隐示的设置写锁(排他锁):UPDATE goods SET counts = counts – 1 WHERE id = 1
5:commit,释放锁。
第三种,试着给select 加读锁,这种做法是不行,会出现死锁,什么情况会死锁呢?事务1,2同时加读锁,事务1加写锁等事务2的写锁,事务2的加写锁等事务1的读锁,相互等待,陷入死锁。那为啥 select for update 不会这样,因为mysql 互斥锁是可重入锁啊。