《设计数据密集型应用》第七章(7) 事务：串行化(2)

本节我们继续讨论关于事务串行化的另一种实现方式：两阶段锁（two-phase locking，2PL），它也是一种强隔离性的保证。

两阶段锁

注意，这里不是两阶段提交（2PC），两阶段提交将在后面介绍。

之前我们介绍避免dirty writes时，提到了当两个事务尝试写相同的数据对象时，锁保证第二个写入者必须第一个的事务完成才能继续。对于两阶段锁来说，除了这个要求以外，还要求以下两点：

如果事务A读取数据，并且事务B想写入相同的数据，B必须等待A提交之后才能继续；
如果事务A写入数据，并且事务B想读取相同的数据，B必须等待A提交之后才能继续。

在两阶段锁中，写入并不仅阻塞写入，也会阻塞读取；反过来，读取也会阻塞写入，这和Snapshot隔离性的读写不互相阻塞是完成不同的。因此两阶段锁可以完全避免事务的并发性问题。

两阶段锁的实现

读取和写入时，通过对数据对象加不同的锁，也就是共享锁和排他锁来实现。锁的行为可以总结如下：

当事务想要读取数据时，必须首先获取该数据的共享锁。允许多个事务同时拥有相同数据的多个共享锁，但是当该数据上有排他锁时，该事务需要等待；
当事务想要写入数据时，必须首先获取该数据的排他锁，没有其他事务拥有该数据的共享锁或者排他锁，如果有的则该事务需要等待。
如果一个事务先读取，然后写入数据，可以将拥有的共享锁升级为排他锁，升级的过程和获取排他锁的过程相同。
事务获取锁之后，直到事务结束时才会释放锁。这是两阶段的命名由来：第一阶段是事务执行时获取锁，第二阶段是事务结束后释放锁。

由于使用到了很多锁，可能出现事务A长时间等待事务B释放锁的情况等，称之为死锁。数据库会自动检测死锁的情况，并且在死锁出现时中止其中一个事务，使另外一个事务能够继续执行。

两阶段锁的性能

数据库设计时是没有限制事务的持续时间的，因此事务在对数据加锁之后，可能导致事务的处理时间增加。两阶段锁使得事务处理的时间变得不那么稳定，在大多数情况下延迟都是很低的，但如果出现一个慢的事务，或者一个事务访问很多数据，加了很多锁，会导致系统有可能整体卡住。这种不稳定性在我们需要鲁棒性的系统时是有问题的。

同时，两阶段锁使死锁出现的几率大大增加。在死锁出现时，许多事务会不断的中止和重试，对于性能的影响也是很大的。

谓词锁（Predicate locks）

谓词锁可以用来解决之前我们介绍的幻读（phantoms）问题。基本的原理是在查询时，将查询的条件视为锁。该锁并不匹配数据库中的任何数据，比如以下的查询：

SELECT * FROM bookings
  WHERE room_id = 123 AND
    end_time > '2018-01-01 12:00' AND
    start_time < '2018-01-01 13:00';

谓词锁和两阶段锁有些类似，它的使用方式如下：

当事务A想读取匹配某个条件的数据时，比如先获取属于该谓词的共享锁。如果有另外一个事务B拥有该谓词的排他锁时，事务A必须等待事务B提交后重新查询；
当事务A想要修改数据时，必须看旧值或者新值是否匹配已有的谓词锁条件。如果有匹配的事务B，事务A必须在事务B提交后才能继续。

该方式可以解决有些数据在查询时不存在，但可能会在未来添加，也就是write skew和幻读的问题。

索引范围锁（Index-range locks）

上面加谓词锁的方式，在实际使用时性能表现并不太好：我们对活动的事务加了太多的锁，在匹配时需要花的时间比较长。因此，我们将谓词锁优化为索引范围锁。

基本思路是，如果我们放大谓词锁的数据范围，只是会对更大范围的数据加锁，但是不会影响隔离性的。因此，我们选择谓词中的索引字段，针对这些索引字段加锁，这样在查询时速度是很快的。

假设在预定会议室的例子中，我们对room_id和/或start_time和end_time加了索引，如果我们想要预定room 123在中午12点到下午1点的会议室时，索引范围锁的工作方式如下：

room_id是索引字段，使用该索引查找room 123已有的预定。对room 123添加一个共享锁，证明有事务查询了该room的预定情况；
或者，使用基于时间的索引，在想要预定的时间范围上增加共享锁，证明有事务正在查询中午12点到1点的预定情况。

每种方式都是使用索引的近似查询条件，如果其他事务修改的会议室或者时间与该事务有交叉，则必须要等待该事务先提交并释放锁。

如果没有合适的索引进行加锁，则会降级对整个数据库加共享锁，这会阻止其他所有事务写入数据库，是性能不高但是安全的方式。