这一章在做什么

读之前：先预测

第 6、7 章把数据复制、分片到多台机器上；这一章回到一个更老的问题：几个客户端同时读写、任何一步都可能崩溃时，数据库能替应用担下多少。第 4 章的预写日志在这里是原子性和持久性的底座，第 6 章「最后写入胜出」会丢掉的更新，这里正面讲怎么防。往后，第 9 章讲网络和时钟为什么靠不住，第 10 章用共识算法替换两阶段提交里那个单点的协调者，第 12、13 章接着讲「恰好一次」和幂等。

1. 读已提交已经保证了不脏读、不脏写，为什么两个人同时给计数器加一还会少加一次？§2.1§2.3
2. 写偏斜和丢失更新差在哪？为什么快照隔离自带的丢失更新检测抓不住它？§2.4
3. 两阶段锁「先等再说」，SSI「先做再查」。它们各在什么样的负载下吃亏？§3.2§3.3
4. 两阶段提交里，协调者一崩溃，参与者为什么只能干等？§4.1

这一章的骨架

这一章按「事务要对付什么」分三块：出错（§1），并发（§2–§3），跨节点（§4）。篇幅最大、最容易乱的是并发：§2 一级一级讲弱隔离，每讲一级就冒出一种它挡不住的竞争，到 §3 才给出能全挡住的三种实现。读的时候在纸上画一张表：横着是隔离级别，竖着是竞争的种类，每读到一处就填一格。

边读边填：每行一个问题，读到答案就写一两句。只存在你这台设备的浏览器里，别人看不到。

分节地图

全章约 2.2 万词（不算代码和图注），是全书最长的一章，建议分六次读。第二、三次是全章的重心，最好连着读；第四、五次讲可串行化的三种实现；第六次的 XA 部分细节多，抓住「存疑时一直持锁」这一条就够。

1. 第一次坐下§0–§1.2 · 约 4300 词 · 事务是什么，ACID 四个字母各管什么
2. In the harsh reality of…约 500 词开篇会出错的种种；事务是为简化编程而发明的，不是每个应用都离不开它。
3. What Exactly Is a Transaction?约 300 词事务到底是什么从 System R 到 NoSQL 丢掉事务，再到 NewSQL 把它找回来。
4. The Meaning of ACID约 1900 词ACID 的含义四个字母逐个拆开。抓住两点：原子性不管并发，一致性属于应用。方框讲持久性的种种不可靠。
5. Single-Object and Multi-Object Operations约 1600 词单对象与多对象操作什么时候非得一次改好几个对象；单对象也要原子性；中止后重试的几个坑。
6. 第二次坐下§2–§2.2 · 约 3700 词 · 读已提交和快照隔离
7. Weak Isolation Levels约 500 词弱隔离级别数据库为什么不默认可串行化；弱隔离造成的 bug 有多真实。
8. Read Committed约 1000 词读已提交两条保证：不脏读、不脏写。各自通常怎么实现，为什么读不加锁。
9. Snapshot Isolation and Repeatable Read约 2200 词快照隔离与可重复读读偏斜是什么；多版本和可见性规则怎么给出一致的快照；名字为什么一团乱。
10. 第三次坐下§2.3–§2.4 · 约 3100 词 · 两个事务同时写
11. Preventing Lost Updates约 1400 词防止丢失更新读-改-写循环的几种对策，各自要应用做什么；复制的数据库里为什么又不一样。
12. Write Skew and Phantoms约 1700 词写偏斜与幻读两人改的不是同一行，照样出错。抓住几个例子共同的四步套路。
13. 第四次坐下§3–§3.2 · 约 3700 词 · 可串行化：真串行和两阶段锁
14. Serializability约 400 词可串行化弱隔离的困境；实现可串行化的三条路。
15. Actual Serial Execution约 1600 词真正的串行执行单线程一次跑一个事务为什么又行得通了；存储过程和分片各有什么代价。
16. Two-Phase Locking约 1700 词两阶段锁读写互斥的锁、它的性能问题，以及谓词锁、索引范围锁怎么挡住幻读。
17. 第五次坐下§3.3–§4.1 · 约 3900 词 · 乐观的 SSI，然后进入分布式提交
18. Serializable Snapshot Isolation约 1800 词可串行化快照隔离先放行、提交时检查前提有没有过时。留意两种检测情形的区别。
19. Distributed Transactions约 700 词分布式事务单机靠一条提交记录做到原子提交，多个节点为什么不能各提交各的。
20. Two-Phase Commit约 1500 词两阶段提交两轮请求、两次承诺，协调者崩溃时参与者的处境，三阶段提交为什么不现实。
21. 第六次坐下§4.2–§5 · 约 3400 词 · XA 的麻烦、数据库内部的事务、恰好一次
22. Distributed Transactions Across Different Systems约 1800 词跨不同系统的分布式事务XA 怎么工作；存疑的事务为什么一直持锁；协调者坏了谁来收拾。
23. Database-Internal Distributed Transactions约 300 词数据库内部的分布式事务同一套软件内部的两阶段提交，为什么没有 XA 那些毛病。
24. Exactly-Once Message Processing Revisited约 500 词再谈恰好一次的消息处理只用数据库自己的事务，怎样让每条消息的效果恰好出现一次。
25. Summary约 800 词小结全章回顾。先自己把几种竞争和隔离级别对一遍，再读它。

