本系列将站在于实践和前沿技术的角度，着重讨论分事务的原理和多种实现技术。事务的实现技术是整个事务型数据库的框架和灵魂，确定了事务的实现算法，才能确定数据库的整体架构。

另外，讨论的重点将是分布式事务。分布式事务的核心问题是解决分布式、并发情况下的数据的一致性，包括事务一致性和分布式一致性。分布式事务中数据的一致性主要表现在三个方面：

q跨节点写数据时，如何保证写操作影响的数据是全局一致的。

q跨节点读数据时，在存在并发的分布式写事务的前提下，如何保证读到的数据是一致的。

q从分布式系统读到的数据如何保证满足分布式一致性。分布式一致性本质上是分布式系统引入的问题，是站在分布式系统之外观察对数据的读取，观察到的数据之间不存在时间上的不一致。而事务一致性属于事务概念中ACID中的C的问题，这种情况下并发事务对数据项的影响不会造成数据异常，即数据状态始终会保持从一个合法状态变迁为另外一个合法状态。

本系列将从并发访问控制算法的角度，讨论传统的和较新的事务并发访问控制技术。

事务没有统一的一个概念，ANSI SQL标准认为事务是一系列操作的一个逻辑单位，而且明确提出事务成功和失败的两种状态。Jim Gray提出事务的ACID四个特性，其中A指原子性（Atomicity）、C指一致性（Consistency），I指隔离性（Isolation），D指持久性（Durability）。

事务除了应具有ACID四个特性外，还应具有可串行化（Serializability）、可恢复性（Recoverability）、严格性（Strictness）这样的事务属性[1]。事务属性确保了ACID实现的正确性。

并发操作可能会导致数据产生多种异常现象，为了确保事务特性的实现，事务处理技术还延伸到了事务处理策略、事务模型、多种并发访问控制技术，目的是以解决数据异常现象，从而达到事务层面数据的一致性要求。

事务处理策略

经典的事务处理策略包括：

q乐观并发控制策略（Optimistic concurrency control，OCC）：从事务开始，每一项操作都允许进行，但在事务提交的时刻，进行隔离性和完整性约束检查，如果有违反相关约束的行为则事务被终止。单机事务处理模型很少使用乐观并发控制策略。

q悲观并发控制策略（Pessimistic concurrency control，PCC）：从事务开始，即检查每一项操作是否会违反隔离性和完整性约束，如果可能违反，则阻塞这样的操作，预防其他并发事务发生。通常采用封锁并发控制机制实现并发事务的互斥，直至事务完成后才解除互斥（释放锁）。

q混合策略：悲观并发控制策略混合策略通常以乐观并发控制策略为框架，并内嵌悲观并发控制策略，从而实现并发访问控制。

工程实践中，经典的单机事务处理技术实现有Oracle、MySQL/InnoDB、Informix、DB2等的事务模型采用的悲观并发控制策略，虽然后来Oracle、MySQL/InnoDB等逐步融合了MVCC（Multi-Version Concurrency Control，多版本并发控制）技术，但仍然是以悲观并发控制策略为主，用封锁并发访问控制协议确保可串行化（Oracle、MySQL/InnoDB、Informix、DB2），而PostgreSQL在V9.2之后完全使用MVCC/SSI技术来确保可串行化。

事务模型

事务模型包括：

1. 平板事务模型（Flat Transactions）：事务块中的所有SQL语句会构成一个逻辑单元，这些SQL语句会通过这个逻辑单元共同工作，要么都成功，要么都失败（哪怕有一项失败就会导致所有都失败），弱势失败就会导致事务回滚。PostgreSQL的事务管理如果不考虑保存点（Savepoint）机制，可以认为就是一个平板类型的事务，事务块内的一个SQL失败，会导致整个事务回滚，之前执行成功的操作也必须回滚。

2. 带有保存点的平板事务模型（Flat Transactions With Savepoints）：在平板事务的基础上实现保存点技术，这样对一个事务块划分出不同的层次，每个层次之间为一个逻辑单元，后面失败的SQL不影响保存点前发生的操作，即回滚发生在局部。PostgreSQL、InnoDB、Informix在平板事务的基础上，都支持了保存点技术。

3. 链式事务模型（Chained Transactions）：与平板事务不同的是，链式事务在提交一个事务后会释放一些资源（如锁等资源），但是一些上下文环境，如事务的载体（存放事务信息的结构体或类等对象）则不会被释放，会留给下一个事务使用。用户感觉自己的逻辑上的处理单元与之前的事务似乎没有COMMIT之类命令执行的明显分割。如InnoDB的事务模型，就是链式事务的代表。但是，这并不是说InnoDB不支持平板事务，实际上InnoDB不仅支持平板事务，还支持带有保存点的平板事务，并通过XA技术支持下面将要谈到的分布式事务。

