黄东旭解析 TiDB 的核心优势
687
2023-11-19
本篇内容主要讲解“Mysql两阶段锁和死锁是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Mysql两阶段锁和死锁是什么”吧!
概念
讲的是InnoDB如何处理行锁的上锁,释放锁的行为。
在事务使用过程中,对记录以主键为条件删改时,会立刻加上排他锁,这完成了上锁阶段。
当删改动作完成后,这个锁并不会立即释放,需要等至事务提交时,才会释放锁。
引发的问题-阻塞事务 A事务 Bbegin;
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一样的事,问题就大了,被阻塞的线程就会多了起来。
如何处理上述问题我们应该尽量将可能会引起阻塞的语句,放到事务的最后面操作,例如上述事务 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最大连接数。
到此,相信大家对“Mysql两阶段锁和死锁是什么”有了更深的了解,不妨来实际操作一番吧!这里是网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。