隔离被定义为数据库同时执行多个事务而不会对每个结果产生负面影响的能力。本文将解释这些级别并概述它们之间的权衡。我们还建议您选择最适合您需要的隔离级别。
让我们从有效使用隔离级别所需的最低知识开始，检查代表大多数应用程序的两个用例及其对不同隔离级别的影响。
用例1：银行交易
客户从银行账户提款：
-
开始交易；
-
读取用户余额；
-
在活动表中创建一行（我们避免将其称为事务，以避免与数据库事务混淆）；
-
从读取的金额中减去提款金额后，更新用户的余额；
-
Commit
在交易完成之前，我们不希望用户的余额发生变化。
用例2：零售交易
国际客户使用不同于标价的货币从零售店购买商品：
-
开始交易；
-
读取exchange_rate表，获取最新的兑换率；
-
在订单表中创建一行；
-
Commit
假设有一个单独的过程在不断更新汇率，但我们不关心汇率在读取后是否发生变化，即使当前交易尚未完成。
可序列化
Serializable隔离级别是唯一满足ACID属性理论定义的级别。它从本质上说，两个并发事务不允许相互干扰对方的更改，如果一个接一个地执行，则必须产生相同的结果。不幸的是，Serializable通常被认为是不切实际的，即使对于非分布式数据库也是如此。所有现有的流行数据库（如Postgres和MySQL）都反对它，这并非巧合。
为什么这个设置如此不切实际？让我们检查两个用例：
在银行用例中，Serializable是完美的。读取用户余额后，数据库保证用户余额不会改变。因此，应用业务逻辑是安全的，例如确保用户有足够的余额，并根据读取的值编写新的余额。在银行用例中，Serializable是完美的。
在Retail用例中，Serializable也可以正常工作。在创建订单的事务成功之前，不允许更新汇率的进程执行其操作。由于事件的精确顺序，这听起来可能是一个很棒的功能。但是，如果创建订单的交易缓慢而复杂，该怎么办？也许它必须打电话到仓库检查库存。也许它必须对下订单的用户进行信用检查。它将保持该行上的锁，防止汇率进程更新。这种可能是意外的依赖关系可能会阻止系统扩展。
Serializable设置也会经常出现死锁。例如，如果两个事务读取一个用户的余额，它们将在该行上放置一个共享读取锁。如果事务稍后修改该行，它们将尝试将读锁升级为写锁。这将导致死锁，因为每个事务都将被另一个事务持有的读取锁阻塞。正如我们将在下面看到的，不同的隔离级别可以很容易地避免这个问题。
换句话说，有争议的工作负载将无法使用Serializable设置进行扩展。如果工作负载没有争议，我们就不需要这个隔离级别。较低的隔离可能同样有效。
为了解决这种不必要且昂贵的安全问题，必须重构应用程序。例如，获取汇率的代码可能必须在事务开始之前调用，或者读取器可能必须使用单独的连接完成。
虽然理论上没有那么纯粹，但其他隔离级别允许您逐个执行序列化读取。这使得它们在编写可伸缩系统时更加灵活和实用。
无锁定实现
有一些方法可以在不锁定数据的情况下提供可序列化的一致性。然而，这类系统也会遇到上述相同的问题，即冲突交易的失败方式不同。问题的根本原因在于隔离级别本身，任何实现都无法让您摆脱这些约束。
重复读取
RepeatableRead设置不明确。这是因为它区分了点选择和搜索，并为每个点定义了不同的行为。这并不是黑白分明的，并导致了许多其他实现。我们不会详细讨论这个隔离级别。然而，就我们的用例而言，RepeatableRead提供了与Serializable相同的保证，因此继承了相同的问题。
快照读取
SnapshotRead隔离级别虽然不是ANSI标准，但已经越来越流行。这也称为MVCC。这种隔离级别的优点是无争用：它在事务开始时创建快照。所有读取都发送到该快照，而不获取任何锁。但写操作遵循严格的可序列化规则。
SnapshotRead事务对于只读工作负载最有价值，因为您可以看到一致的数据库快照。这避免了在加载事务上相互依赖的不同数据片段时出现意外。您还可以使用快照功能在特定时间读取多个表，然后观察自该快照以来发生的更改。对于希望将更改流式传输到分析数据库的更改数据捕获工具，此功能非常方便。
对于执行写入的事务，快照功能没有那么有用。您主要想控制是否允许在上次读取后更改值。如果您想允许该值更改，它将在您阅读后立即失效，因为其他人可以稍后对其进行更新。因此，无论您是从快照读取还是获取最新值，这都无关紧要。如果不希望更改，则需要最新的值，并且必须锁定行以防止更改。换句话说，SnapshotRead对于只读工作负载很有用，但对于写工作负载来说，它并不比ReadCommitted好，我们将在下面介绍。
在此隔离级别中重新应用Retail用例很自然，不会产生争用：从汇率中读取的值产生了创建事务时快照的值。在进行此交易时，允许单独的交易来更新汇率。银行用例如何？数据库允许您对数据进行锁定。例如，MySQL将使您能够“在共享模式下选择…锁定”（读取锁定），此模式将读取升级为可序列化事务的读取。当然，您还继承了此隔离级别的死锁风险，较低的隔离级别为您提供了两个中最好的。您可以发出“select…for update”（写入锁定），此锁阻止另一个事务获取此行上的任何类型的锁。这种悲观锁定方法起初听起来更糟，但它将允许两个竞争事务成功完成，而不会遇到死锁。第二个事务将等待第一个事务完成，此时它将读取并锁定新值所在的行。
MySQL默认支持SnapshotRead隔离级别，但错误地将其称为REPEATABLE_READ。
分布式数据库
虽然单个数据库有多种有效实现可重复读取的方法，但在分布式数据库中，问题变得更加复杂。这是因为事务可以跨越多个碎片。如果是这样，系统必须提供严格的订购保证。这种排序要求系统使用集中的并发控制机制或全局一致的时钟。这两种方法本质上都试图紧密耦合本来可以独立执行的事件。
因此，在希望分布式数据库支持分布式快照读取之前，必须了解并愿意接受这些权衡。
已提交
ReadCommitted隔离比SnapshotRead更明确，因为它不断返回数据库的最新视图。这也是隔离级别中争议最小的。在这个级别上，每次读取行时可能会得到不同的值。
ReadCommitted设置还允许您通过发出读或写锁定来升级读取，有效地允许您执行按需序列化读取。如前所述，对于打算修改数据的应用程序事务，这种方法为您提供了两全其美的解决方案。
Postgres支持的默认隔离级别是ReadCommitted。
读取未提交
这种隔离级别通常被认为是不安全的，不建议用于分布式或非分布式设置。这是因为您可能会读取稍后可能已回滚（或根本不存在）的数据。
分布式事务
这个主题与隔离级别是正交的，但这里必须涵盖这一点，因为它对于保持事物的松散耦合具有重要意义。
在分布式系统中，如果两行位于不同的碎片或数据库中，并且您希望在单个事务中原子化地修改它们，则会产生两阶段提交（2PC）的开销。
这需要更多的工作：
-
关于分布式事务的元数据被创建并保存到持久存储中。
-
向所有单个交易发布准备。
-
要提交的决策保存到元数据中。
-
向准备好的事务发出提交。
prepare要求您保存元数据，以便在节点在提交（或回滚）之前崩溃时，可以在新的leader中恢复事务。
分布式事务还与隔离级别交互。例如，假设只有2PC事务的第一次提交成功，第二次提交被延迟。如果应用程序已经读取了第一次提交的效果，那么数据库必须阻止应用程序读取第二次提交的行，直到完成。反过来说，如果应用程序在第二次提交之前读取了一行，那么它一定不会看到第一次提交的效果。
数据库必须做额外的工作来支持分布式事务的隔离保证。如果应用程序可以容忍这些部分提交，该怎么办？然后，我们正在做应用程序不关心的不必要的工作。可能值得引入新的隔离级别，如ReadPartialCommits。请注意，这与ReadUncommitted不同，您可以读取最终可能回滚的数据。
最后，过度使用2PC会降低系统的整体可用性和延迟。这是因为性能最差的碎片将决定您的有效可用性。
总结
为了具有可伸缩性，应用程序应该避免依赖数据库的任何高级隔离功能。相反，它应该尽可能少地使用担保。如果您可以编写一个应用程序来使用ReadCommitted隔离级别，那么不建议迁移到SnapshotRead。Serializable或RepeatableRead几乎总是个坏主意。
最好避免多语句事务，但随着应用程序的发展，这可能会不可避免。此时，尝试主要依赖事务的原子保证，并保持数据库系统支持的最低隔离级别。
如果使用分片数据库，请完全避免分布式事务。这可以通过将相关行保留在同一个碎片中来实现。必须从一开始就这样做，因为很难将非并发程序重构为并发程序。
原文标题：Optimizing Isolation Levels for Scaling Distributed Databases
原文作者：Sugu Sougoumarane
原文链接：https://dzone.com/articles/optimizing-isolation-levels-for-scaling-distribute
