Mysql 事务及数据的一致性处理

在工做中，咱们常常会遇到这样的问题，须要更新库存，当咱们查询到可用的库存准备修改时，这时，其余的用户可能已经对这个库存数据进行修改了，致使，咱们查询到的数据会有问题，下面咱们就来看解决方法。

在MySQL的InnoDB中，预设的Tansaction isolation level 为REPEATABLE READ（可重读）

若是SELECT 后面若要UPDATE 同一个表单，最好使用SELECT ... UPDATE。

举个例子:

　　假设商品表单products 内有一个存放商品数量的quantity ，在订单成立以前必须先肯定quantity 商品数量是否足够(quantity>0) ，而后才把数量更新为1。代码以下:

SELECT quantity FROM products WHERE id=3; UPDATE products SET quantity = 1 WHERE id=3;

为何不安全呢?

少许的情况下或许不会有问题，可是大量的数据存取「铁定」会出问题。若是咱们须要在quantity>0 的状况下才能扣库存，假设程序在第一行SELECT 读到的quantity 是2 ，看起来数字没有错，可是当MySQL 正准备要UPDATE 的时候，可能已经有人把库存扣成0 了，可是程序却浑然不知，将错就错的UPDATE 下去了。所以必须透过的事务机制来确保读取及提交的数据都是正确的。

因而咱们在MySQL 就能够这样测试，代码以下:

SET AUTOCOMMIT=0; BEGIN WORK; SELECT quantity FROM products WHERE id=3 FOR UPDATE;

此时products 数据中id=3 的数据被锁住(注3)，其它事务必须等待这次事务 提交后才能执行

SELECT * FROM products WHERE id=3 FOR UPDATE

如此能够确保quantity 在别的事务读到的数字是正确的。

UPDATE products SET quantity = '1' WHERE id=3 ; COMMIT WORK;

提交(Commit)写入数据库，products 解锁。
注1: BEGIN/COMMIT 为事务的起始及结束点，可以使用二个以上的MySQL Command 视窗来交互观察锁定的情况。
注2: 在事务进行当中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一笔数据时会等待其它事务结束后才执行，通常SELECT ... 则不受此影响。
注3: 因为InnoDB 预设为Row-level Lock，数据列的锁定可参考这篇。
注4: InnoDB 表单尽可能不要使用LOCK TABLES 指令，若情非得已要使用，请先看官方对于InnoDB 使用LOCK TABLES 的说明，以避免形成系统常常发生死锁。

更高级用法

若是咱们须要先查询，后更新数据的话，最好能够这样使用语句：

UPDATE products SET quantity = '1' WHERE id=3 AND quantity > 0;

这样，能够不用添加事物就可处理。

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

看到了一篇很是好的文章，特转此学习。

今天王总又给咱们上了一课，其实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（加锁/解锁），不然表示交易成功。
当商品数量递减到0时，表示商品秒杀完毕，拒绝其余用户的请求。

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

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

这个直接可使用加锁机制去解决，乐观锁或者悲观锁。
乐观锁:，就是在数据库设计一个版本号的字段，每次修改都使其+1，这样在提交时比对提交前的版本号就知道是否是并发提交了，可是有个缺点就是只能是应用中控制，若是有跨应用修改同一条数据乐观锁就没办法了，这个时候能够考虑悲观锁。

悲观锁:，就是直接在数据库层面将数据锁死，相似于oralce中使用select xxxxx from xxxx where xx=xx for update，这样其余线程将没法提交数据。

除了加锁的方式也可使用接收锁定的方式，思路是在数据库中设计一个状态标识位，用户在对数据进行修改前，将状态标识位标识为正在编辑的状态，这样其余用户要编辑此条记录时系统将发现有其余用户正在编辑，则拒绝其编辑的请求，相似于你在操做系统中某文件正在执行，而后你要修改该文件时，系统会提醒你该文件不可编辑或删除。

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

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

悲观锁和乐观锁

首先，多用户并发修改同一条记录时，确定是后提交的用户将覆盖掉前者提交的结果了。这个直接可使用加锁机制去解决，乐观锁或者悲观锁。

　　悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，因此每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了不少这种锁机制，好比行锁，表锁等，读锁，写锁等，都是在作操做以前先上锁。

　　乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，因此不会上锁，可是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可使用版本号等机制。乐观锁适用于多读的应用类型，这样能够提升吞吐量，像数据库若是提供相似于write_condition机制的其实都是提供的乐观锁。

　　两种锁各有优缺点，不能单纯的定义哪一个好于哪一个。乐观锁比较适合数据修改比较少，读取比较频繁的场景，即便出现了少许的冲突，这样也省去了大量的锁的开销，故而提升了系统的吞吐量。可是若是常常发生冲突（写数据比较多的状况下），上层应用不不断的retry，这样反而下降了性能，对于这种状况使用悲观锁就更合适。

实战

对这个表的 amount 进行修改，开两个命令行窗口

第一个窗口A;

SET AUTOCOMMIT=0; BEGIN WORK; SELECT * FROM order_tbl WHERE order_id='124' FOR UPDATE;

第二个窗口B：

# 更新订单ID 124 的库存数量
UPDATE `order_tbl` SET amount = 1 WHERE order_id = 124;

咱们能够看到窗口A加了事物，锁住了这条数据，窗口B执行时会出现这样的问题：

第一个窗口完整的提交事物：

SET AUTOCOMMIT=0; BEGIN WORK; SELECT * FROM order_tbl WHERE order_id='124' FOR UPDATE;
UPDATE `order_tbl` SET amount = 10 WHERE order_id = 124;
COMMIT WORK;

---

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