这一章在做什么

读之前：先预测

第 11、12 章讲了批处理和流处理怎么工作；这一章把它们当作材料，回头把全书串起来：第 4 章的索引、第 6 章的复制日志和读己之写、第 8 章的事务和两阶段提交、第 10 章的共识和全序，都会在「派生数据」的眼光下重新出现一次。读的时候要分清两样东西：书里讲过的机制，和作者在这些机制之上提出的主张。第 14 章转向伦理和社会，这一章是技术部分的最后一章。

1. 作者为什么说「先定一个全序」比用 CDC 还是用事件溯源更要紧？什么情况下拿不到全序？§1.1
2. 在数据库里执行 CREATE INDEX，和用流处理器维护一个搜索索引，哪里一样？「拆开数据库」拆的是什么？§2.1
3. TCP 会去重，数据库有事务，流处理器有恰好一次，重复提交为什么还是拦不住？§3.1
4. 把「一致性」拆成两半以后，哪一半可以放松，放松的代价由谁来付？§3.3

这一章的骨架

这一章分三块：§1 说为什么要派生、派生靠什么（一个全序）、它的边界在哪；§2 把派生放大成一种架构观，从数据库内部一路推到用户的设备；§3 回头算正确性的账。容易乱的是 §2 和 §3 之间：§2 讲的多是可能性和好处，§3 才回答「不用分布式事务还对不对」。读 §3 时，把它和 §1.1 里「派生数据和分布式事务」那一小节接起来读。

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

分节地图

全章约 1.7 万词，建议分五次读。前两次讲架构上的主张，第三次从读写路径过渡到正确性，第四次是全章最需要慢读的地方（约束、及时性和完整性），最后一次轻松些。

1. 第一次坐下§0–§1.2 · 约 3000 词 · 为什么要派生，派生靠什么
2. In Chapter 2 we discussed the…约 100 词开篇作者交代这一章的定位：只讲一种思路，立场比前面各章鲜明。
3. Data Integration约 300 词数据集成没有一种软件能包办所有用法，把几种拼在一起成了常态。
4. Combining Specialized Tools by Deriving Data约 1500 词用派生数据组合专用工具先定写入顺序再派生；和分布式事务比；全序拿不到时怎么保住因果。
5. Batch and Stream Processing约 1100 词批处理与流处理两者都在维护派生状态；重新处理历史数据怎样让系统渐进演化。别跳过铁路轨距的方框。
6. 第二次坐下§2–§2.2 · 约 3700 词 · 把数据库拆开，应用围绕数据流
7. Unbundling Databases约 300 词拆开数据库Unix 和关系数据库两种信息管理哲学的对照，这一节想两头兼得。
8. Composing Data Storage Technologies约 1500 词组合多种存储技术建索引和维护派生系统有多像；联邦和拆开；什么时候不该拆。
9. Designing Applications Around Dataflow约 1900 词围绕数据流设计应用应用代码当派生函数，代码和状态分开；用汇率的例子比较同步请求和订阅。
10. 第三次坐下§2.3–§3.1 · 约 4600 词 · 读写路径推到终端，转入正确性
11. Observing Derived State约 2400 词观察派生状态写路径和读路径的边界，一路推到客户端；读请求也可以当事件处理。
12. Aiming for Correctness约 500 词追求正确有状态的系统为什么更要讲正确，现有的事务和一致性概念哪里不够。
13. The End-to-End Argument for Databases约 1800 词数据库的端到端论证重复提交为什么每一层都拦不住；端到端论证是什么，搬到数据系统里意味着什么。
14. 第四次坐下§3.2–§3.3 · 约 3400 词 · 约束、及时性和完整性
15. Enforcing Constraints约 1600 词实施约束唯一性为什么要共识；按值分片的日志怎么实施约束；多分片请求不用原子提交。
16. Timeliness and Integrity约 1800 词及时性与完整性把「一致性」拆成两半；哪些约束可以先违反再补偿；避免协调的系统。
17. 第五次坐下§3.4–§4 · 约 2100 词 · 持续核查，加小结
18. Trust, but Verify约 1600 词信任，但要核查硬件和软件都会出错，怎样持续审计数据；事件日志对审计有什么帮助。
19. Summary约 500 词小结全章回顾。先自己回忆一遍再读它。

先用中文过一遍

派生数据：只写一处，其余按同一个顺序算出来

一份商品数据，可能同时活在交易库、搜索索引、缓存、数仓和推荐模型里。最直觉的做法是让应用把每一处都写一遍，叫双写。第 12 章已经看过它的毛病：两个人几乎同时改同一个商品，两处收到的先后可能相反，各自都「成功」了，结果永远对不上；还可能一处写成、一处失败。

派生的做法是只让一处接受写入，这一处叫记录系统（system of record），其余各处都从它的变更日志里按同样的顺序算出来。先后由日志一家说了算，每个下游只要按顺序、确定性地处理，就会落到同一个结果；处理到一半崩溃，从上次的位置重放，只要处理是幂等的，重放几遍都一样。这就是第 10 章的状态机复制，只不过「副本」换成了形态各异的系统。

代价有两样。一是下游是异步追上来的，刚写完立刻去读派生出来的那一份，可能还是旧的；分布式事务通常保证读到新值，日志派生默认不保证。二是「一处定序」本身有上限：事件多到一台机器排不过来就得分片，分片之间没有先后；跨地区部署时各地区有各自的主；微服务各管各的状态；客户端离线时先改本地。书里有一个社交网络的例子，说明丢掉事件之间的因果顺序，会让一条通知发给不该收到的人。

派生还带来一个好处：可以重算。想换一种数据结构，不必一次性迁移，而是从同一份原始数据再派生一个新视图，新旧并存，先让少量用户走新的，没问题再逐步扩大，出了问题随时退回旧的。

