00:00
MYSQL悲观锁,也就是这个select for update,那我们演示完之后呢,我们来去分析一下它都给我们解决了什么问题。然后又带来了一些什么新的问题?那么首先呢,它可以解决同一个商品有多条库存记录时,咱一个SQL语句束手无策这个问题。他用他就没办法了。但是如果我用0FOR update的话,那就很灵活了,我可以呢,先根据商品编号来去查询我们的库存记录。那么查询到之后呢,通过程序来去分析。啊,你可以是框架来去分析,你也可以是大数据的分析,你也可以呢,是代码来处理。那么总之呢,处理方式呢,多种多样。它更加灵活。然后最终呢,从一个仓库中为减库存就可以了。那么然后呢,我们来看它还可以解决什么问题呢?才可以解决无法记录库存前后变化前后的一个状态。
01:03
那么以前咱是一个词后语句是无法记录的,但现在呢,我们想在任何地方记录都可以。在减库存之前,我们可以呢去记录库存里面的库存状态。那么在减完库存之后呢,我依然可以去记录咱库存里面的库存状态,有多少件库存。是可以记录的。所以呢,咱们这种玩法呢,更加灵活,更加方便。那么它适用场景呢,就更加广泛啊。现在许多大厂啊,往往呢,哎,他们这种方式可能更加适合一点。那如果我只是简单的减一下库存,库存就一条,那你确实呢,使用这种方式呢,性能会更高一些。那么,被关所是不是只有优点没有缺点了呢?他缺点呢,其实也很明显。首先并发量我们可以看出来,它比我们的即便本地所性能稍微高一点啊,即便本利所呢,它应该是不到600的喷吐量。
02:04
啊,那么我们的悲管所呢,比它稍微好一点,可能接近更加接近于600了,600左右的吞吐量。但是呢,比我们的一个SQL语句判断时呢,要低很多。要低,所以性能呢较低啊,再呢,我们来列举一下它的问题,那么第一个问题呢,就是咱刚才了解的咱聊到的性能问题。性能问题,那并发量呢,明显受到了影响。那么第二个问题呢,就是咱聊到锁,就不得不去聊死锁问题啊死锁问题。那我们在加速的过程中,必须要保证我们加锁的顺序要一致。啊,加锁顺序那么要一致,特别是你对多条数据加锁的时候,那加锁顺序呢,一定要一致啊,对多条数据加锁时。
03:03
加锁时要保证加锁顺序一致。那么这个呢,咱可以去演示一下,如果你的加锁顺序不一致。他可能会怎么样?好,我们回到咱们这个客户端里面去啊,首先我在一这个客户端里面开启一个事务,开启完事务之后呢,我们开始去执行一个,那么加锁操作,来一个select星,From DB talk,围绕ID等于一,比如说我就对一这条记录查询,并且加速来一个for update。二一回车,那么一这条记录呀,就被我给查询并且去加锁了啊。那同时我可能也要对二这条季度来进行加速。那么在他加锁的时候呢,可能一啊二这个客户端也来了。那么二后这个后端在干什么事情呢?他也去开启了一个实物。
04:02
那么同时也去执行加锁操作啊。加速操作,但是呢,它加速操作的时候呢,它锁的水道锁的是二这条记录,因为他锁的是二。锁二,那么锁二之后呢?来看啊,一此时它锁的是一这条记路,二呢,锁的是二这条记路。那么紧接着他们俩呢,都想对这两条记录来进行加锁啊,只是呢,一先加了,先加锁了这个这条记录,紧接着开始加这条记录。啊,来,去获取他的锁。那么此时呢,大家一看啊,一这个后后端开始对二阶的机动应加锁了,它已经融有一的锁了。I等于一最小记度的锁了,然后开始想去获取二的负,那么一回车。逆回车怎么样呢?被阻塞住了。那么此时二这个客户端啊,仍有ID等于二的这条记录的所。
05:01
他他想怎么样呢?他想获取一的锁。那么此时呢,查询一这条库存,并且呢,对它进行加锁,那我一回撤怎么样。哎,报错了对吧,啊报思索问题了。那么如果我们对多条记录加速的时候。而这多条记录的加锁顺序不一样。就有可能会产生思索。所以呢,咱们使用这个东西的时候呀,也要注意。好,那么然后第三种情况就是我们的库存操作要统一啊,第三个啊。第三个问题,第三个问题,那么的库存操作要统一。那么如果我们的put操作不统一啊,有的时候呢,我们使用的是select,然后呢,是啊是新啊select,然后from。啊,For update对吧,For update我们使用这个,那么有的时候呢,我们可能使用的是select,没有for update使用的是普通的啊。
06:10
普通的L。那它能锁住吗?就锁不住了,它相互之间就锁不住了啊。因为我库存操作除了减库存之外,那我们可能将来还有什么呢,还有出库入库什么之类的呢。所以扩员操作呢,不能单独就是减构成。那么其他操作万一在操作过程中影响到我的减库存了呢?这是很有可能的。所以呢,咱们要统一规范啊,全部都要去使用for update,以避免出现闭环性的问题。在操作上呢,要统一啊。好,这是咱们这个MYSQL备关所。啊,他的一个问题。那比如说大家可以去演示一下啊,演示一下咱来两个客户端,我把这两个呢全部都给它释放掉,来一个roll back回滚一下。
07:03
啊,那么然后呢,这个呢,也是一样,Roll back回滚一样,这两个锁呢,应该都释放掉了啊。那么高吃完量之后呢,我们来去。看一下啊,我先在一里面,那么来去开启实物。比如说我一这个客户端我来执行了啊,加锁这个操作啊,ID等于1FOR update。我执行了一个加锁操作。那么二这个客户端呢。他可能就没有执行加锁操作。那直接呢,就啥呢,就是比如说开启一个事物了,开启完事物之后呢,谁就死了一个什了啊随给查了,然后呢,From DB stock,那we ID哪等于一。那么此时怎么样呢?是依然可以查询成功啊。啊,他依然可以查询到这个库存。那假如他他在这个库存的基础上来操作的话。
08:00
那么就出问题了呀,那他操作完了,那我这边呢,也是无法感知的啊,另外一个客户端是无法感知的。所以可能会引发并发性的问题。好,那么这是闭关所所存在的三个问题呢?我们就分析完了。
我来说两句