这一章在做什么

读之前：先预测

这一章紧接着第 11 章：批处理的输入有界，流处理把这个前提拿掉。它把前面几章的零件重新串了一遍：第 4 章的日志结构和合并变成了消息代理的存储和日志压缩，第 6 章的复制日志变成了变更数据捕获，第 8 章的「恰好一次」和第 10 章的共享日志在这里换了个场合再出现。第 13 章接着这一章，讨论怎样用流把各种专门的数据系统接在一起。

1. 传统消息代理和日志式消息代理，「读一条消息」这件事有什么根本不同？这个不同带来了哪些好处和限制？§1.1§1.2
2. 应用同时写数据库和搜索索引，为什么没有任何报错，两边也会永远对不上？§2.1§2.2
3. 按事件发生的时间分窗口统计，什么时候才能宣布一个窗口「结束了」？§3.2
4. 一个跑了几年的作业不能「失败了从头重跑」，它靠什么做到恰好一次的效果？§3.4

这一章的骨架

这一章分三大块：事件怎么传（§1），数据库和流是什么关系（§2），拿到流以后怎么算（§3）。三块之间的线索是「日志」：§1 的日志式代理、§2 的变更数据捕获、§3 的容错，用的都是一条有序、可以从头再读的日志。容易乱的是 §2 和 §3.2：§2 在 CDC、事件溯源、不可变性之间来回比较；§3.2 的几个时间概念要分清是谁的时钟。

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

分节地图

全章约 1.8 万词（不算代码和图注），建议分四次读。第一次讲消息怎么传，节奏平稳；第二次是全章的思想重心，数据库和流其实是一回事；第三次换到流处理，§3.2 讲时间的那一节最需要慢读；第四次的连接和容错，要用到前面所有的概念。

1. 第一次坐下§0–§1.2 · 约 5200 词 · 从批处理到消息代理
2. In Chapter 11 we discussed…约 400 词开篇批处理的输入有界，现实的数据无界。流是什么，这一章分哪三步走。
3. Transmitting Event Streams约 500 词传送事件流事件、生产者、消费者、主题这几个词；为什么轮询数据库不够用。
4. Messaging Systems约 2100 词消息系统两个问题区分各种系统：发得比收得快怎么办，节点崩溃丢不丢。再看直连、代理、确认和重投。
5. Log-Based Message Brokers约 2100 词基于日志的消息代理把消息存进分区的日志，按偏移量读。抓住它和传统代理在并行、顺序、重放上的差别。
6. 第二次坐下§2–§2.3 · 约 5100 词 · 数据库和流是一回事
7. Databases and Streams约 400 词数据库与流反过来，把流的想法用到数据库上：复制日志本来就是一条写事件的流。
8. Keeping Systems in Sync约 600 词让多个系统保持同步同一份数据存在好几个系统里，靠双写同步会出什么事。
9. Change Data Capture约 2200 词变更数据捕获把数据库的变更日志变成公开的流：初始快照、日志压缩、和事件溯源的对比，加一个讲模式的方框。
10. State, Streams, and Immutability约 2000 词状态、流与不可变性可变的状态和不可变的事件日志是什么关系；不可变的好处，和删不掉的麻烦。
11. 第三次坐下§3–§3.2 · 约 3900 词 · 流处理的用途和时间
12. Processing Streams约 500 词处理流拿到流能做的三件事，以及流处理和批处理唯一关键的不同。
13. Uses of Stream Processing约 1700 词流处理的用途复杂事件处理、流分析、维护物化视图、流上搜索，以及为什么 actor 不算流处理。
14. Reasoning About Time约 1700 词关于时间的推理事件时间和处理时间、迟到的事件、该信谁的时钟、四种窗口。全章最该慢读的一节。
15. 第四次坐下§3.3–§4 · 约 3700 词 · 连接、容错和小结
16. Stream Joins约 1700 词流的连接流和流、流和表、表和表三种连接，最后落到「跟哪个时刻的状态连接」。
17. Fault Tolerance约 1300 词容错永远跑不完的作业怎么做到恰好一次：微批、检查点、原子提交、幂等、重建状态。
18. Summary约 800 词小结全章回顾。先自己回忆一遍再读它。

先用中文过一遍

两种消息代理：读完就删，还是读完只挪一下指针

生产者把事件交给代理，代理再交给消费者，这样双方不用同时在线。传统的消息代理（RabbitMQ 这类，遵循 AMQP 或 JMS 标准）像一个任务队列：每条消息单独派给某个消费者，消费者处理完回一个确认，代理就把它删掉；超时没收到确认，就把这条消息重投给别人。这对「每条都很贵、谁处理都行」的任务很合适，代价是消息一旦确认就没了，新来的消费者看不到过去的消息。

日志式代理（Kafka 这类）换了个思路：消息按顺序追加到日志里，日志按分区切开放在多台机器上，每条消息在分区里有一个递增的编号，叫偏移量。消费者读消息不删消息，只记住自己读到了哪个偏移量。好比一群人读同一本账簿，各自夹各自的书签：多个消费者组互不影响，想重新处理昨天的数据，把书签往回挪就行。代价是并行度按分区算：一个分区在一个组里只交给一个消费者，按顺序一条条处理。

让数据库变成一条流：变更数据捕获和事件溯源

一个应用的数据常常要同时放在数据库、缓存、搜索索引和数据仓库里。最直接的同步办法是双写：应用改完数据库，再自己去改索引、清缓存。问题是两个请求同时改同一条记录时，两个系统可能以相反的顺序收到它们，最后各自留下不同的值，而且没有任何报错；另外，一边写成功、一边失败，也会对不上。