拆开数据库，和读写路径的边界

在数据库里执行 CREATE INDEX，数据库会对表拍一个一致的快照，扫一遍建出索引，再补上建索引期间新来的写，之后每次写表都顺手更新索引。把「表」换成记录系统、「索引」换成搜索服务或缓存、「顺手更新」换成变更数据捕获加流处理器，就是上一节的派生。作者由此主张：一个组织里的全部数据流，可以看成一个巨大的数据库，流处理器相当于触发器和物化视图的维护逻辑，各个派生系统相当于不同类型的索引，只是分散在不同机器上、归不同团队管。这叫拆开（unbundling）数据库。另一条路是联邦数据库（federated database）：在许多存储之上盖一层统一的查询接口。前者统一的是写，后者统一的是读。

派生出来的东西放在哪一层，决定了一次请求的工作怎么分配。数据一写进来就做的部分叫写路径，有人来读时才做的部分叫读路径，派生数据集就是两条路相遇的地方。缓存、索引、物化视图做的事情都一样：把这条边界往读的那一侧推，写的时候多做一点，读的时候省一点。推到最远，就是服务器把变化一路推送到用户设备上，作者把这看作写路径延伸到了终端用户。

端到端：去重要从发起请求的那一端做起

重试会带来重复：一次操作也许其实成功了，只是确认没传回来。底层各有各的去重办法，但各管一段。TCP 用序列号去重，只在一条连接之内有效；数据库的事务通常和一条客户端连接绑在一起；流处理器的恰好一次，管的是它自己处理消息的那一段。手机信号断在「服务器已提交、回包还没到」的那一刻，用户看到失败、再点一次，对服务器是一个新请求，对数据库是一个新事务，哪一层都认不出它是重复的。

办法是让发起请求的那一端生成一个请求 ID，一路带到数据库，在数据库里对它建唯一约束：同一个 ID 第二次插入就失败。这是 Saltzer、Reed、Clark 1984 年的论文《End-to-End Arguments in System Design》提出的端到端论证（end-to-end argument）在数据系统里的样子：有些功能只有通信两端的应用自己才能做完整、做对，底层提供的版本只能降低出事的概率。书里还把同一个论证用到校验和与加密上。

约束、及时性和完整性

用户名不能重复、库存不能为负，这类约束要在并发的请求里定出谁先谁后，第 10 章说过这等价于共识。放到日志里，做法是按要约束的那个值给日志分片：同一个值的请求必然落进同一个分片，一个分片由一个处理器单线程、按顺序地读，排在前面的赢。分片之间互不相干，所以可以加分片来扩展。

一个请求涉及好几个分片时，也不一定要跨分片的原子提交。下图是本站换的例子：用一张优惠券下单，券只能用一次，下单成功后要给商家入账、给用户加积分。请求先作为一条事件写进按券号分片的日志，这一步是原子的；处理器确定性地做判断，再往别的分片发出带着同一个请求 ID 的事件；崩溃重来时，它会作出同样的判断、发出同样的事件，下游按 ID 丢掉重复的。

这样做的代价是，发请求的人不能马上知道结果，要在输出流上等那条消息。作者由此把平常笼统说的「一致性」拆成两件事。及时性（timeliness）：用户看到的是不是最新状态；违反了，等一会儿再看就好。完整性（integrity）：数据有没有丢、有没有算错、有没有自相矛盾；违反了，等多久也不会自己好，要有人去查、去修。事务通常两样一起给，异步的数据流可以只保完整性、放松及时性。再往前一步：如果业务本来就有道歉和补偿的流程（超卖了就退款加赔偿），连约束的检查都可以挪到事后。作者把不需要同步协调、仍保完整性的系统叫作避免协调的（coordination-avoiding）数据系统。

这一章点名的系统

词与短语

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

§0 In Chapter 2 we discussed the…

§1 Data Integration

§1.1 Combining Specialized Tools by Deriving Data

§1.2 Batch and Stream Processing

§2 Unbundling Databases

§2.1 Composing Data Storage Technologies

§2.2 Designing Applications Around Dataflow

§2.3 Observing Derived State

§3 Aiming for Correctness

§3.1 The End-to-End Argument for Databases

§3.2 Enforcing Constraints

§3.3 Timeliness and Integrity

§3.4 Trust, but Verify

读完：回到你的预测

判断题：换成你来选

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

和本站其他书对照

值得停下来的句子

The fastest and most reliable network request is no network request at all!— §2.2。本站译：最快、最可靠的网络请求，就是根本不发请求！

这句话是汇率例子的落点，也是整个「围绕数据流设计」的卖点：与其用到时再去问，不如提前订阅变化、在本地备好。值得停下来，是因为它省掉的那次请求并没有凭空消失，而是换成了一份要保持新鲜的本地副本，以及作者紧接着承认的时间相关的连接问题。读这一章的主张时，都可以这样问一句：省下的东西换到哪里去了。

Violations of timeliness can be annoying and confusing, but violations of integrity can be catastrophic.— §3.3。本站译：违反及时性会让人烦恼、困惑，违反完整性则可能是灾难。

后半章的论证都压在这句话上。只要接受「完整性比及时性要紧得多」，异步的数据流就有了站得住的理由：它放弃的是及时性，守住的是完整性。反过来，如果你的业务里有一个约束必须当场判定、事后补不回来（比如钱已经从取款机里吐出去了），这句话就提醒你，那一处还得付同步协调的代价。

检查一下理解

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

精彩回顾

一句话：只写一处、其余按日志派生；不靠分布式事务，靠端到端的 ID 和持续核查守住完整性。