先用中文过一遍

读已提交和快照隔离：读到的是哪个版本

隔离要解决的是：几个事务同时跑，彼此别踩到对方。最弱的一档实用级别是读已提交，它保证两件事：只读得到别人已经提交的数据（不脏读），只覆盖别人已经提交的数据（不脏写）。不脏写靠行锁：要改一行先拿锁，拿到提交或中止才放。不脏读通常不用锁，而是让数据库同时记着这一行的旧值（已提交的）和新值（还没提交的），别的事务来读，就给它旧值。

读已提交挡不住一种情况：一个事务先后读两行，两次之间别人改了这两行并提交了，它看到的是一半旧、一半新。只读一下，过几秒刷新就好；可要是备份或对账这种要跑几个小时的读，就会读出一个从来没存在过的状态。快照隔离的办法是把「旧值和新值」推广成「好几个已提交的版本」：每个版本标着是哪个事务创建的、哪个事务删除的（更新就是删一个旧版本、加一个新版本）。事务开始时记下当时还有哪些事务没提交，之后读任何一行，都只挑「开始那一刻已经提交」的那个版本。这就是多版本并发控制（MVCC）。读的人不挡写的人，写的人也不挡读的人。

两个事务同时写：丢失更新和写偏斜

前面两级主要管「读的人看到什么」。两个事务都要写时，问题更多。最常见的是丢失更新：两个事务都先读一个值、在程序里改、再整个写回去，后写的那个把先写的冲掉了。读已提交挡不住它：后一次写发生在前一个事务提交之后，算不上脏写。对策有好几种：让数据库做原子的「在原值上加减」，显式给要改的行加锁，让数据库自动检测并中止后写的那个，或者用「值没变才写」的条件写。

写偏斜更隐蔽：两个事务读的是同一批数据，改的却是不同的行。每个事务都先查一个条件（「还有空位吗」），按结果决定写入，而它的写入恰好让对方的条件不再成立。因为两人改的不是同一行，行锁、丢失更新检测统统看不到冲突。更麻烦的是，如果条件查的是「没有符合条件的行」，就连一行可以加锁的东西都没有，这就是幻读引起的写偏斜。

要全挡住：可串行化的三种做法

可串行化的意思是：不管事务实际上怎么交错执行，结果都和某个「一个接一个跑」的顺序一样。这样只要每个事务单独跑是对的，一起跑也是对的。书里讲了三种实现。第一种最直接：真的只用一个线程，一次跑一个事务。前提是事务都很短、数据都在内存里，而且事务要写成存储过程整个交给数据库，不能和应用来回聊。第二种是两阶段锁：读要拿共享锁，写要拿排他锁，读写互相等，拿到的锁一直留到事务结束；为了挡住幻读，还要锁住「查询条件」或者索引上的一段范围。第三种是可串行化快照隔离（SSI）：照快照隔离那样放手让事务跑，只是暗中记下谁读了什么、谁写了什么，到提交时检查自己当初读到的前提有没有被别人改掉，改掉了就中止。前两种是悲观的，有风险就等；第三种是乐观的，先做，出了问题再撤。

跨节点提交：两阶段提交的两次承诺

