精通Java事务编程-深入理解事务

苛刻的数据存储系统中，很多可能出错的case：

• 数据库软件、硬件可能随时失效（包括正在执行写操作的过程中）
• 应用程序可能随时崩溃（包括一系列操作的中间某步）
• 网络中断可能会意外切断数据库与应用的连接，或数据库之间的连接。
• 多个客户端可能同时写入DB，导致数据覆盖
• 客户端可能读到无意义的、部分更新的数据
• 客户端之间由于边界条件竞争所引入的各种奇怪问题

为实现高可靠，系统必须处理这些问题。但完善容错机制工作量巨大，要仔细考虑所有可能出错的事情，并充分测试。

十年来，事务一直是简化这些问题的首选机制。事务将应用程序的多个读、写操作组合成一个逻辑单元。即事务中的读、写操作是个执行的整体：整个事务要么成功（提交），要么失败（中止或回滚）。若失败，程序可安全地重试。如此，便无需再担心部分失败的情况，应用层的错误处理就简单很多。

也许你觉得事务就这么简单了，但细究起来也许不止于此。事务不是先天存在的；它是为简化应用层的编程模型而人为创造的。通过事务，应用程序可忽略某些潜在的错误和复杂的并发问题，因为DB会替应用处理好（称之为安全保证，safety guarantees）。

并非所有应用都需要事务，有时可弱化事务处理或完全放弃事务（如为获得更高性能或更高可用性）。一些安全相关属性也可能会避免引入事务。

如何判断是否需要事务？

先要确切理解事务能为我们提供什么安全保障及其代价。

本文将研究许多出错案例，并探索DB防范这些问题的算法和设计。尤其是并发控制领域，深入讨论各种竞争条件及DB的隔离级别。

本文同时适用于单机DB与分布式DB。

1 深入理解事务

目前几乎所有关系型DB和一些非关系DB都支持事务。大多遵循IBM System R（第一个SQL数据库）在1975年的设计。50年来，尽管一些细节实现变化，但总体思路大同小异。MySQL、PostgreSQL、Oracle 和 SQL Server 等DB中的事务支持与 System R 极为相似。

2000年后，NoSQL普及，目标在关系DB现状上，通过提供新数据模型和内置的复制和分区改进传统的关系模型。然而，事务成了这变革的受害者：新一代DB完全放弃事务或重新定义，即替换为比以前弱得多的保证。

随新型分布式DB炒作，人们普遍认为事务是可扩展性的对立面，大型系统都必须放弃事务以获得更高性能和高可用性。但另一方面，还有一些DB厂商坚称事务是 “关键应用” 和 “高价值数据” 所必备的重要功能。这两种观点都有些夸张。

事务有其优势和局限性。为理解事务权衡，来看看正常运行和各种极端case，看看事务到底能给我们什么。

1.1 ACID到底意味着什么

事务所提供的安全保证即ACID：

• 原子性（Atomicity）
• 一致性（Consistency）
• 隔离性（Isolation）
• 持久性（Durability）

它由 TheoHärder 和 Andreas Reuter 于 1983 年为精确描述DB的容错机制。

但实际上不同DB的 ACID 实现不尽相同。仅隔离性含义就有很多争议。当一个系统声称自己 “兼容ACID” 时，实际上能提供什么保证并不清楚。ACID现在几乎已经变成一个营销术语。

不符合ACID的系统有时被称为BASE：

• 基本可用性（Basic