PHP8.1.21版本已发布
vue8.1.21版本已发布
jquery8.1.21版本已发布

一起聊聊Mysql两阶段锁和死锁

藏色散人
藏色散人 转载
2022-12-05 15:55:17 1906浏览

本篇文章给大家带来了关于mysql锁的相关知识,其中主要介绍了mysql 两阶段锁和死锁,下面一起来看一下,希望对大家有帮助。

两阶段锁

概念

讲的是InnoDB如何处理行锁的上锁,释放锁的行为。

事务使用过程中,对记录以主键为条件删改时,会立刻加上排他锁,这完成了上锁阶段。

当删改动作完成后,这个锁并不会立即释放,需要等至事务提交时,才会释放锁

引发的问题-阻塞

事务 A事务 B
begin;
update t set k=k+1 where id=1;
update t set k=k+1 where id=2;


begin;
update t set k=k+2 where id=1;
commit;

根据两阶段锁协议,事务 B将会因为id=1的数据被事务 A上了锁,而阻塞,因为事务 B需要拿到锁后才能进行下一步操作。

上述这个问题,可能看似问题不大,但是如果不止是事务 B,还有事务 C事务 D,等等很多,做的是跟事务 B一样的事,问题就大了,被阻塞的线程就会多了起来。【推荐学习:MySQL视频教程

如何处理上述问题

我们应该尽量将可能会引起阻塞的语句,放到事务的最后面操作,例如上述事务 A例子中的id=1的语句,它和第二句的执行并没有什么关联关系,可是它是容易引起阻塞的语句,因为在事务 B中也要对这一行数据做锁操作(在各类事务中频繁使用的,如公司的收付款账号余额记录,即**热点行**),但是却在事务一开始就拿到锁了。

本质上,是缩短了拿锁时间和释放锁之间的时间。即持有锁的时间缩短,以此减少锁引起的阻塞。

死锁

概念

两个线程,互相在等待对方释放资源。

在两个事务A,B中。

  • 事务 A拿到了资源 A的锁。

  • 事务 B拿到了资源 B的锁。

  • 事务 A去拿资源 B的锁。

  • 事务 B去拿资源 A的锁。

很明显,步骤 3,4中,事务 A,B 都想去拿锁,但是又都拿不到,因为对方都还没有释放该资源的锁。这种现象就是死锁。

引发的问题-死锁

InnoDB中,有一个拿锁的等待时间配置,超过这个时间就会抛出异常,这个时间默认是50秒。通常来说,有一个接口需要50秒后才响应是不可接受的。innodb_lock_wait_timeout

那是不是把这个配置时间设置短一点就行了?比如1秒?

应该是不可以的,因为可能会影响到你的正常业务,或许你的业务导致你的事务执行时间本身就比较长,超过1秒。超出这个时间会抛出异常,你的正常业务就被影响了。

那该如何处理上述问题

InnoDB中,还有一个自动检测死锁并处理的配置。它是默认开启的,在极端情况下,虽然能处理问题,但是对CPU消耗特别大。

它原理是在事务中即将要上锁的时候,会去检测其他并发线程,有没有将此资源锁住,如果检测到某个线程A有,然后再会去检测线程A的依赖有没有被其他并发线程锁住,如此循环往复,最终判断这些锁会不会形成死锁。

可以看出,线程越多,检测成本就越大。innodb_deadlock_detect

仅代表个人当前的学习做出的对此问题的处理和总结:

1.关闭死锁检测,将拿锁时间配置缩短至预估的最高时间,通常不会超过15秒,超过15秒后,需要有重试机制。

2.开启死锁检测,在应用层控制并发连接数,使用连接池控制Mysql的连接数,在服务层限制Mysql最大连接数。

以上是对怎样减少行锁性能影响的学习总结。

声明:本文转载于:learnku,如有侵犯,请联系admin@php.cn删除