行锁

MySQL的行锁都是在引擎层实现的，但是 MyISAM 不支持行锁，意味着并发控制只能使用表锁，同一张表任何时刻只能被一个更新在执行，影响到业务并发度。InnoDB 是支持行锁的，这也是 MyISAM 被 InnoDB 替换的重要原因之一。

行锁就是针对数据库中表的行记录的锁，这很好理解，比如事务 A 更新了一行，而这时候，事务 B 也要更新一行，则必须等事务 A 的操作完成后才能更新。

两阶段锁

先举个例子，假设有一个表 t，主键是 id，其中一个字段是 k，在下面的操作中，事务 B 的 update 语句执行时，会是什么现象呢 ？说明：红色表示事务 A，黄色表示事务 B：

这个问题的结论取决于事务 A 执行完前两条语句后，持有哪些锁，以及在什么时候释放。

实际上，事务 A 持有两个记录的行锁，都是在 commit 的时候才释放的，所以事务 B 的 update 就会被阻塞，直到事务 A 执行 commit 之后，事务 B 才能被继续执行。也就是说，在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，需要等事务结束时才释放，这就是两阶段锁协议，分为加锁阶段和解锁阶段，所有的 lock 操作都在 unlock 操作之后。

假设你负责实现一个电影票在线交易业务，顾客 userA 要在影院 cinema 购买电影票，需要涉及以下操作：

扣除顾客 userA 账户余额

增加影院 cinema 账户余额

记录一条交易日志

也就是说，完成这次交易，需要 update 两条记录，并 insert 一条记录。当然为了保证交易的原子性，我们需要这三个操作放在一个事务中。与此同时，还有顾客 userB 也在影院购买电影票，那么你会怎样安排这三个语句在事务中的顺序呢？

首先发现冲突的部分是语句 2，就是两个事务都要给 cinema 的账户余额增加电影票价。根据两阶段协议，不论怎么安排语句，所有的操作需要的行锁都是在事务提交的时候才释放的，要想使行锁在事务中不会停留太长时间，最大程度的减少了事务之间的锁等待，应该把语句 2 放在最后面。如下图所示：

死锁

如下图所示，事务 A 在等待事务 B 释放 id = 2 的行锁，而事务 B 在等待 事务 A 释放 id = 1 的行锁，事务 A 和事务 B 在互相等待对方的资源释放，就是进入了死锁状态。

在并发系统中，不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程进入无限等待的状态，成为死锁。

当进入死锁状态时，有下列 2 种策略：

通过 innodb_lock_wait_timeout 来设置超时时间，InnoDB 中默认值是 50s，第一个被锁住的事务 A 等待超过 50s 才会超时退出，其他事务才能得以执行，对于在线服务来说，这个等待时间往往是无法接受的。如果设置太短 1s，可能有的事务只是简单的锁等待，就被退出了，会出现很多误伤。

通过设置 innodb_deadlock_detect = on，发起死锁检测，发现死锁之后主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。比如回滚事务 A，让事务 B 继续执行。

死锁检测

正常情况下使用第 2 种策略的，但是快速发现死锁并进行处理，也是有额外负担的。你可以想象一下这个发现死锁的过程：每当一个事务被锁的时候，就要看看他依赖的线程有没有被别人锁住，判断是否出现了循环等待，也就是死锁。

假设有 1000 个并发线程，都要同时更新同一行，第 1 个线程来的时候检测数是 0；第 2 个线程来的时候，需要检测【线程1】有没有被别人锁住；第 3 个线程来的时候，需要检测【线程1，线程2】有没有被其他线程锁住，以此类推，第 n 个线程来的时候，检测数是 n - 1，所以总的检测数是 0 + 1 + 2 + 3 + 。。。+ (n - 1) = n(n -1)/2，所以时间复杂度应该是 O(n²)。

也就是 1000 个并发线程同时操作同一行，那么死锁检测操作就是 100 万这个量级的，虽然最终检测的结果是没有死锁，但是这期间要消耗大量的 CPU 资源，就会看到 CPU 利用率很高，但是每秒却执行不了几个事务。

那么怎么处理这种热点行更新导致的性能问题呢？

如果你能确定这个业务一定不会出现死锁，可以临时把死锁关掉，这种操作带有一定风险，因为业务设计的时候一般不会把死锁当成一个严重错误，毕竟出现死锁了，就回滚，然后通过业务重试一般就没有问题了，这是业务无损的，而关掉死锁检测意味着可能出现大量超时，这是业务有损的。

控制并发度，比如同一行最多只有 10 个线程在更新，这样死锁检测的成本很低，一个直接的想法就是在客户端做并发控制。可是如果客户端有 600 个，即使每个客户端控制到只有 5 个线程，汇总到数据库服务端以后，峰值并发数也有可能达到 3000。因此这个并发控制要在服务端，比如引入中间件来实现，在进入引擎之前排队。

将一行改成逻辑上的多行来处理，比如影院的账户余额等于 10 行记录的值总和，这样每次给影院账户加金额的时候，随机选取其中一条记录来加，冲突概率变为原来的1/10，减少锁的等待个数，也就减少了死锁检测的 CPU 消耗。这个方案看上去是无损的，但是需要根据业务逻辑做详细设计。如果账户余额减少，比如退票，这个时候就要考虑当一部分行记录变为 0 的时候，代码要有特殊处理。

————————————————

版权声明：本文为CSDN博主「笙南」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/weixin_38118016/article/details/90271468