单机上，「提交」落在一个确定的时刻：提交记录写进磁盘上的日志的那一刻。事务涉及好几个节点时，不能简单地给每个节点发一句「提交」：有的节点可能提交了，有的因为冲突、超时或崩溃回滚了，而已经提交的数据别人可能已经读走，收不回来。两阶段提交加了一个协调者，把提交拆成两轮。第一轮问每个参与者「你能提交吗」，参与者答「是」之前，要先把数据写盘、查过约束，答了就不能反悔。第二轮，协调者收齐答复，把决定写进自己的日志，然后通知所有人。这个决定一旦写下，就要不停重试直到人人照办。代价也在这里：参与者答了「是」之后，如果协调者崩溃，它既不能自己提交，也不能自己回滚，只能拿着锁等。

这一章点名的系统

动手：模拟器

先猜：库存 10 件，A 买 1 件、B 买 2 件，都按「读库存 → 写回减过的数 → 提交」来，顺序是 A 读、B 读、A 写、B 写、A 提交、B 提交。读已提交下最后剩几件？换成「快照隔离（检测丢失更新）」，谁会被中止、在哪一步？换成两阶段锁呢？猜好了再点「坏交错：自动走」验证。

1. 场景「丢失更新」，五种隔离级别各点一次「坏交错：自动走」。哪几种最后剩 8 件？其余几种里，B 是在哪一步、因为什么被中止的？点「重试被中止的事务」再把 B 走完，库存对了吗？
2. 场景「写偏斜」，在「快照隔离（检测丢失更新）」下自动走：检测为什么没起作用？换两阶段锁：谁先停下来等、谁被中止，为什么算死锁？换 SSI：两个事务都顺利走到提交，谁在提交那一刻被拒？
3. 场景「读偏斜」，手动走：A 开始、A 读东仓，然后一直点「B 走一步」，直到 B 走完或者走不动，再把 A 走完，最后把 B 走完。读已提交下 A 算出的合计是多少？快照隔离和两阶段锁都给出 100，但 B 的经历完全不同，差在哪？

词与短语

词条按在书里出现的顺序排，按节分组；读一节之前先把这一节的过一遍，读的时候就不用停。斜体小字是原句里连续的几个词，在电子书里搜它就能找到那一句。标着「每个字都认识」的，是字面意思会把你带偏的。行话（compaction、quorum 这类）不在这里，在上面的术语表里。

§0 In the harsh reality of…

§1 What Exactly Is a Transaction?

§1.1 The Meaning of ACID

§1.2 Single-Object and Multi-Object Operations

§2 Weak Isolation Levels

§2.1 Read Committed

§2.2 Snapshot Isolation and Repeatable Read

§2.3 Preventing Lost Updates

§2.4 Write Skew and Phantoms

§3 Serializability

§3.1 Actual Serial Execution

§3.2 Two-Phase Locking

§3.3 Serializable Snapshot Isolation

§4 Distributed Transactions

§4.1 Two-Phase Commit

§4.2 Distributed Transactions Across Different Systems

§4.3 Database-Internal Distributed Transactions

§4.4 Exactly-Once Message Processing Revisited

§5 Summary

读完：回到你的预测

判断题：换成你来选

场景都是本站编的。先选，再看解释；解释里写了对应的节号，拿不准就回原书看那一节。

和本站其他书对照

值得停下来的句子

Transactions are not a law of nature; they were created with a purpose—namely, to simplify the programming model for applications accessing a database.— §0。本站译：事务不是自然规律；它是带着目的被造出来的，那就是让访问数据库的应用编程起来更简单。

这句话定下了全章的读法。既然事务是为了简化编程而存在，评价一个隔离级别、一个提交协议，就要问它替应用挡掉了哪些情况、还剩哪些要应用自己操心。后面讲弱隔离时作者一再抱怨，正是因为它们把一部分复杂度又推回给了应用，而且推得不明不白。

the database guarantees that if the transactions behave correctly when run individually, they continue to do so when run concurrently— §3。本站译：数据库保证，如果事务单独运行时行为正确，那么并发运行时也依然正确。

这是可串行化最有用的一种说法。它把「并发对不对」这个难问题，换成了「单个事务对不对」这个容易的问题，应用开发者只需要想后者。弱隔离级别给不了这句保证，所以每用一个弱隔离级别，你都得回到 §2 那几种竞争，一个一个排查自己的代码。

检查一下理解

用一句话说这一章（写给一个没读过的朋友）：

精彩回顾

一句话：事务把一大类故障和并发问题变成「中止，再试一次」；隔离级别越弱，留给应用自己防的竞争越多。