mysql 解决超卖问题的锁分析

    解决超卖问题，常见的方式，利用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 互斥锁是可重入锁啊。