4. 嵌套事务模型（Nested Transactions）：嵌套事务如同一棵树，这棵树有子叉、有叶子，也有根。其中，每个子叉事务可以是嵌套事务的子事务也可以是平板事务的子事务；每叶子节点的事务必须是平板事务；只有通过根节点事务提交，整个事务对数据修改才生效，否则只能在事务内局部有效。PostgreSQL、MySQL（不包括InnoDB，InnoDB是被Oracle收购之后才逐渐并入MySQL的）不支持嵌套事务。原本MySQL打算在5.0版本之后提供对嵌套事务的支持，但直到8.0.8版本还没有兑现。

5. 分布式事务模型（Nested Transactions）：在分布式环境下，每个节点的事务模型采用平板事务模型或以上其他类型的事务模型。分布式事务需要实现事务层面的一致性和分布式系统的一致性，最终表现为强一致性，这使得分布式事务模型会比其他模型更为复杂。从逻辑上看，分布式节点和每个节点上的事务模型构成了分布式事务处理的模型。

6. 多层次事务模型（Multi-Level Transactions）：多层事务也如同一棵树，树根是事务的总节点，与树根相连的下层事务是对象操作（Object Operation），而一个对象操作还可以带有多个子对象操作节点，或带有一个或多个的叶子节点（Page operation，）。

事务模型的实现，依赖的是有限状态自动机。不同事务模型，有着相似但不完全相同的事务状态，如事务开始、事务执行中、事务提交、事务回滚等，支持子事务的还包括子事务的提交、子事务的回滚等状态，这些状态之间互相变迁，完成事务的生命过程。

并发访问控制技术

事务处理机制，核心技术是并发访问控制技术，主要包括五种：

1. Locking：封锁并发访问控制机制，即两阶段封锁协议，简写为2PL，强调的是加锁（增长阶段，growing phase）和解锁（缩减阶段，shrinking phase）这两个阶段，即不管同一个事务内需要在多少个数据项上加锁，所有的加锁操作都只能在同一个阶段完成，在这个阶段内，不允许对对已经加锁的数据项进行解锁操作，即加锁和解锁操作不能交叉执行（同一个事务内）。而实现可串行化的机制是强严格两阶段锁（Strong Stric two-phase locking，简写为SS2PL），如MySQL/InnoDB、Informix采取了SS2PL确保可串行化。

2. Time-stamp ordering：时间戳排序并发访问控制机制，是基于时间戳对事务提交进行排序以完成并发控制的技术，简写为TO。这种技术用来确保在出现访问冲突的情况下，多个事务按照时间戳的顺序来访问数据项。如果TS（Ti）<TS（Tj），那么数据库事务管理器必须保证所产生的调度等价于事务Ti出现在事务Tj之前的某个串行调度。

3. Serialization graph testing：串行化图验证并发访问控制机制，也称为优先图、冲突图或串行化图（Precedence graph checking、conflict graph、serializability graph）。调度S中所有事务代表的节点和事务间优先关系构成的边共同构成一个有向图。串行化图形检测，就是检查上述图中是否存在环，如果存在环，则违反了“冲突可串行化（Conflict serializable）”原则，这时就可判定其存在“冲突行为（Conflictaction）”。因此存在环的调度是不应该存在的情况。

4. Commitment ordering：提交排序并发访问控制机制，简写为CO。在CO算法中，事件是否可以提交，由本地提交机制（a local commitment mechanism，即本地节点上的事务处理机制）和原子提交协议（an atomic commitment protocol，即分布式事务提交时如何保证提交操作是原子的）来确定的。这表明CO被用于协调本地事务和分布式事务（，即用于在分布式环境下实现分布式事务。这是一种非常适合去中心化的分布式事务处理机制，后续将讨论。

5. Multi version concurrent access control：多版本并发访问控制机制，简写为MVCC。MVCC技术的核心是以元组存在多个版本为物理基础，通过当前活动事务的状态形成的快照、利用多版本可见性算法识别出历史上存活的数据。MVCC通常和其他并发访问控制机制混合使用，如与封锁并发访问控制机制、时间戳排序并发访问控制机制等互相配合提高并发度。Oracle、MySQL/InnoDB混合采取了SS2PL和MVCC技术。而PostgreSQL的并发访问控制技术由使用SS2PL逐渐演变为使用纯粹的MVCC技术。