问题引入

我们都知道事务的四大特性，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的两阶段锁协议