优化隔离级别以扩展分布式数据库

隔离被定义为数据库同时执行多个事务而不会对每个结果产生负面影响的能力。本文将解释这些级别并概述它们之间的权衡。我们还将建议选择最适合您需求的隔离级别。

让我们通过检查代表大多数应用程序的两个用例及其对不同隔离级别的影响，从有效使用隔离级别所需的最低知识开始。

用例 1：银行交易

客户从银行账户取款：

开始交易；
读取用户余额；
在活动表中创建一行（我们避免将此称为事务以防止与数据库事务混淆）；
读取金额减去提现金额后更新用户余额；
犯罪。
在交易完成之前，我们不希望用户的余额发生变化。

用例 2：零售交易

一位国际客户使用不同于标价的货币从零售店购买商品：

开始交易；
读取 exchange_rate 表，获取最新兑换率；
在订单表中创建一行；
犯罪。
让我们假设一个单独的过程不断更新汇率——但我们并不关心汇率在读取后是否发生变化，即使当前交易尚未完成。

可序列化
Serializable 隔离级别是唯一满足 ACID 属性理论定义的隔离级别。它本质上表明两个并发事务不允许相互干扰，如果一个接一个地执行，则必须产生相同的结果。

不幸的是，Serializable 通常被认为是不切实际的，即使对于非分布式数据库也是如此。所有现有的流行数据库（如 Postgres 和 MySQL）都反对它，这并非巧合。

为什么这个设置如此不切实际？让我们检查两个用例：

在银行用例中，Serializable 是完美的。读取用户余额后，数据库保证用户余额不会发生变化。因此，应用业务逻辑是安全的，例如确保用户有足够的余额并根据读取的值写入新的余额。在银行用例中，Serializable 是完美的。

在零售用例中，Serializable 也可以正常工作。在创建订单的交易成功之前，不会允许更新汇率的进程执行其操作。

由于事件的精确排序，这听起来像是一个很棒的功能。但是，如果创建订单的交易既慢又复杂怎么办？也许它必须到仓库检查库存。也许它必须对下订单的用户进行信用检查。它将锁定该行，防止汇率过程更新。这种可能无意的依赖性可能会阻止系统扩展。

Serializable 设置也容易发生死锁。例如，如果两个事务读取一个用户的余额，它们将在该行上放置一个共享读锁。如果事务稍后修改该行，它们将尝试将读锁升级为写锁。这将导致死锁，因为每个事务都会被另一个事务持有的读锁阻塞。正如我们将在下面看到的，不同的隔离级别可以很容易地避免这个问题。

不同的隔离级别可以轻松避免这个问题。

换句话说，有争议的工作负载将无法使用 Serializable 设置进行扩展。如果工作负载没有争议，我们就不需要这个隔离级别。较低的隔离度可能同样有效。

为了解决这种不必要且昂贵的安全问题，必须重构应用程序。例如，获取汇率的代码可能必须在交易开始之前被调用，或者读取器可能必须使用单独的连接来完成。

尽管理论上不那么纯粹，但其他隔离级别允许您根据具体情况执行可序列化读取。这使得它们在编写可扩展系统时更加灵活和实用。

无锁实现
有一些方法可以在不锁定数据的情况下提供 Serializable 一致性。然而，这样的系统存在上述相同的问题，其中冲突的事务以不同的方式失败。问题的根本原因在于隔离级别本身，没有任何实现可以让您摆脱这些限制。

可重复读
RepeatableRead 设置不明确。这是因为它将点选择与搜索区分开来，并为每个选择定义不同的行为。这不是非黑即白，并导致了许​​多其他实现。我们不会深入讨论这个隔离级别的细节。但是，就我们的用例而言，RepeatableRead 提供与 Serializable 相同的保证，因此继承了相同的问题。

快照读取
SnapshotRead 隔离级别虽然不是 ANSI 标准，但已经越来越流行。这也称为 MVCC。这种隔离级别的优点是它是无争用的：它在事务开始时创建一个快照。所有读取都发送到该快照而不获取任何锁。但是写入遵循严格的可序列化规则。

SnapshotRead 事务对于只读工作负载最有价值，因为您可以看到一致的数据库快照。这样可以避免在加载事务上相互依赖的不同数据时出现意外。您还可以使用快照功能在特定时间读取多个表，然后观察自该快照以来发生的更改。此功能对于希望将更改流式传输到分析数据库的更改数据捕获工具非常方便。

