个人中心
gpt4 book ai didi

分析Mysql事务和数据的一致性处理问题

转载 作者：qq735679552 更新时间：2022-09-29 22:32:09 25 4
gpt4 key购买 nike

CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章分析Mysql事务和数据的一致性处理问题由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

这篇文章通过安全性，用法，并发处理等方便详细分析了Mysql事务和数据的一致性处理问题，以下就是全部内容:

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

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

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

举个例子

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

?
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 就可以这样测试，代码如下

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

  。

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

?
1
SELECT * FROM products WHERE id=3 FOR UPDATE

  。

如此可以确保quantity 在别的事务读到的数字是正确的.

?
1
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 的说明，以免造成系统经常发生死锁.

更高级用法 。

如果我们需要先查询，后更新数据的话，最好可以这样使用语句:

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

  。

这样，可以不用添加事物就可处理.

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

看到了一篇非常好的文章，特转此学习.

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

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

从技术方面剖析，很多人肯定会想到事务，但是事务是控制库存超卖的必要条件，但不是充分必要条件.

举例:

总库存：4个商品 。

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

程序如下:

?
1
2
3
4
5
6
7
8
9
10
11
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后，生成新的版本；这样执行完后，库存肯定为负数了。但是根据以上描述，我们修改一下代码就不会出现超买现象了，代码如下:

?
1
2
3
4
5
6
7
8
9
10
11
12
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(提交事务)

  。

另外，更简洁的方法:

?
1
2
3
4
5
6
7
8
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去直面大并发读写，会借助“外力”，比如缓存、利用主从库实现读写分离、分表、使用队列写入等方法来降低并发读写.

悲观锁和乐观锁 。

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

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

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

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

实战 。

分析Mysql事务和数据的一致性处理问题

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

第一个窗口A,

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

第二个窗口B:

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

  。

我们可以看到窗口A加了事物，锁住了这条数据，窗口B执行时会出现这样的问题:

分析Mysql事务和数据的一致性处理问题

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

?
1
2
3
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处理高并发，防止库存超卖，以上就是本篇文章的全部内容，如果大家还有不明白的可以在下方留言讨论.

原文链接：https://segmentfault.com/a/1190000012469586 。

最后此篇关于分析Mysql事务和数据的一致性处理问题的文章就讲到这里了,如果你想了解更多关于分析Mysql事务和数据的一致性处理问题的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。

25 4 0
文章推荐： 我的电脑图标没了怎么办？windows 10我的电脑怎么放在桌面上？
文章推荐： 用shell写一个mysql数据备份脚本
文章推荐： MySQL的慢日志线上问题及优化方案
文章推荐： 2021一组充满艺术感很有个性的头像 人间百态各有不同
qq735679552
个人简介

我是一名优秀的程序员,十分优秀！

滴滴打车优惠券免费领取
滴滴打车优惠券
全站热门文章
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com