这一章在做什么

读之前：先预测

第 4 章讲一台机器上的存储引擎，这一章开始把数据放到好几台机器上，每个副本里跑的仍是那些引擎，主库甚至可以直接把预写日志发给从库。后面几章都从这里接着走：第 7 章去掉「每台机器都装得下全部数据」这个假设，讲分片；第 9 章细说这一章反复碰到的不可靠的网络和时钟；第 10 章的共识，正是自动选出新主库要解决的问题；第 12 章的变更数据捕获，用的就是这里的逻辑日志。

1. 异步复制的主库坏了，换一个从库当主库，已经告诉用户「成功」的写为什么可能就此消失？§1.1§1.3
2. 复制延迟会造成哪三种怪象？每一种要靠哪一种保证挡住？§1.5
3. 两个主库同时改了同一条记录，有哪几种收场的办法，各自丢掉了什么？§2.3
4. 无主复制里 w + r > n 为什么通常能读到最新值，又在哪些情况下不灵？§3.1

这一章的骨架

这一章按「谁能收写」分成三大块：单主（§1）、多主（§2）、无主（§3），后两块都比第一块短，因为很多问题前面已经铺好了。容易乱的是两处：§1 里同步与异步、故障切换、日志格式、复制延迟一路排下来，前四节都是在为 §1.5 做铺垫；§2.3 的冲突解决和 §3.4 的并发检测是同一个问题的两半，隔着一大块无主复制，读到 §3.4 时要回头把它们接上。

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

分节地图

全章约 1.8 万词（不算图注），建议分五次读。第二次的 §1.5 和第三次的 §2.3 是全章的重心；第四、五次讲无主复制，§3.4 的版本号例子要拿笔跟着算一遍。

1. 第一次坐下§0–§1.3 · 约 3700 词 · 单主复制怎么搭起来，节点坏了怎么办
2. Replication means keeping a copy…约 600 词开篇复制的三个理由，三种做法的总览。方框讲复制和备份为什么不能互相替代。
3. Single-Leader Replication约 400 词单主复制主库收所有写，从库按同样顺序重放复制日志。哪些系统是这么做的。
4. Synchronous Versus Asynchronous Replication约 600 词同步复制与异步复制主库等不等从库确认：各自换来什么、丢掉什么，半同步怎么折中。
5. Setting Up New Followers约 900 词添加新的从库不停机加从库靠快照加日志位置。方框讲把数据库放在对象存储上的利弊。
6. Handling Node Outages约 1300 词处理节点宕机从库挂了怎么追上；主库挂了的故障切换分三步，留意每一步能出的事。
7. 第二次坐下§1.4–§1.6 · 约 3300 词 · 复制日志的格式，复制延迟的三种怪象
8. Implementation of Replication Logs约 1000 词复制日志的实现语句、预写日志、逻辑日志三种格式，看它们和存储引擎绑得多紧。
9. Problems with Replication Lag约 2000 词复制延迟带来的问题读扩展只能配异步复制，于是有了三种怪象和对应的三种保证。最该细读的一节。
10. Solutions for Replication Lag约 300 词复制延迟的解决办法在应用里补，还是换一个强一致的数据库？NoSQL 和 NewSQL 的来回。
11. 第三次坐下§2–§2.3 · 约 5100 词 · 多主复制和写冲突
12. Multi-Leader Replication约 300 词多主复制让不止一个节点收写。同步的多主等于单主，所以只讨论异步的。
13. Geographically Distributed Operation约 1200 词跨地域运行每个区域一个主库，从四个方面和单主对比；再看几种复制拓扑各自的毛病。
14. Sync Engines and Local-First Software约 1100 词同步引擎与本地优先软件离线可用和实时协作的应用，本质上都是多主复制。同步引擎的好处和适用范围。
15. Dealing with Conflicting Writes约 2500 词处理写冲突避免冲突、最后写入者胜、手动解决、自动合并。注意每种办法丢掉的是什么。
16. 第四次坐下§3–§3.2 · 约 3000 词 · 无主复制和法定人数
17. Leaderless Replication约 300 词无主复制不要主库，任何副本都能直接收写。Dynamo 风格这个叫法的来历。
18. Writing to the Database When a Node Is Down约 2000 词有节点宕机时怎么写读写都发给多个副本：漏掉的写怎么补，w + r > n 保证什么、不保证什么。
19. Single-Leader Versus Leaderless Replication Performance约 700 词单主与无主的性能对比无主为什么更扛慢节点和灰色故障，它自己又有哪些性能问题。
20. 第五次坐下§3.3–§4 · 约 2800 词 · 跨区域、检测并发写，加小结
21. Multi-Region Operation约 200 词跨区域运行无主数据库跨区域时怎么转发写、怎么选一致性级别。
22. Detecting Concurrent Writes约 1900 词检测并发写什么叫「并发」；用版本号分出覆盖和并发，推广到多副本就是版本向量。
23. Summary约 600 词小结全章回顾。先自己回忆一遍再读它。