变更数据捕获（CDC）的办法是：应用只写数据库，数据库按自己定下的提交顺序把变更写进复制日志，再把这份日志当成一条公开的流，索引、缓存、数仓都只是这条流的消费者。这其实就是第 6 章的主从复制：数据库当主，别的系统当从。事件溯源（第 3 章讲过）走得更远：应用一开始就不写「当前状态」，只把「发生了什么」作为不可变的事件追加进日志，状态全部从日志算出来。

这一节背后有一个更大的想法：可变的状态和不可变的事件日志，是同一样东西的两种样子。仓库的库存是所有入库、出库单算出来的，会员积分是每一次消费和兑换累加出来的。日志存下来，状态随时能重算；数据库存的「当前值」，不过是日志末尾的一份缓存。代价也在这里：日志会一直长，真要删掉某个人的数据，在不可变的世界里很难。

事件时间、处理时间和窗口

流分析常常要「按分钟统计」。可「这一分钟」有两种算法：按事件发生的时间（事件时间），还是按流处理器看到它的时间（处理时间）？平时两者只差几毫秒，可一旦有积压、断网、重启，处理时间就会把一批旧事件当成「刚刚发生」。按事件时间算才对，但新的麻烦来了：你永远说不准一个窗口的事件到齐了没有，总可能有一条还在路上，这就是迟到的事件（straggler）。只能等一会儿再宣布窗口结束；等得越久越完整，结果也出得越晚。

窗口怎么划也有几种。滚动窗口首尾相接、不重叠，每个事件只属于一个窗口；跳跃窗口长度固定但互相重叠，统计更平滑；滑动窗口按事件彼此之间的距离来定，不看固定的边界；会话窗口没有固定长度，同一个用户隔了一段时间没动静，会话就结束。

恰好一次：输出要么全算数，要么全作废

批处理的容错很简单：任务失败了，扔掉它写了一半的输出，换台机器从头再跑，最终结果和没失败一样，好像每条记录恰好处理了一次。流处理做不到「等任务做完再公开输出」，因为它永远做不完。办法是把流切成小段：要么每段当一个小批处理（微批），要么定期给状态拍一张检查点，崩溃后从最近的检查点重来，把之后的输出作废。

这只管得住框架内部。输出一旦离开框架，写进外部数据库、发了邮件，就收不回来了，重来一次就会做两遍。剩下两条路：一是让「处理这条消息」的所有后果（输出、状态变化、移动偏移量）在一个事务里一起提交；二是把写操作做成幂等的，做两遍和做一遍效果一样，比如写入时带上触发它的那条消息的偏移量，重复的就能认出来。

这一章点名的系统

动手：模拟器

书里提到一种特殊消息，告诉下游「从现在起不会再有早于某个时刻的事件」，可以用它来触发窗口。很多流处理框架（比如 Flink）把这个时刻叫作水位线（watermark）。下面的模拟器用一种常见的算法：水位线 ＝ 目前见过的最大事件时间 − 等待时间；水位线越过窗口的结束时刻，窗口就输出；之后才到的、属于这个窗口的事件就是迟到的。

先猜：等待时间为 0 时，32 个事件里会丢掉几个？等 30 秒呢？要把断网网关补发的事件全部收进来，得等多久？代价是什么？猜好了再动手。

1. 等待时间 0 秒、窗口 1 分钟、迟到的丢掉，点「全部放完」，数一数丢了几个；改成 30 秒再看。丢掉的少了，「窗口结束后平均多久才输出」变成了多少？
2. 重置，等待时间 0 秒，一个个点到第 7 个事件（发生在 0:52，路上走了 25 秒），它为什么被丢掉？换成 10 秒，同一个事件为什么就收进去了？
3. 断网网关补发的三个事件，路上走了一分多钟到两分半钟。等待时间要调到多少才一个不丢？这时一共输出了几个窗口？再把「迟到的事件」换成「发更正」，比较两种做法的输出。

词与短语

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

§0 In Chapter 11 we discussed…

§1 Transmitting Event Streams

§1.1 Messaging Systems

§1.2 Log-Based Message Brokers

§2 Databases and Streams

§2.1 Keeping Systems in Sync

§2.2 Change Data Capture

§2.3 State, Streams, and Immutability

§3 Processing Streams

§3.1 Uses of Stream Processing

§3.2 Reasoning About Time

§3.3 Stream Joins

§3.4 Fault Tolerance

§4 Summary

读完：回到你的预测

判断题：换成你来选

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

和本站其他书对照

值得停下来的句子

mutable state and an append-only log of immutable events do not contradict each other; they are two sides of the same coin.— §2.3。本站译：可变的状态和只追加、由不可变事件组成的日志并不矛盾，它们是一枚硬币的两面。

这句话是全章的转折点。前半章把日志当成传消息的管道，到这里日志变成了数据本身：数据库存的当前状态，只是把日志从头算到尾的结果。有了这个视角，CDC、事件溯源、日志压缩、用变更日志做流和表的连接、从日志重建状态，都成了同一件事的不同用法。第 13 章的「拆开数据库」也从这里出发。

you can never be sure whether you have received all the events for a particular window or some are still to come.— §3.2。本站译：你永远无法确定，一个窗口的事件是已经全部收到了，还是有一些还在路上。

批处理没有这个问题：文件读完了，数据就齐了。流处理的很多设计，从等待时间、更正、撤回，到给事件打三个时间戳，都是在跟这句话讨价还价。它没有正确答案，只有取舍：等得越久越完整，结果出得越晚。上面的模拟器就是让你亲手摸一摸这个取舍。

检查一下理解

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

精彩回顾

一句话：流处理是永远不结束的批处理；一条有序、能重放的日志，把消息、数据库和计算接在一起。