并发异常那些事
本文Github地址：https://github.com/Vonng/pg/blob/master/internal/concurrent-control.md 微信看着效果太渣。
大多数数据库都会同时被多个客户端访问。如果它们各自读写数据库的不同部分，这是没有问题的，但是如果它们访问相同的数据库记录，则可能会遇到并发问题（竞争条件（race conditions））。
图1是这类问题的一个简单例子。假设你有两个客户端同时在数据库中增长一个计数器。（假设数据库中没有自增操作）每个客户端需要读取计数器的当前值，加1 ，再回写新值。因为发生了两次增长，计数器应该从42增至44；但由于竞态条件，实际上只增至 43 。
事务ACID特性中的I，即隔离性（Isolation）就是针对这种问题而提出的。ACID意义上的隔离性意味着，同时执行的事务是相互隔离的：它们不能相互踩踏。传统的数据库教科书将隔离性形式化为可序列化（Serializability），这意味着每个事务可以假装它是唯一在整个数据库上运行的事务。数据库确保当事务已经提交时，结果与它们按顺序运行（一个接一个）是一样的，尽管实际上它们可能是并发运行的。
图1 两个客户之间的竞争状态同时递增计数器
然而实践中很少会使用可序列化隔离，因为它有性能损失。一些流行的数据库如Oracle 11g，甚至没有实现它。在Oracle中有一个名为“可序列化”的隔离级别，但实际上它实现了一种叫做**快照隔离（snapshot isolation）**的功能，这是一种比可序列化更弱的保证。
1 隔离等级
如果两个事务不触及相同的数据，它们可以安全地并行（parallel）运行，因为两者都不依赖于另一个。当一个事务读取由另一个事务同时修改的数据时，或者当两个事务试图同时修改相同的数据时，并发问题（竞争条件）才会出现。只读事务之间不会有问题，但只要至少一个事务涉及到写操作，就有可能出现冲突。
并发BUG很难通过测试找到，因为这样的错误只有在特殊时机下才会触发。这样的时机可能很少，通常很难重现。并发性也很难推理，特别是在大型应用中，你不一定知道哪些其他代码正在访问数据库。在一次只有一个用户时，应用开发已经很麻烦了，有许多并发用户使得它更加困难，因为任何一个数据都可能随时改变。
偶然出现的瞬时错误有时称为Heisenbug，而确定性的问题对应地称为Bohrbugs
出于这个原因，数据库一直试图通过提供**事务隔离（transaction isolation）**来隐藏应用程序开发者的并发问题。从理论上讲，隔离可以通过假装没有并发发生，让你的生活更加轻松：**可序列化（serializable）**的隔离等级意味着数据库保证事务的效果与连续运行（即一次一个，没有任何并发）是一样的。
实际上不幸的是：隔离并没有那么简单。可序列化会有性能损失，许多数据库不愿意支付这个代价。因此，系统通常使用较弱的隔离级别来防止一部分，而不是全部的并发问题。这些隔离级别难以理解，并且会导致微妙的错误，但是它们仍然在实践中被使用。
并发性错误导致的并发性错误不仅仅是一个理论问题。它们造成了很多的资金损失，耗费了财务审计人员的调查，并导致客户数据被破坏。关于这类问题的一个流行的评论是“如果你正在处理财务数据，请使用ACID数据库！” —— 但是这一点没有提到。即使是很多流行的关系型数据库系统（通常被认为是“ACID”）也使用弱隔离级别，所以它们也不一定能防止这些错误的发生。
比起盲目地依赖工具，我们应该对存在的并发问题的种类，以及如何防止这些问题有深入的理解。
我们将研究几个在实践中使用的弱隔离级别，以及这些隔离级别中可能出现的问题。
2 SQL92标准
按照ANSI SQL92的标准，三种现象（phenomena）（脏读，不可重复读，幻读）区分出了四种隔离等级，如下表所示：
| 隔离等级 | *脏写P0 | 脏读 P1 | 不可重复读 P2 | 幻读 P3 |
|---|---|---|---|---|
| 读未提交RU | 不可能 | 可能 | 可能 | 可能 |
| 读已提交RC | 不可能 | 不可能 | 可能 | 可能 |
| 可重复读RR | 不可能 | 不可能 | 不可能 | 可能 |
| 可序列化SR | 不可能 | 不可能 | 不可能 | 不可能 |
脏写没有在标准中指明，但是却是RU必须避免的异常
脏写（P0, Dirty Write）
事务T1修改了数据项，而另一个事务T2在T1提交或回滚之前就修改了T1修改的数据项。
无论如何，事务必须避免这种情况。
脏读（P1, Dirty Read）
事务T1修改了数据项，另一个事务T2在T1提交或回滚前就读到了这个数据项。
如果T1选择了回滚，那么T2实际上读到了一个事实上不存在（未提交）的数据项。
不可重复读（P2, Non-repeatable or Fuzzy Read）
事务T1读取了一个数据项，然后另一个事务T2修改或删除了该数据项并提交。
如果T1尝试重新读取该数据项，它就会看到修改过后的值，或发现值已经被删除。
幻读（P3, Phantom）
事务T1读取了满足某一搜索条件的数据项集合，事务T2创建了新的满足该搜索条件的数据项并提交。
如果T1再次使用同样的搜索条件查询，它会获得与第一次查询不同的结果。
现象与异常
现象（phenomena）与异常（anomalies）并不相同。现象不一定是异常，但异常肯定是现象。例如在脏读的例子中，如果T1回滚而T2提交，那么这肯定算一种异常：看到了不存在的东西。但无论T1和T2各自选择回滚还是提交，这都是一种可能导致脏读的现象。通常而言，异常是一种严格解释，而现象是一种宽泛解释。
这几种现象与异常的形式化表述如下：
P0: w1[x]...w2[x]...((c1 or a1) and (c2 or a2)) in any order)P1: w1[x]...r2[x]...((c1 or a1) and (c2 or a2)) in any order)
A1: w1[x]...r2[x]...(a1 and c2 in any order)
P2: r1[x]...w2[x]...((c1 or a1) and (c2 or a2) in any order)
A2: r1[x]...w2[x]...c2...r1[x]...c1
P3: r1[P]...w2[y in P]...((c1 or a1) and (c2 or a2) any order)
A3: r1[P]...w2[y in P]...c2...r1[P]...c1
注意
SQL92标准对于隔离级别的定义是有缺陷的 —— 模糊，不精确，并不像标准应有的样子独立于实现。标准其实针对的是基于锁调度的实现来讲的，而基于多版本的实现就很难对号入座。有几个数据库实现了“可重复读”，但它们实际提供的保证存在很大的差异，尽管表面上是标准化的。在研究文献中已经有了可重复读的正式定义，但大多数的实现并不能满足这个正式定义。还有，IBM DB2使用“可重复读”来引用可串行化。结果，没有人真正知道可重复读的意思。
标准还有其他的问题，例如在P3中只提到了创建/插入的情况，但实际上任何写入都可能导致异常现象。 此外，标准对于可序列化也语焉不详，只是说“SERIALIZABLE隔离级别必须保证通常所知的完全序列化执行”，其实意思就是不出现这三种异常现象。
3 现代模型
相比之下，现代的隔离等级与一致性等级对于这个问题有更清晰的阐述，如图所示：
图：隔离等级偏序关系图
为了讨论便利，本图中刨除了MAV、CS、I-CI、P-CI等隔离等级。
表：各个隔离等级及其可能出现的异常现象
| 等级\现象 | P0 | P1 | P4C | P4 | P2 | P3 | A5A | A5B |
|---|---|---|---|---|---|---|---|---|
| 读未提交 RU | ✅ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ⚠️ |
| 读已提交 RC | ✅ | ✅ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ⚠️ |
| 游标稳定性 CS | ✅ | ✅ | ✅ | ⚠️? | ⚠️? | ⚠️ | ⚠️ | ⚠️? |
| 可重复读 RR | ✅ | ✅ | ✅ | ✅ | ✅ | ⚠️ | ✅ | ✅ |
| 快照隔离 SI | ✅ | ✅ | ✅ | ✅ | ✅ | ⚠️? | ✅ | ⚠️ |
| 可序列化 SR | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
带有？标记的表示可能出现异常，依具体实现而异。
主流关系型数据库的实际隔离等级
相应地，将主流关系型数据库为了“兼容标准”而标称的隔离等级映射到现代隔离等级模型中，如下表所示：
表：主流关系型数据库标称隔离等级与实际隔离之间的对照关系
| 实际\标称 | PostgreSQL/9.2+ | MySQL/InnoDB | Oracle(11g) | SQL Server |
|---|---|---|---|---|
| 读未提交 RU | RU | RU | ||
| 读已提交 RC | ||||
| 游标稳定性 CS | ||||
| 单调原子视图 MAV | RC | RC, RR | RC | RC |
| 可重复读 RR | RR | |||
| 快照隔离 SI | RR | SR | SI | |
| 可序列化 SR | SR | SR | SR |
以PostgreSQL为例
如果按照ANSI SQL92标准来看，PostgreSQL实际上只有两个隔离等级：RC与SR。
| 隔离等级 | 脏读 P1 | 不可重复读 P2 | 幻读 P3 |
|---|---|---|---|
| RU，RC | ✅ | ⚠️ | ⚠️ |
| RR，SR | ✅ | ✅ | ✅ |
其中，RU和RC隔离等级中可能出现P2与P3两种异常情况。而RR与SR则能避免P1,P2,P3所有的异常。
当然实际上如果按照现代隔离等级模型，PostgreSQL的RR隔离等级实际上是快照隔离SI，无法解决A5B写偏差的问题。直到9.2引入可序列化快照隔离SSI之后才有真正意义上的SR，如下表所示：
| 标称 | 实际 | P2 | P3 | A5A | P4 | A5B |
|---|---|---|---|---|---|---|
| RC | RC | ⚠️ | ⚠️ | ⚠️ | ⚠️ | ⚠️ |
| RR | SI | ✅ | ✅ | ✅ | ✅ | ⚠️ |
| SR | SR | ✅ | ✅ | ✅ | ✅ | ✅ |
作为一种粗略的理解，可以将RC等级视作语句级快照，而将RR等级视作事务级快照。
防止脏写与脏读可以简单地通过数据项上的读锁与写锁实现。因为大多数数据库使用RC作为默认隔离等级，因此脏写P0，脏读P1等异常通常很难遇到，就不再展开了。下面以PostgreSQL为例，介绍这几种可能出现的并发异常现象：
P2：不可重复读
P3：幻读
A5A：读偏差
P4：丢失跟新
A5B：写偏差
这五种异常有两种分类方式，第一可以按照隔离等级来区分。
P2，P3，A5A，P4是RC中会出现，RR不会出现的异常；A5B是RR中会出现，SR中不会出现的异常。
P2，P3，A5A是读事务与写事务之间的并发异常，而P4与A5B则是读写事务之间的并发异常。
读-写异常
让我们先来考虑一种比较简单的情况：一个只读事务与一个读写事务之间的冲突。例如：
P2：不可重复读
P3：幻读
A5A：读偏差
在PostgreSQL中，这三种异常都会在RC隔离等级中出现，但使用RR隔离等级就不会有这些问题。
不可重复读 P2
假设我们有一张账户表，存储了用户的银行账户余额，id是用户标识，balance是账户余额，其定义如下
CREATE TABLE account(id INTEGER PRIMARY KEY,
balanceINTEGER
);
譬如，在事务1中前后进行两次相同的查询，但两次查询间，事务2写入并提交，结果查询得到的结果不同。
START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T1, RC, 只读START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2, RC, 读写
SELECT * FROM account WHEREk = 'a'; -- T1, 查询账户a，看不到任何结果
INSERT INTO account VALUES('a', 500); -- T2, 插入记录(a,500)
COMMIT; -- T2, 提交
SELECT* FROM account WHERE id = 'a'; -- T1, 重复查询，得到结果(a,500)
COMMIT; -- T1陷入迷惑，为什么同样的查询结果不同？
对于事务1而言，在同一个事务中执行相同的查询，竟然会出现不一样的结果，也就是说读取的结果不可重复。这就是不可重复读的一个例子，即现象P2。在PostgreSQL的RC级别中是会出现的，但如果将事务T1的隔离等级设置为RR，就不会出现这种问题了：
START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T1, RR, 只读START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2, RC, 读写
SELECT * FROM counter WHERE k = 'x'; -- T1, 查询不到任何结果
INSERT INTO counter VALUES('x', 10); -- T2, 插入记录(x,1RR
COMMIT; -- T2, 提交
SELECT * FROM counter WHERE k = 'x'; -- T1, 还是查询不到任何结果
COMMIT; -- T1, 在RR下，两次查询的结果保持一致。
幻读 P3
在ANSI SQL92中，幻读是用于区分RR和SR的现象，实际上它经常与不可重复读P2混为一谈。唯一的区别在于读取列时是否使用了谓词（predicate），也就是Where条件。将上一个例子中查询是否存在账户，变为满足特定条件账户的数目，就成了一个所谓的“幻读”问题。
START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T1, RC, 只读START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2, RC, 读写
SELECT count(*) FROM account WHERE balance > 0; -- T1, 查询有存款的账户数目。0
INSERT INTO account VALUES('a', 500); -- T2, 插入记录(a,500)
COMMIT; -- T2, 提交
SELECT count(*) FROM account WHERE balance > 0; -- T1, 查询有存款的账户数目。1
COMMIT; -- T1陷入迷惑，为什么冒出来一个人？
同理，事务1在使用PostgreSQL的RR隔离级别之后，事务1就不会看到满足谓词P的结果发生变化了。
START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T1, RR, 只读START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2, RC, 读写
SELECT count(*) FROM account WHERE balance > 0; -- T1, 查询有存款的账户数目。0
INSERT INTO account VALUES('a', 500); -- T2, 插入记录(a,500)
COMMIT; -- T2, 提交
SELECT count(*) FROM account WHERE balance > 0; -- T1, 查询有存款的账户数目。0
COMMIT; -- T1, 读取到了一致的快照（虽然不是最新鲜的）
之所以有这种相当Trivial的区分，因为基于锁的隔离等级实现往往需要额外的谓词锁机制来解决这类特殊的读-写冲突问题。但是基于MVCC的实现，以PostgreSQL的SI为例，就天然地一步到位解决了所有这些问题。
幻读看上去不严重，但它通常是导致最为微妙错误：写人偏差 A5B的前提条件：因为看到了幻象，才进行了错误的写入。
读偏差 A5A
另一类读-写异常是读偏差（A5A）：考虑一个直观的例子，假设用户有两个账户：a和b，各有500元。
-- 假设有一张账户表，用户有两个账户a，b，各有500元。CREATE TABLE account(
id INTEGER PRIMARY KEY,
balance INTEGER
);
INSERTINTOaccount VALUES('a', 500), ('b', 500);
现在用户向系统提交从账户b向账户a转账100元的请求，并从网页上并查看自己的账户余额。在RC隔离级别下，下列操作历史的结果可能会让用户感到困惑：
START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T1, RC, 只读，用户观察START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2, RC, 读写，系统转账
SELECT * FROM account WHERE id = 'a'; -- T1, 用户查询账户a, 500元
UPDATE account SET balance -= 100 WHERE id = 'b'; -- T2, 系统扣减账户b 100元
UPDATE account SET balance += 100 WHERE id = 'b'; -- T2, 系统添加账户a 100元
COMMIT; -- T2, 系统转账事务提交提交
SELECT * FROM account WHERE id = 'a'; -- T1, 用户查询账户b, 400元
COMMIT; -- T1, 用户陷入迷惑，为什么我总余额(400+500)少了100元？
这个例子中，只读事务读取到了系统的一个不一致的快照。这种现象称为读偏差（read skew），记作A5A。
在一些场景中，我们希望获取一致的状态快照，读偏差是不能接受的。一个典型的场景就是备份。通常对于大型数据库，备份需要花费若干个小时。备份进程运行时，数据库仍然会接受写入操作。因此如果存在读偏差，备份可能会包含一些旧的部分和一些新的部分。如果从这样的备份中恢复，那么不一致（比如消失的钱）就会变成永久的。此外，一些长时间运行的分析查询通常也希望能在一个一致的快照上进行。如果一个查询在不同时间看见不同的东西，那么返回的结果可能毫无意义。
快照隔离是这个问题最常见的解决方案。PostgreSQL的RR隔离等级实际上就是快照隔离，提供了事务级一致性快照的功能。例如，如果我们将T1的隔离等级设置为可重复读，就不会有这个问题了。
START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T1, RR, 只读，用户观察START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2, RC, 读写，系统转账
SELECT * FROM account WHERE id = 'a'; -- T1 用户查询账户a, 500元
UPDATE account SET balance -= 100 WHERE id = 'b'; -- T2 系统扣减账户b 100元
UPDATE account SET balance += 100 WHERE id = 'b'; -- T2 系统添加账户a 100元
COMMIT; -- T2, 系统转账事务提交提交
SELECT * FROM account WHERE id = 'a'; -- T1 用户查询账户b, 500元
COMMIT; -- T1没有观察到T2的写入结果{a:600,b:400}，但它观察到的是一致性的快照。
读写异常小结
以上这几个异常有一个共性，就是都是只读事务与写入事务之间的并行冲突。它们都发生在RC级别，都在RR级别被解决。其根本原因在于，RC实质上可以视作语句级别的快照，而RR则是事务级别的快照。因此在RC等级中，如果事务涉及到多条读查询，则实际上可能观察到几个不同快照中的状态。
写-写异常
上一节讨论了只读事务在并发写入时可能发生的异常。通常这种读取异常可能只要稍后重试就会消失，但如果涉及到写入，问题就比较严重了，因为这种读取到的暂时不一致状态很可能经由写入变成永久性的不一致……。
到目前为止已经讨论的读已提交和快照隔离级别，只讨论了在并发写入发生时，只读事务可以看见什么。如果两个事务并发执行写入，还可能会有一种更有趣的写-写异常：
P4： 丢失更新：RC存在，RR不存在。
A5B：写入偏差：RC，RR存在，SR不存在。
其中，写偏差（A5B）可以视作丢失更新（P4）的泛化情况。快照隔离能够解决丢失更新的问题，却无法解决写入偏差的问题。解决写入偏差需要真正的可序列化隔离等级。
丢失更新-例1
仍然以上文中的账户表为例，假设有一个账户x，余额500元。
CREATE TABLE account(id TEXT PRIMARY KEY,
balance INTEGER
);
INSERT INTO account VALUES('x', 500);
有两个事务T1，T2，分别希望向该账户打入两笔钱，比如一笔100，一笔200。从顺序执行的角度来看，无论两个事务谁先执行，最后的结果都应当是余额 = 500 + 200 + 100 = 800。
START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T1START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2
SELECT balance FROM account WHERE id = 'x'; -- T1, 查询当前余额=500
SELECT balance FROM account WHERE id = 'x'; -- T2, 查询当前余额也=500
UPDATE account SET balance = 500+ 100; -- T1, 在原余额基础上增加100元
UPDATE account SET balance = 500+ 200; -- T2, 在原余额基础上增加200元,被T1阻塞。
COMMIT; -- T1, 提交前可以看到余额为600。T1提交后解除对T2的阻塞，T2进行了更新。
COMMIT; -- T2, T2提交,提交前可以看到余额为700
-- 最终结果为700
但奇妙的时机导致了意想不到的结果，最后账户的余额为700元，事务1的转账更新丢失了！
但令人意外的是，两个事务都看到了UPDATE 1的更新结果，都检查了自己更新的结果无误，都收到了事务成功提交的确认。结果事务1的更新丢失了，这就很尴尬了。最起码事务应当知道这里可能出现问题，而不是当成什么事都没有就混过去了。
如果使用RR隔离等级（主要是T2，T1可以是RC，但出于对称性尽量都用RR），后执行更新的语句就会报错中止事务。这就允许应用知耻而后勇，进行重试。
START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T1, 这里RC也可以START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T2, 关键是T2必须为RR
SELECT balance FROM account WHERE id = 'x'; -- T1, 查询当前余额=500
SELECT balance FROM account WHERE id = 'x'; -- T2, 查询当前余额也=500
UPDATE account SET balance = 500+ 100; -- T1, 在原余额基础上增加100元
UPDATE account SET balance = 500+ 200; -- T2, 在原余额基础上增加200元,被T1阻塞。
COMMIT; -- T1, 提交前可以看到余额为600。T1提交后解除对T2的阻塞
-- T2 Update报错：ERROR: could not serialize access due to concurrent update
ROLLBACK; -- T2, T2只能回滚
-- 最终结果为600，但T2知道了错误可以重试，并在无竞争的环境中最终达成正确的结果800。
当然我们可以看到，在RC隔离等级的情况中，T1提交，解除对T2的阻塞时，Update操作已经能够看到T1的变更了（balance=600）。但事务2还是用自己先前计算出的增量值覆盖了T1的写入。对于这种特殊情况，可以使用原子操作解决，例如：UPDATE account SET balance = balance + 100;。这样的语句在RC隔离级别中也能正确地并发更新账户。但并不是所有的问题都能简单到能用原子操作来解决的，让我们来看另一个例子。
丢失更新-例2
让我们来看一个更微妙的例子：UPDATE与DELETE之间的冲突。
假设业务上每人最多有两个账户，用户最多能选择一个账号作为有效账号，管理员会定期删除无效账号。
账户表有一个字段valid表示该账户是否有效，定义如下所示：
CREATE TABLE account(id TEXT PRIMARY KEY,
valid BOOLEAN
);
INSERT INTO account VALUES('a', TRUE), ('b', FALSE);
现在考虑这样一种情况，用户要切换自己的有效账号，与此同时管理员要清理无效账号。
从顺序执行的角度来看，无论是用户先切换还是管理员先清理，最后结果的共同点是：总会有一个账号被删掉。
START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T1, 用户更换有效账户START TRANSACTION ISOLATION LEVEL READ COMMITTED; -- T2, 管理员删除账户
UPDATE account SET valid = NOT valid; -- T1, 原子操作，将有效账户无效账户状态反转
DELETE FROM account WHERE NOT valid; -- T2, 管理员删除无效账户。
COMMIT; -- T1, 提交，T1提交后解除对T2的阻塞
-- T2 DELETE执行完毕，返回DELETE 0
COMMIT; -- T2, T2能正常提交，但检查的话会发现自己没有删掉任何记录。
-- 无论T2选择提交还是回滚，最后的结果都是(a,f),(b,t)
从下图中可以看到，事务2的DELETE原本锁定了行(b,f)准备删除，但因为事务1的并发更新而阻塞。当T1提交解除T2的阻塞时，事务2看见了事务1的提交结果：自己锁定的那一行已经不满足删除条件了，因此只好放弃删除。
相应的，改用RR隔离等级，至少给了T2知道错误的机会，在合适的时机重试就可以达到序列执行的效果。
START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T1, 用户更换有效账户START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T2, 管理员删除账户
UPDATE account SET valid = NOT valid; -- T1, 原子操作，将有效账户无效账户状态反转
DELETE FROM account WHERE NOT valid; -- T2, 管理员删除无效账户。
COMMIT; -- T1, 提交，T1提交后解除对T2的阻塞
-- T2 DELETE报错：ERROR: could not serialize access due to concurrent update
ROLLBACK; -- T2, T2只能回滚
RR隔离级别小结
上面提到的异常，包括P2，P3，A5A，P4，都会在RC中出现，但却不会再RR中出现。
RR解决的问题一言以蔽之，就是提供了事务级别的快照。因而各种读-写异常（P2，P3，A5A）都不会再出现了。而且，RR还可以解决丢失更新（P4）的问题。
丢失更新是一种相当常见的问题，因此也有不少应对的方法。典型的方式有三种：原子操作，显式锁定，冲突检测。原子操作通常是最好的解决方案，前提是你的逻辑可以用原子操作来表达。如果数据库的内置原子操作没有提供必要的功能，防止丢失更新的另一个选择是让应用显式地锁定将要更新的对象。然后应用程序可以执行读取-修改-写入序列，如果任何其他事务尝试同时读取同一个对象，则强制等待，直到第一个读取-修改-写入序列完成。（例如MySQL和PostgreSQL的FOR UPDATE子句）
另一种应对丢失更新的方法是自动检测。如果事务管理器检测到丢失更新，则中止事务并强制它们重试其读取-修改-写入序列。这种方法的一个优点是，数据库可以结合快照隔离高效地执行此检查。事实上，PostgreSQL的可重复读，Oracle的可串行化和SQL Server的快照隔离级别，都会自动检测到丢失更新，并中止惹麻烦的事务。但是，MySQL/InnoDB的可重复读并不会检测丢失更新。一些专家认为，数据库必须能防止丢失更新才称得上是提供了快照隔离，所以在这个定义下，MySQL下没有提供快照隔离。
但就算每个事务都能看到一致的快照，但仍然有一些问题是无法解决的。在PostgreSQL的RR（实际是SI）隔离等级中，一种称为写偏差（A5B）的问题仍然可能会发生。丢失更新其实是写偏差的一种特例：两个写入事务竞争写入同一条记录。竞争写入同一条数据能够被数据库的丢失更新检测机制发现，但如果两个事务写入了不同的数据项，又怎么办呢？
写偏差 A5B
考虑一个运维值班的例子：互联网公司通常会要求几位运维同时值班，但底线是至少有一位运维在值班。运维可以翘班，只要至少有一个同事在值班就行：
CREATE TABLE duty (name TEX TPRIMARY KEY,
oncall BOOLEAN
);
-- Alice和Bob都在值班
INSERT INTO duty VALUES('Alice', TRUE), ('Bob', True);
假如应用逻辑约束是：不允许无人值班。即：SELECT count(*) FROM duty WHERE oncall值必须大于0。现在假设A和B两位运维正在值班，两人都感觉不舒服决定请假。不幸的是两人同时按下了翘班按钮。则下列执行时序会导致异常的结果：
START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T2, Bob
SELECT count(*) FROM duty WHERE oncall; -- T1, 查询当前值班人数, 2
SELECT count(*) FROM duty WHERE oncall; -- T2, 查询当前值班人数, 2
UPDATE duty SET oncall = FALSE WHERE name = 'Alice'; -- T1, 认为其他人在值班，Alice翘班
UPDATE duty SET oncall = FALSE WHER Ename = 'Bob'; -- T2, 也认为其他人在值班，Bob翘班
COMMIT; -- T1
COMMIT; -- T2
SELECT count(*) FROM duty; -- 观察者, 结果为0, 没有人在值班了！
两个事务看到了同一个一致性快照，首先检查翘班条件，发现有两名运维在值班，那么自己翘班是ok的，于是更新自己的值班状态并提交。两个事务都提交之后，没有运维在值班了，违背了应用定义的一致性。
但如果两个事务并不是同时（Concurrently）执行的，而是分了先后次序，那么后一个事务在执行检查时就会发现不满足翘班条件而终止。因此，事务之间的并发导致了异常现象。
对事务而言，明明在执行翘班操作之前看到值班人数为2，执行翘班操作之后看到值班人数为1，但为啥提交之后看到的就是0了呢？这就好像看见幻象一样，所以称其为幻读。如果其中一个（只读）事务只是看到了幻象，那这确实是幻读。但如果它还基于幻象进行了冲突的写入，这种异常就称为写偏差。
问题的关键在于不同读写事务之间的读写依赖。如果某个事务读取了一些数据作为行动的前提，那么如果当该事务执行后续写入操作时，这些被读取的行已经被其他事务修改，这就意味着事务依赖的前提可能已经改变。
此类问题的共性
事务基于一个前提采取行动（事务开始时候的事实，例如：“目前有两名运维正在值班”）。之后当事务要提交时，原始数据可能已经改变——前提可能不再成立。
一个
SELECT查询找出符合条件的行，并检查是否满足一些约束（至少有两个运维在值班）。根据第一个查询的结果，应用代码决定是否继续。（可能会继续操作，也可能中止并报错）
如果应用决定继续操作，就执行写入（插入、更新或删除），并提交事务。
这个写入的效果改变了步骤2 中的先决条件。换句话说，如果在提交写入后，重复执行一次步骤1 的SELECT查询，将会得到不同的结果。因为写入改变符合搜索条件的行集（只有一个运维在值班）。
在SI中，每个事务都拥有自己的一致性快照。但SI是不提供线性一致性（强一致性）保证的。事务看到的快照副本可能因为其他事务的写入而变得陈旧，但事务中的写入无法意识到这一点。
与丢失更新的联系
作为一个特例，如果不同读写事务是对同一数据对象进行写入，这就成了丢失更新问题。通常会在RC中出现，在RR/SI隔离级别中避免。对于相同对象的并发写入可以被数据库检测出来，但如果是向不同数据对象写入，违背应用逻辑定义的约束，那RR/SI隔离等级下的数据库就无能为力了。
解决方案
有很多种方案能应对这些问题，可序列化当然是ok的，但也存在一些其他手段，例如锁
显式锁定
START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T1, 用户更换有效账户START TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- T2, 管理员删除账户
SELECT count(*) FROM duty WHERE oncall FOR UPDATE; -- T1, 查询当前值班人数, 2
SELECT count(*) FROM duty WHERE oncall FOR UPDATE; -- T2, 查询当前值班人数, 2
WITH candidate AS(SELECT name FROM duty WHERE oncall FOR UPDATE)
SELECT count(*) FROM candidate; -- T1
WITH candidate AS(SELECT name FROM duty WHERE oncall FOR UPDATE)
SELECT count(*) FROM candidate; -- T2, 被T1阻塞
UPDATE duty SET oncall = FALSE WHERE name = 'Alice'; -- T1, 执行更新
COMMIT; -- T1, 解除T2的阻塞
-- T2报错：ERROR: could not serialize access due to concurrent update
ROLLBACK; -- T2 只能回滚
使用SELECT FOR UPDATE语句，可以显式锁定待更新的行，这样，当后续事务想要获取相同的锁时就会被阻塞。这种方法在MySQL中称为悲观锁。这种方法本质上属于一种物化冲突，将写偏差的问题转换成了丢失更新的问题，因此允许在RR级别解决原本SR级别才能解决的问题。
在最极端的情况下（比如表没有唯一索引），显式锁定可能蜕化为表锁。无论如何，这种方式都有相对严重的性能问题，而且可能更频繁地导致死锁。因此也存一些基于谓词锁和索引范围锁的优化。
显式约束
如果应用逻辑定义的约束可以使用数据库约束表达，那是最方便的。因为事务会在提交时（或语句执行时）检查约束，违背了约束的事务会被中止。不幸的是，很多应用约束都难以表述为数据库约束。
可序列化
使用可序列化隔离等级可以避免这一问题，这也是可序列化的定义：避免一切序列化异常。这可能是最简单的方法了，只需要使用SERIALIZABLE就可以了。
START TRANSACTION ISOLATION LEVEL SERIALIZABLE; -- T2, Bob
SELECT count(*) FROM duty WHERE oncall; -- T1, 查询当前值班人数, 2
SELECT count(*) FROM duty WHERE oncall; -- T2, 查询当前值班人数, 2
UPDATE duty SET oncall = FALSE WHERE name = 'Alice'; -- T1, 认为其他人在值班，Alice翘班
UPDATE duty SET oncall = FALSE WHERE name = 'Bob'; -- T2, 也认为其他人在值班，Bob翘班
COMMIT; -- T1
COMMIT; -- T2, 报错中止
-- ERROR: could not serialize access due to read/write dependencies among transactions
-- DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt.
-- HINT: The transaction might succeed if retried.
在事务2提交的时候，会发现自己读取的行已经被T1改变了，因此中止了事务。稍后重试很可能就不会有问题了。
PostgreSQL使用SSI实现可序列化隔离等级，这是一种乐观并发控制机制：如果有足够的备用容量，并且事务之间的争用不是太高，乐观并发控制技术往往表现比悲观的要好不少。
数据库约束，物化冲突在某些场景下是很方便的。如果应用约束能用数据库约束表示，那么事务在写入或提交时就会意识到冲突并中止冲突事务。但并不是所有的问题都能用这种方式解决的，可序列化的隔离等级是一种更为通用的方案。
小结
本文简要介绍了并发异常，这也是事务ACID中的“隔离性”所要解决的问题。本文简单讲述了ANSI SQL92标准定义的隔离等级以及其缺陷，并简单介绍了现代模型中的隔离等级（简化）。最后详细介绍了区分隔离等级的几种异常现象。当然，这篇文章只讲问题，关于这些隔离等级背后的实现原理，将留到下一篇文章来陈述。
Reference
【1】Designing Data-Intensive Application，ch7
【2】Highly Available Transactions: Virtues and Limitations
【3】A Critique of ANSI SQL Isolation Levels