RC 和 快照隔离 级别可防止某些竞争条件，但并非全部。一些棘手案例，如写偏斜 和 幻读，会发现可悲情况：

• 隔离级别难理解，且不同DB实现不一（如RR含义天差地别）
• 若检查应用层代码很难判断特定隔离级别下是否安全，尤其是大型系统，无法预测各种并发
• 无检测竞争条件的好工具。理论上，静态分析可能有所帮助，但更多技术还没法实际应用。并发问题测试也很难，一切取决于时机

而这些还不是新问题，1970s引入了较弱隔离级别以来一直这样。研究人员的答案都很简单：使用可串行化隔离级别！

可串行化隔离是最强隔离级别。保证即使事务可以并发执行，但最终结果和串行执行一样。因此数据库保证，若事务在单独运行时正常运行，则它们在并发运行时仍正确，即DB能防止所有可能的竞争条件。

若可串行化比弱隔离级别好得多，那为何没啥人用？支持可串行化DB都使用如下三种技术之一：

• 严格串行顺序执行事务
• 两阶段锁定（2PL, two-phase locking），几十年来几乎唯一可行选择
• 乐观并发控制技术，如可串行化快照隔离

本文主要在单节点DB下讨论这些技术。

3.1 真的串行执行

避免并发最简单方法就是完全不并发：即在一个线程上按序执行事务。这完全回避了检测、防止事务冲突。

看着很直接的想法，但DB设计人员在 2007 年才确信，单线程循环执行事务可行。若多线程并发在过去的30年中被认为是获得良好性能的关键所在，那么究竟是什么改变致使单线程执行？

如下两个进展促使我们重新审视：

• RAM越来越便宜，许多场景现在都能将完整活动数据集加载到内存。当事务所需数据都在内存，事务处理的执行速度要比等待数据从磁盘加载时快得多。
• 数据库设计人员意识到 OLTP 事务通常执行很快，而且只产生少量读写操作。相比之下，长时间运行的分析查询通常只读，可在一致性快照（使用快照隔离）上运行，而不需要运行在串行主循环里

串行执行事务的方法在 VoltDB/H-Store，Redis 和 Datomic 中实现。单线程执行的系统有时可以比支持并发的系统效率更好，尤其是可以避免锁开销。但吞吐量上限为单 CPU 核吞吐量。为充分利用单线程，需要与传统形式的事务做出不同调整。

3.1.1 存储过程中封装事务

DB早期阶段，采用事务包含整个用户操作流程。如预订机票涉及多阶段（搜索路线，票价和可用座位，决定行程，在行程的某航班订座，输入乘客信息，最后付款）。DB设计者认为，若整个过程是个事务，则它就可被原子化执行。

但人类做出决定并回应的速度缓慢。若DB事务需等待用户输入，则DB需支持潜在的大量并发事务，其中大部分是空闲的。大多DB不能高效完成这项工作，因此几乎所有的 OLTP 应用程序都避免在事务中等待交互式的用户输入，以此来保持事务简短。在 Web 上，这意味着事务在同一个 HTTP 请求中被提交，而不会跨越多个请求。一个新的 HTTP 请求就开始一个新事务。

即使已经将人为交互从关键路径中排除，事务仍以交互式客户端 / 服务器风格执行，一次一个请求语句。应用程序提交查询，读取结果，可能根据第一个查询的结果进行另一个查询，依此类推。查询和结果在应用程序代码（在一台机器上运行）和数据库服务器（在另一台机器上）之间来回发送。

在这种交互式的事务方式中，应用程序和数据库之间的网络通信耗费了大量的时间。如果不允许在数据库中进行并发处理，且一次只处理一个事务，则吞吐量将会非常糟糕，因为数据库大部分的时间都花费在等待应用程序发出当前事务的下一个查询。在这种数据库中，为了获得合理的性能，需同时处理多个事务。

