隔离定义为在数据库并发执行多个事务时，不会影响到其他事务的执行。本文将解释这些隔离级别，并概述它们之间的权衡。我们还建议选择最适合您需求的隔离级别。
让我们从有效使用隔离级别所需的最低知识开始，研究表示大多数应用程序的两个用例及其对不同隔离级别的影响。
用例1：银行交易
客户从银行账户取钱：
开始交易；
读取用户余额；
在活动表中创建一行（我们避免将其称为事务，以避免与数据库事务混淆）；
从读取的金额中减去提款金额后，更新用户的余额；
提交。
在交易完成之前，我们不希望用户的余额发生变化。
用例2：零售交易
国际客户从零售店购买物品时使用的货币与标价不同:
开始交易；
读取exchange_rate表，获取最新的兑换率；
在订单表中创建一行；
提交。
假设有一个单独的过程正在不断更新汇率，但我们不关心汇率在读取之后是否会发生变化，即使当前交易还没有完成。
可序列化
Serializable隔离级别是唯一满足ACID属性理论定义的级别。它从本质上说，两个并发事务不允许相互干扰对方的更改，如果一个接一个地执行，则必须产生相同的结果。
不幸的是，Serializable通常被认为是不切实际的，即使对于非分布式数据库。所有现有的流行数据库（如Postgres和MySQL）都不推荐它，这并不是巧合。
为什么这个设置如此不切实际？让我们来看看两个用例：
在银行用例中，Serializable是完美的。在读取用户余额后，数据库保证用户余额不会改变。因此，应用业务逻辑是安全的，例如确保用户有足够的余额，并根据读取的值写入新的余额。在银行用例中，Serializable是完美的。
在零售用例中，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。
最好避免多语句事务，但随着应用程序的发展，这可能会不可避免。此时，尝试主要依赖事务的原子保证，并保持数据库系统支持的最低隔离级别。
如果使用分片数据库，请完全避免分布式事务。这可以通过将相关行保留在同一个碎片中来实现。必须从一开始就这样做，因为很难将非并发程序重构为并发程序。