先用中文过一遍

单主复制：写只进主库，从库照着日志重放

选一个副本当主库，客户端的写都发给它。主库每改一次数据，就把改动记进复制日志发给各个从库，从库按同样的顺序重放一遍；读可以落到任何一个副本上。好比一个班只有一个人记账，其他人照着这份流水抄。

关键的选择是同步还是异步。主库等某个从库确认收到了，才告诉客户端「成功」，这是同步：这个从库一定和主库一样新，可它一卡住，所有写都得停下等它。不等就是异步：写永远不会被从库拖慢，代价是主库如果在改动发出去之前坏掉，客户端已经收到「成功」的写就没了。实际系统常常折中，一个从库同步，其余异步。

主库坏了要故障切换（failover）：先判断它真的死了（通常靠超时），再选一个数据最新的从库接任，最后让客户端和其他从库都改认新主库。每一步都可能出事：超时设长了，恢复得慢；设短了，负载一高就误判。旧主库回来以后如果还以为自己是主库，两个主库同时收写，就是脑裂（split brain）。

复制延迟：刚写完读不到，刷新又倒回去

大多数线上服务读多写少，于是有一种很诱人的做法：多加几个从库分摊读请求，叫读扩展。从库一多，就只能用异步复制，否则任何一个从库出问题，写就全停了。异步就有延迟：平时不到一秒，系统负载高或者网络出问题时，可能是几秒甚至几分钟。只要停止写入、等一会儿，从库终究会追上，这就是最终一致性（eventual consistency）；「终究」是多久，没有上限。

延迟大了，用户会碰到三种怪象。自己刚改的东西刷新后不见了，要的保证叫读己之写（read-after-write）；刷新一次，看到的比上一次还旧，像时间倒流，要的保证叫单调读（monotonic reads）；有先后关系的两次写，读的人看到的顺序反了，比如先看到回复、后看到提问，要的保证叫一致前缀读（consistent prefix reads）。前两种在下面的模拟器里能直接看到。办法本身不复杂，难在应用代码里处处都得想着它。

多主：每个区域都能写，代价是冲突

单主的毛病是所有写都得经过那一个主库。数据库部署在好几个区域（几个地理上分开的数据中心）时，离主库远的用户每次写都要跨洋走一趟；连不上主库，就根本写不了。多主让每个区域都有自己的主库，写在本地完成，再异步同步给其他区域。手机上离线可用的应用、几个人同时编辑一份文档，其实也是多主：每台设备、每个浏览器标签页都是一个能收写的副本，只是网络差到了极点。

代价是冲突。两个主库同时改了同一条记录，各自都说「成功」，同步时才发现对不上。收场的办法大致有四种：从源头上避免（同一条记录只让一个主库写）；比时间戳，留大的，丢掉另一个（最后写入者胜，LWW）；把几个值都留下，交给应用或用户去挑；按数据类型自动合并，文本、列表、计数器都有专门的算法（CRDT 和 OT）。还有一类冲突更隐蔽：两次写各自没问题，合在一起才违反约束，比如演出的同一个座位被两个区域各卖出去一次。