因此，采用单线程串行执行的系统不支持交互式的多语句事务。应用程序必须提前将整个事务代码作为存储过程提交给DB。这些方法差异如图-9。将事务所需数据都加载到内存，则存储过程可更快执行，而无需等待网络或磁盘I/O。

3.1.2 存储过程的优缺点

存储过程在关系型DB已存在一段时间，自 1999 年以来一直是 SQL 标准（SQL/PSM）一部分，但名声有点不好：

• 每个DB厂商都有自己的存储过程语言（Oracle的PL/SQL，SQL Server的T-SQL，PostgreSQL的PL/pgSQL 等）。这些语言并未跟上通用编程语言发展，所以看起来丑陋过时，而且缺乏大多数编程语言中能找到的库的生态
• 在DB中运行代码难以管理：与应用服务器相比，更难调试，更难保持版本控制和部署，更难测试，难集成到指标收集系统来进行监控
• DB通常比应用服务器对性能敏感，因为单个数据库实例通常由许多应用服务器共享。DB中一个写得不好的存储过程（如占用大量内存或 CPU 时间）会比在应用服务器中相同的代码造成更多的麻烦

但这些问题都能克服。现代的存储过程实现放弃了 PL/SQL，而是使用现有的通用编程语言：VoltDB 使用 Java 或 Groovy，Datomic 使用 Java 或 Clojure，而 Redis 使用 Lua。

存储过程与内存存储使得在单个线程上执行所有事务变得可行。由于不需要等待 I/O，且避免了并发控制机制的开销，它们可以在单个线程上实现相当好的吞吐量。

VoltDB 还使用存储过程进行复制：但不是将事务的写入结果从一个节点复制到另一个节点，而是在每个节点上执行相同的存储过程。因此 VoltDB 要求存储过程是 确定性的（在不同的节点上运行时，它们必须产生相同的结果）。举个例子，如果事务需要使用当前的日期和时间，则必须通过特殊的确定性 API 来实现。

3.1.3 分区

串行执行所有事务使并发控制更简单，但DB事务吞吐量被限制为单机单核速度。虽然只读事务能使用快照隔离在其它地方执行，但对写入吞吐量较高应用，单线程事务处理器可能成为一个严重瓶颈。

为伸缩至多个CPU核和多个节点，可对数据分区，VoltDB 支持这样做。若找到一种对数据集分区方法，以便每个事务只需在单分区中读写数据，则每个分区就能拥有自己独立运行的事务处理线程。此时，可为每个分区指派一个独立CPU核，则 DB 事务吞吐量就能与 CPU 核数保持线性伸缩。

但对跨分区的任何事务，DB必须在涉及的所有分区之间协调事务。存储过程需跨越所有分区加锁执行，以确保整个系统可串行化。

由于跨分区事务具有额外协调开销，所以它们比单分区事务慢得多。 VoltDB 报告的吞吐量大约是每秒 1000 个跨分区写入，比单分区吞吐量低几个数量级，并且不能通过增加更多的机器来扩展性能。

事务是否可以是划分至单个分区很大程度上取决于应用数据的结构。简单KV数据通常可以非常容易地进行分区，但是具有多个次级索引的数据可能需要大量跨分区协调。

3.1.4 小结

满足如下特定约束条件，串行执行事务可实现串行化隔离：

• 事务简短高效，只要有一个缓慢事务，就会拖慢影响所有其它事务性能
• 仅限于活跃数据集完全能放入内存的case。很少访问的数据可能会被移动到磁盘，但万一需要在单线程事务中访问，就会拖累系统 [^x]。
• 写吞吐量必须低到能在单 CPU 核处理，否则需要分区，事务划分至单个分区，最好无需跨分区协调事务
• 跨分区事务虽然也能支持，但比例必须很小

[^x]: 若事务需访问不在内存中的数据，最佳实践可能是中止事务，异步将数据提取到内存，同时继续处理其他事务，然后在数据加载完毕时重启事务，这被称为 反缓存（anti-caching）。