问题引入

我们都知道事务的四大特性，ACID，原子性、一致性、隔离性、持久性。那么事务是如何实现这样的特性的呢？其中原子性通过redo、undo、binlog日志来实现；持久性通过mysql底层的刷磁盘机制实现；隔离性通过MVCC多版本快照读实现；但是数据的一致性如何实现呢？通过什么样的锁机制？如何把一个事务中的多个写操作放到一个锁中呢？每个写操作的锁是如何加的？如何释放的？

此篇博客主要是讲述MySql(仅限innodb)的两阶段加锁(2PL)协议,而非两阶段提交(2PC)协议,区别如下：

2PL,两阶段加锁协议：指的是单机事务中的加锁机制。

2PC,两阶段提交协议：主要用于分布式事务中，通过对每个数据库事务之间的协调来达到分布式事务效果。

什么时候会加锁

在 select for update、lock in share model 时，update, delete 等操作时 ，会对记录加锁（有共享锁、排它锁、意向锁、gap锁、nextkey锁等等），本文为了简单考虑，不考虑锁的种类。

什么是两阶段加锁-2PL

在一个事务里面，分为加锁(lock)阶段和解锁(unlock)阶段，也即所有的lock操作都在unlock操作之前,如下图所示:

工程实践中的两阶段加锁-S2PL

在实际情况下，SQL是千变万化、条数不定的，数据库很难在事务中判定什么是加锁阶段，什么是解锁阶段。于是引入了S2PL(Strict-2PL)，即：

在事务中只有提交(commit)或者回滚(rollback)时才是解锁阶段，其余时间为加锁阶段。

如下图所示：

这样的话，在实际的数据库中就很容易实现了。

了解了两阶段加锁协议，我们可以通过这个理论进行一些优化，主要就是通过缩短加锁时间来提高Mysql的并发量。

比如：在一个事务中，将不加锁的普通查询写在前面，将需要加锁的操作写在后面；将热点数据的加锁放在事务的最后；合并SQL等。

1、缩短热点数据的加锁时间

上面很好的解释了两阶段加锁，现在我们分析下其对性能的影响。考虑下面两种不同的扣减库存的方案:

方案1:begin;

// 扣减库存update t_inventory set count=count-5 where id=${id} and count >= 5;

// 锁住用户账户表select * from t_user_account where user_id=123 for update;

// 插入订单记录insert into t_trans;commit;

方案2:begin;

// 锁住用户账户表select * from t_user_account where user_id=123 for update;

// 插入订单记录insert into t_trans;

// 扣减库存update t_inventory set count=count-5 where id=${id} and count >= 5;commit;

由于在同一个事务之内，这几条对数据库的操作应该是等价的。但在两阶段加锁下的性能确是有比较大的差距。两者方案的时序如下图所示：

由于库存往往是最重要的热点，是整个系统的瓶颈。那么如果采用第二种方案的话, tps应该理论上能够提升3rt/rt=3倍。这还仅仅是业务就只有三条SQL的情况下，多一条sql就多一次rt,就多一倍的时间。

从上面的例子中,可以看出，需要把最热点的记录， 放到事务最后，这样可以显著的提高吞吐量。更进一步: 越热点记录离事务的终点越近(无论是commit还是rollback)

注意：避免死锁

上面我们说了通过调整加锁顺序可以提高Mysql数据库并发量。但是一旦涉及到调整加锁顺序就要注意一件事情：死锁。因为死锁的形成条件就是加锁顺序不一致导致的，所以我们要统一按照调整之后的顺序进行加锁。死锁的形成条件见下图：

2、SQL合并

我们可以直接将一些简单的判断逻辑写到update的谓词里面，以减少加锁时间，考虑下面两种方案:

方案1：

begin:
    int count = select count from t_inventory for update;
    
    if count >= 5:
        update t_inventory set count = count - 5 where id = 123; 
        commit;  
    else        
       rollback;

方案2:

begin:        
    int rows = update t_inventory set count = count-5 where id = 123 and count >= 5
       
    if rows > 0:
        commit;                
    else:         
        ​​​​​​​rollback;

时延如下图所示：

可以看到，通过在update中加谓词计算，少了1rt的时间。

由于update在执行过程中对符合谓词条件的记录加的是和select for update一致的排它锁

(具体的锁类型较为复杂，不在这里描述)，所以两者效果一样。

MySQL 两阶段锁协议

在InnoDB事务中,行锁是需要的时候才加上的,但并不是不需要立马释放,而是等事务结束后释放,这个就是--------两阶段协议.

两阶段锁协议引起的死锁

事务A在等事务B释放Id = 2 的锁, 事务B在等事务A释放id = 1 的锁,导致发生死锁

死锁检测:

参考：https://www.phpmianshi.com/?id=175

行锁

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

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

两阶段锁 （Two-Phase Locking――2PL）

在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，需要等事务结束时才释放，这就是两阶段锁协议，分为加锁阶段和解锁阶段，所有的 lock 操作都在 unlock 操作之后。

两段锁协议规定所有的事务应遵守的规则：
　　① 在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁。
　　② 在释放一个封锁之后，事务不再申请和获得其它任何封锁。
　　即事务的执行分为两个阶段：
　　第一阶段是获得封锁的阶段，称为扩展阶段。
　　第二阶段是释放封锁的阶段，称为收缩阶段。

遵循两段锁协议的事务有可能发生死锁。
　

　　此时事务T1 、T2同时处于扩展阶段，两个事务都坚持请求加锁对方已经占有的数据，导致死锁。
　　为此，又有了一次封锁法。一次封锁法要求事务必须一次性将所有要使用的数据全部加锁，否则就不能继续执行。因此，一次封锁法遵守两段锁协议，但两段锁并不要求事务必须一次性将所有要使用的数据全部加锁，这一点与一次性封锁不同，这就是遵守两段锁协议仍可能发生死锁的原因所在。

死锁

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

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

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

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

2. 通过设置 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 利用率很高，但是每秒却执行不了几个事务。

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

1. 1、关掉死锁检测，等待超时

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

3. 2、控制并发度

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

5. 3、热点key拆分

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