mysql处理高并发，防止库存超卖

摘 自: http://blog.csdn.net/caomiao2006/article/details/38568825

 

 

今天王总又给咱们上了一课，其实mysql处理高并发，防止库存超卖的问题，在去年的时候，王总已经提过；可是很惋惜，即便当时你们都听懂了，可是在现实开发中，仍是没这方面的意识。今天就个人一些理解，整理一下这个问题，并但愿之后这样的课程能多点。

先来就库存超卖的问题做描述：通常电子商务网站都会遇到如团购、秒杀、特价之类的活动，而这样的活动有一个共同的特色就是访问量激增、上千甚至上万人抢购一个商品。然而，做为活动商品，库存确定是颇有限的，如何控制库存不让出现超买，以防止形成没必要要的损失是众多电子商务网站程序员头疼的问题，这同时也是最基本的问题。

从技术方面剖析，不少人确定会想到事务，可是事务是控制库存超卖的必要条件，但不是充分必要条件。

举例：

总库存：4个商品

请求人：a、1个商品 b、2个商品 c、3个商品


程序以下：


beginTranse(开启事务)

try{


    $result = $dbca->query('select amount from s_store where postID = 12345');

    if(result->amount > 0){

        //quantity为请求减掉的库存数量


        $dbca->query('update s_store set amount = amount - quantity where postID = 12345');


    }


}catch($e Exception){

    rollBack(回滚)


}


commit(提交事务)


以上代码就是咱们平时控制库存写的代码了，大多数人都会这么写，看似问题不大，其实隐藏着巨大的漏洞。数据库的访问其实就是对磁盘文件的访问，数据库中的表其实就是保存在磁盘上的一个个文件，甚至一个文件包含了多张表。例如因为高并发，当前有三个用户a、b、c三个用户进入到了这个事务中，这个时候会产生一个共享锁，因此在select的时候，这三个用户查到的库存数量都是4个，同时还要注意，mysql innodb查到的结果是有版本控制的，再其余用户更新没有commit以前(也就是没有产生新版本以前)，当前用户查到的结果依然是就版本；

而后是update，假如这三个用户同时到达update这里，这个时候update更新语句会把并发串行化，也就是给同时到达这里的是三个用户排个序，一个一个执行，并生成排他锁，在当前这个update语句commit以前，其余用户等待执行，commit后，生成新的版本；这样执行完后，库存确定为负数了。可是根据以上描述，咱们修改一下代码就不会出现超买现象了，代码以下：

beginTranse(开启事务)

try{

    //quantity为请求减掉的库存数量
    $dbca->query('update s_store set amount = amount - quantity where postID = 12345');

    $result = $dbca->query('select amount from s_store where postID = 12345');

    if(result->amount < 0){

       throw new Exception('库存不足');


    }


}catch($e Exception){

    rollBack(回滚)


}


commit(提交事务)




另外，更简洁的方法：



beginTranse(开启事务)

try{

    //quantity为请求减掉的库存数量
    $dbca->query('update s_store set amount = amount - quantity where amount>=quantity and postID = 12345');

}catch($e Exception){

    rollBack(回滚)


}


commit(提交事务)


=====================================================================================

1、在秒杀的状况下，确定不能如此高频率的去读写数据库，会严重形成性能问题的
必须使用缓存，将须要秒杀的商品放入缓存中，并使用锁来处理其并发状况。当接到用户秒杀提交订单的状况下，先将商品数量递减（加锁/解锁）后再进行其余方面的处理，处理失败在将数据递增1（加锁/解锁），不然表示交易成功。
当商品数量递减到0时，表示商品秒杀完毕，拒绝其余用户的请求。





2、这个确定不能直接操做数据库的，会挂的。直接读库写库对数据库压力太大，要用缓存。
把你要卖出的商品好比10个商品放到缓存中；而后在memcache里设置一个计数器来记录请求数，这个请求书你能够以你要秒杀卖出的商品数为基数，好比你想卖出10个商品，只容许100个请求进来。那当计数器达到100的时候，后面进来的就显示秒杀结束，这样能够减轻你的服务器的压力。而后根据这100个请求，先付款的先得后付款的提示商品以秒杀完。




3、首先，多用户并发修改同一条记录时，确定是后提交的用户将覆盖掉前者提交的结果了。

这个直接可使用加锁机制去解决，乐观锁或者悲观锁。
乐观锁，就是在数据库设计一个版本号的字段，每次修改都使其+1，这样在提交时比对提交前的版本号就知道是否是并发提交了，可是有个缺点就是只能是应用中控制，若是有跨应用修改同一条数据乐观锁就没办法了，这个时候能够考虑悲观锁。
悲观锁，就是直接在数据库层面将数据锁死，相似于oralce中使用select xxxxx from xxxx where xx=xx for update，这样其余线程将没法提交数据。
 除了加锁的方式也可使用接收锁定的方式，思路是在数据库中设计一个状态标识位，用户在对数据进行修改前，将状态标识位标识为正在编辑的状态，这样其余用户要编辑此条记录时系统将发现有其余用户正在编辑，则拒绝其编辑的请求，相似于你在操做系统中某文件正在执行，而后你要修改该文件时，系统会提醒你该文件不可编辑或删除。




4、不建议在数据库层面加锁，建议经过服务端的内存锁（锁主键）。当某个用户要修改某个id的数据时，把要修改的id存入memcache，若其余用户触发修改此id的数据时，读到memcache有这个id的值时，就阻止那个用户修改。




5、实际应用中，并非让mysql去直面大并发读写，会借助“外力”，好比缓存、利用主从库实现读写分离、分表、使用队列写入等方法来下降并发读写。