《设计数据密集型应用》第七章(8) 事务：串行化(3)
前面我们介绍了关于隔离型的内容，如果使用弱隔离性时，数据库性能较好，但可能会出现事务并行的问题；如果使用事务的串行化，事务的并行执行的结果和串行是一样的，但性能较差。因此，有没有一种串行化的方法，能够结合这两种方式的优点呢：这就是本节要介绍的串行化的镜像隔离（serializable snapshot isolation，SSI）。
串行化的镜像隔离
我们之前提到的两种串行化的方法：单线程的串行化，和两阶段锁，在本质上属于一种悲观锁的实现。悲观锁指的是我们假设每个事务都有可能引起并发性的问题，因此要等待环境安全之后才进行事务的执行。本节我们介绍的SSI，在本质上属于乐观锁，也就是它假设事务的并发执行都是正常的，只有在事务提交前，才会检查是否有违背隔离性的事情发生，会中止并重试该事务。
乐观锁的优点是当数据空间足够稀疏时，事务发生并发冲突的可能性较低，事务执行的效率是很高的；但是如果事务重试的比例很高，对性能的影响较大。
基于过期假设的决定
一些事务的执行是基于事务开始时的假设，比如医生离岗的问题，假设是当前有两个医生在值班，也就是事务中的查询和数据写入。但是当事务提交时，这个假设的结论可能会变化，因此有两种检测假设结论是否变化的方式：
- 检测过期的MVCC数据对象的读取（未提交的写入发生在读取之前）；
- 检测数据写入影响了先前的读取（写入发生在读取之后）。
检测过期的MVCC读取
由于我们使用了snapshot隔离性，事务读取到的是其他事务未提交之前的snapshot。在医生离岗的例子中，通过MVCC判断是否发生了事务的并发冲突的示意图如下：
MVCC检测过期的数据读取
事务43在读取时，已知事务42已经要写入该数据的值，但未提交；当事务43提交时，判断事务42是否已经提交，如果已经提交的话，则事务43中止并重试。
为什么在提交时才判断，而不是在事务43发现事务42已经要写入该数据值就中止呢？因为如果事务43仅读取数据的话，它并不需要被中止，在事务43提交之前，事务管理器并不知道它是否要修改数据。同时，在事务43提交时，事务42可能被中止，这样事务43就是可以提交的。
检测写入影响先前的读取
第二种方式是记录下事务修改数据时，已经有哪些未提交的事务在先前已经读取该数据，中止这些事务。如下图所示：
检测一个事务修改了其他事务读取的数据
在两阶段锁中，我们提到了索引范围锁（index-range locks），这里也采用类似的方式。假设我们查询shift_id=1234的数据，我们记录事务42和43都读取了该条件的数据。当事务42更新数据并提交时，由于它已知事务43已经读取相同条件的数据，因为会中止事务43的执行。
SSI的性能
和两阶段锁相比，SSI的事务执行不会阻塞其他事务的执行，和snapshot隔离性相同，读写不会互相阻塞。这使得事务执行的延迟更加稳定和可预测，特别是针对读取为主的系统，性能会提升很多。
和串行执行相比，SSI会使用多个CPU核工作，可以很容易的进行水平扩展。甚至当数据分区到多台机器时，事务能够在读写多个分区时，保证不会有并发问题。
最后，SSI本身的性能和事务冲突的几率是有关系的。