对于执行写入的事务，快照功能没有那么有用。您主要想控制是否允许在最后一次读取后更改值。如果您想允许更改值，那么一旦您阅读它就会过时，因为其他人可以稍后对其进行更新。因此，您是从快照中读取还是获取最新值都没有关系。如果您不希望它更改，则需要最新的值，并且必须锁定该行以防止更改。

换句话说，SnapshotRead 对于只读工作负载很有用，但对于写入工作负载，它并不比 ReadCommitted 好，我们将在下面介绍。

在此隔离级别中重新应用零售用例可以自然地工作而不会产生争用：从汇率中读取的值会产生一个值，该值与创建事务时的快照相同。当此交易正在进行时，允许单独的交易更新汇率。

银行用例呢？数据库允许您对数据进行锁定。例如，MySQL 将使您能够“选择…锁定共享模式”（读锁定）。此模式将读取升级为可序列化事务的读取。当然，你也继承了这个隔离级别的死锁风险。

较低的隔离级别可为您提供两全其美的效果。您可以发出“选择...进行更新”（写锁定）。此锁可防止另一个事务获得此行上的任何类型的锁。这种悲观锁定的方法起初听起来更糟，但可以让两个竞速事务成功完成而不会遇到死锁。第二个事务将等待第一个事务完成，此时它将读取并锁定新值的行。

MySQL 默认支持 SnapshotRead 隔离级别，但误导性地将其称为 REPEATABLE_READ。

分布式数据库
尽管单个数据库有很多方法可以有效地实现可重复读取，但在分布式数据库的情况下问题变得更加复杂。这是因为事务可以跨越多个分片。如果是这样，系统必须提供严格的订购保证。这种排序要求系统使用集中的并发控制机制或全局一致的时钟。这两种方法本质上都试图将原本可以彼此独立执行的事件紧密耦合。

因此，在希望分布式数据库支持分布式快照读取之前，必须了解并愿意接受这些权衡。

已提交
ReadCommitted 隔离比 SnapshotRead 更明确，因为它不断返回数据库的最新视图。这也是隔离级别中争议最小的。在这个级别，每次读取一行时，您可能会得到不同的值。

ReadCommitted 设置还允许您通过发出读取或写入锁定来升级读取，从而有效地允许您执行按需可序列化读取。如前所述，对于打算修改数据的应用程序事务，这种方法为您提供了两全其美的方法。

Postgres 支持的默认隔离级别是 ReadCommitted。

读未提交
此隔离级别通常被认为是不安全的，不建议用于分布式或非分布式设置。这是因为您可能会读取后来可能已回滚的数据（或一开始就不存在）。

分布式事务
这个主题与隔离级别是正交的，但在这里讨论这一点很重要，因为它对于保持松散耦合具有重要意义。

在分布式系统中，如果两行位于不同的分片或数据库中，并且您希望在单个事务中原子地修改它们，则会产生两阶段提交 (2PC) 的开销。 

这需要更多的工作：

创建有关分布式事务的元数据并将其保存到持久存储中。
为所有单独的交易发出准备。
提交的决定被保存到元数据中。
向准备好的事务发出提交。
准备要求您保存元数据，以便如果节点在提交（或回滚）之前崩溃，事务可以在新的领导者中复活。

分布式事务也与隔离级别交互。例如，我们假设一个 2PC 事务只有第一次提交成功，第二次提交延迟。如果应用程序已经读取了第一次提交的效果，那么数据库必须阻止应用程序读取第二次提交的行直到完成。反过来，如果应用程序在第二次提交之前读取了一行，那么它一定看不到第一次提交的效果。

数据库必须做额外的工作来支持分布式事务的隔离保证。如果应用程序可以容忍这些部分提交怎么办？然后我们正在做应用程序不关心的不必要的工作。引入像 ReadPartialCommits 这样的新隔离级别可能是值得的。请注意，这与 ReadUncommitted 不同，您可以在其中读取最终可能回滚的数据。

最后，过度使用 2PC 会降低系统的整体可用性和延迟。这是因为性能最差的分片将决定您的有效可用性。

综上所述
为了具有可扩展性，应用程序应避免依赖数据库的任何高级隔离功能。相反，它应该尝试使用尽可能少的保证。如果您可以编写一个使用 ReadCommitted 隔离级别的应用程序，那么不鼓励使用 SnapshotRead。Serializable 或 RepeatableRead 几乎总是一个坏主意。

最好避免多语句事务，但是随着应用程序的发展，这可能会变得不可避免。此时，尝试主要依靠事务的原子保证，并保持在数据库系统支持的最低隔离级别。

如果使用分片数据库，请完全避免分布式事务。这可以通过将相关行保持在同一个分片中来实现。必须从一开始就这样做，因为很难将非并发程序重构为并发。