无主：同时写好几个，同时读好几个

无主复制干脆不要主库：客户端（或替它跑腿的协调节点）把写同时发给 n 个副本，等到 w 个确认就算成功；读也同时问 n 个，等 r 个回复，取版本号最大的那个值。只要 w + r > n，写过的那几个副本和读到的那几个副本至少有一个重叠，读就能拿到最新值。有副本宕机也不用故障切换，只要活着的还凑得够 w 和 r。

宕机期间漏掉的写怎么补？读的时候发现某个副本的值旧了，顺手把新值写回去（读修复）；别的副本先替它收着，等它回来再转交（提示移交）；后台进程定期比对副本之间的差异（反熵）。书里接着列了一串「凑够了法定人数也可能读到旧值」的情形，这一段别跳过。

这一章点名的系统

动手：模拟器

先猜：从库 B 落后 4 秒，读请求在 B 和 A 之间轮流（先 B 后 A）。你上传一个文件，接着连刷新 4 次，有几次看不到它？哪一次会比上一次看到的还少？勾上「读己之写」以后，同事上传的文件还会不会忽隐忽现？猜好了再动手。

1. 默认设置下，上传一个文件，连刷新 4 次。哪几次看不到自己的文件？哪一次「时间倒流」？把 B 的延迟调到 1 秒，重置后再做一遍。
2. 重置，勾上「读己之写」，重做第一步：「改读主库」记了几次？再点「同事上传一个文件」，连刷新 3 次，同事的文件为什么还会忽隐忽现？
3. 重置，只勾「单调读」（这里按用户固定读从库 B），上传后连刷新几次：还会倒流吗？自己的文件多久才出现？再把「读己之写」也勾上，看看这次读付出的代价在哪一格。

词与短语

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

§0 Replication means keeping a copy…

§1 Single-Leader Replication

§1.1 Synchronous Versus Asynchronous Replication

§1.2 Setting Up New Followers

§1.3 Handling Node Outages

§1.4 Implementation of Replication Logs

§1.5 Problems with Replication Lag

§1.6 Solutions for Replication Lag

§2.1 Geographically Distributed Operation

§2.2 Sync Engines and Local-First Software

§2.3 Dealing with Conflicting Writes

§3 Leaderless Replication

§3.1 Writing to the Database When a Node Is Down

§3.2 Single-Leader Versus Leaderless Replication Performance

§3.4 Detecting Concurrent Writes

§4 Summary

读完：回到你的预测

判断题：换成你来选

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

和本站其他书对照

值得停下来的句子

one of those writes is randomly chosen to be the winner and the other writes are silently discarded— §2.3。本站译：这几次写里随机挑一个当胜者，其余的悄悄丢掉。

这是作者对「最后写入者胜」的重新定义。名字让人以为系统在尊重时间顺序，可对并发的写来说根本不存在谁先谁后，时间戳只是把随机性藏了起来。值得停下来，是因为 Cassandra、ScyllaDB 这类数据库用的就是这种办法（§3.4），用它之前要先问自己：我的应用丢得起这些写吗？

the resilience of a leaderless system comes from the fact that it doesn’t distinguish between the normal case and the failure case.— §3.2。本站译：无主系统的韧性，来自它不区分正常情况和故障情况。

单主系统平时走一条路，出了故障走另一条路（故障切换），而切换前要先判断「够不够坏」，这个判断本身就会出错。无主系统每次都同时问好几个副本、用最先到的回复，慢一个、坏一个都在日常流程里消化掉了。这句话解释了为什么无主复制特别扛「灰色故障」，也说明它的韧性和它的弱一致性来自同一个设计。

检查一下理解

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

精彩回顾

一句话：复制的难处全在改动：单主让读的人看到延迟，多主和无主让写的人碰上冲突，没有哪一种能两头都躲开。