这一章在做什么

读之前：先预测

第 1 章讲架构上的几对取舍：事务型和分析型、云服务和自建、分布式和单机。这一章给全书准备一套说话的词：响应时间、百分位、故障与失效、负载、可扩展。后面处处用到它们：第 6 章的复制和第 7 章的分片，分别回答「坏了怎么办」和「装不下、扛不住怎么办」；第 9 章细讲这一章一笔带过的超时和不可预测的延迟；第 12 章回到这里提到的「恰好一次」。

1. 把查询结果预先算好存起来，省的是哪边的活、多出来的是哪边的活？碰上极端的用户怎么办？§1.2
2. 为什么不看平均响应时间，而要看 p99、p999？一个请求要调很多后端时，尾巴为什么变重？§2.2§2.3
3. 故障和失效差在哪？为什么软件故障常常比硬件故障更难对付？§3§3.2
4. 说「X 可扩展」为什么没意义？讨论扩展时该问什么？§4

这一章的骨架

这一章先讲一个案例（§1），然后四项需求各占一节：性能（§2）、可靠性（§3）、可扩展性（§4）、可维护性（§5）。案例里的数字在性能和扩展两节被反复拿来举例，读后面时可以翻回去对。容易乱的是 §2 和 §3：§2 里响应时间、延迟、服务时间三个词有各自的意思；§3 开头那对 fault 和 failure，后面整节都靠它。

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

分节地图

全章约 9100 词（不算代码和图注），建议分三次读，每次一个主题：第一次是案例和性能，第二次是可靠性，第三次是可扩展性和可维护性。第二次的 §3.2 最长，大半是一条条故障的例子，可以读得快些。

1. 第一次坐下§0–§2.3 · 约 3300 词 · 一个案例，然后是怎么描述性能
2. If you are building an application…约 300 词开篇功能需求和非功能需求的区别；这一章挑了哪四项来讲。
3. Case Study: Social Network Home Timelines约 100 词案例：社交网络的首页时间线案例的设定：每天发多少条、平均关注多少人。后面的计算都从这几个数出发。
4. Representing Users, Posts, and Follows约 300 词怎么表示用户、帖子和关注最直接的做法是读的时候现查现拼。算一算它每秒要做多少次查找。
5. Materializing and Updating Timelines约 600 词把时间线物化并保持更新反过来，写的时候先推好。工作量挪到了哪里，两种极端用户怎么处理。
6. Describing Performance约 500 词描述性能吞吐和响应时间，以及两者为什么相互牵连。方框里讲过载后回不来的系统。
7. Latency and Response Time约 400 词延迟和响应时间几个容易混用的词在本书里各指什么；响应时间为什么时快时慢。
8. Average, Median, and Percentiles约 700 词平均值、中位数和百分位数为什么看分布不看平均；高百分位对谁要紧。方框里是几份常被引用的研究，留意作者的保留。
9. Use of Response Time Metrics约 400 词响应时间指标怎么用一次请求调很多后端时尾巴怎么放大；SLO 和 SLA；方框讲百分位怎么算、怎么合。
10. 第二次坐下§3–§3.3 · 约 2600 词 · 可靠性：部件会坏，系统要撑住
11. Reliability and Fault Tolerance约 300 词可靠性和容错「可靠」的几条直观期待；故障和失效这对词怎么分。
12. Fault Tolerance约 400 词容错容错总有范围；为什么有人故意制造故障。
13. Hardware and Software Faults约 1100 词硬件故障和软件故障一组硬件故障率，冗余能做什么；软件故障为什么更难缠。全章最长的一节。
14. Humans and Reliability约 800 词人和可靠性怎么看待人为失误，组织该做什么。方框讲可靠性对普通应用有多要紧。
15. 第三次坐下§4–§6 · 约 3200 词 · 可扩展性和可维护性，加小结
16. Scalability约 300 词可扩展性什么时候该操心扩展，什么时候不该；讨论扩展该问哪几个问题。
17. Understanding Load约 400 词理解负载用什么数描述负载；负载涨了，从哪两个角度看系统的反应。
18. Shared-Memory, Shared-Disk, and Shared-Nothing Architectures约 400 词共享内存、共享磁盘和无共享架构加资源的三种办法，各自卡在哪里。
19. Principles for Scalability约 300 词可扩展的原则为什么没有通用的可扩展架构；两条普遍适用的原则。
20. Maintainability约 300 词可维护性软件的钱大多花在上线以后；可维护性拆成三个方面。
21. Operability: Making Life Easy for Operations约 300 词可运维性：让运维省心自动化的两面；数据系统能替运维做哪些事。
22. Simplicity: Managing Complexity约 500 词简单：管住复杂度「简单」为什么难有客观标准；抽象是对付复杂度的主要工具。
23. Evolvability: Making Change Easy约 300 词可演化性：让改动容易需求总在变；什么让大系统难改。
24. Summary约 300 词小结全章回顾。先自己回忆一遍再读它。

先用中文过一遍

先算好存起来：物化和扇出

书里用社交网络的首页时间线来算这笔账。这里换个场景：外卖 app 里有一页「关注」，列出你收藏的店铺最近发的动态（上新、满减）。第一种做法是读的时候现拼：你一打开，就去查你收藏的四十家店各自最近发了什么，按时间归并，取最新的几十条。发动态很便宜，打开页面却要查四十次；在线的人一多、刷得一勤，查询量是「打开次数 × 收藏数」。

第二种做法是写的时候先推：每个用户有一个收件箱，店铺每发一条，就查出收藏它的人，往每个人的收件箱里放一份。打开页面只读自己的收件箱，一次就够。把查询的结果预先算好存起来，叫物化（materialization），收件箱就是一种物化视图。代价挪到了写这边：一条动态要写的份数等于收藏它的人数，一个请求变成多少个下游请求，这个倍数叫扇出（fan-out）。多数店铺收藏的人不多，没问题；碰上几百万人收藏的连锁品牌，发一条就要写几百万次。读 §1.2 时留意书里对两种极端情况的处理为什么不一样。

响应时间：客户端看到的那个数

描述性能，最常用两个数：吞吐量（每秒处理多少请求）和响应时间（从发出请求到拿到结果）。两者相互牵连：机器越忙，新来的请求越可能要排队，等前面的处理完；吞吐接近机器的上限时，排队时间会急剧变长。

响应时间可以拆开看：请求在网络上走的时间、在服务器上排队的时间、真正被处理的时间（服务时间）、结果传回来的时间。服务端的日志往往只记服务时间。下图三个请求几乎同时到达一台一次只能处理一个请求的服务器：A 碰上了一个慢操作，B 和 C 自己都很快，却只能排在 A 后面。这叫队头阻塞（head-of-line blocking）。服务端的日志说 B 用了 20 毫秒，用户等了 240 毫秒。

看分布，不看平均：百分位和尾巴的放大

同一个请求反复发，每次的响应时间都不一样，所以它是一个分布，不是一个数。把一段时间里的响应时间从快到慢排好，正中间那个是中位数（p50）：一半请求比它快。排在 99% 位置的是 p99：一百个请求里只有一个比它慢。p99、p999 这些高百分位叫尾延迟（tail latency）。平均值把少数特别慢的请求摊薄了，看不出有多少人真的等了那么久。

一个请求要调很多后端时，尾巴会被放大。比如一次搜索要并行查 100 个分片，等全部返回才出结果，整次搜索的时间就是最慢那个分片的时间。每个分片只有 1% 的调用慢，100 个分片里至少碰上一个慢的概率却是 1 − 0.99¹⁰⁰，约 63%。下图是这个概率怎么随分片数涨；下面的模拟器可以自己调参数。

故障不等于失效

可靠性粗略地说是「出了问题还能正常工作」。书里把「问题」分成两层：系统的某个部件不正常了，叫故障（fault）；整个系统不再提供该提供的服务，叫失效（failure）。同一件事，站在不同的层次看法不同：一块盘坏了，对这块盘自己是失效；对一个把数据存了三份的存储系统，只是一个故障。能扛住某些故障、不让它升级成整体失效，叫容错（fault tolerance）；扛不住、一坏就全停的那个部件，叫单点故障。

容错的老办法是冗余：多一块盘、多一路电源、多一台机器。冗余管用有一个前提：备份和原件不会一起坏。读 §3.2 时，拿这个前提去对照书里列的硬件故障和软件故障，再看 §3.3 为什么把人为失误放到组织的层面去谈。

这一章点名的系统

动手：模拟器

先猜：一次搜索并行查 10 个分片，每个分片 1% 的调用要 400 毫秒以上，其余几十毫秒。整次搜索的 p99 是快还是慢？分片加到 100 个，中位数呢？猜好了再选参数验证。

1. 慢调用比例 1%，分片数依次选 1、10、100，看「碰上慢分片的搜索」和搜索的 p50、p99。哪一步 p99 先变慢，哪一步连 p50 也慢了？
2. 分片数 100，把慢调用比例降到 0.1%。中位数回来了，p99 呢？要让 100 个分片的搜索 p99 也快，每个分片得在哪个百分位上快？
3. 分片数 1、慢调用比例 1%，连点几次「换一批」，看搜索的 p99 怎么跳。1000 个样本里，决定 p99 的只有最慢的十来个。

词与短语

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

§0 If you are building an application…

§1.1 Representing Users, Posts, and Follows

§1.2 Materializing and Updating Timelines

§2 Describing Performance

§2.1 Latency and Response Time

§2.2 Average, Median, and Percentiles

§2.3 Use of Response Time Metrics

§3.1 Fault Tolerance

§3.2 Hardware and Software Faults

§3.3 Humans and Reliability

§4 Scalability

§4.1 Understanding Load

§4.3 Principles for Scalability

§5 Maintainability

§5.1 Operability: Making Life Easy for Operations

§5.2 Simplicity: Managing Complexity

§5.3 Evolvability: Making Change Easy

读完：回到你的预测

判断题：换成你来选

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

和本站其他书对照

值得停下来的句子

What we call “human error” is not really the cause of an incident, but rather a symptom of a problem with the sociotechnical system— §3.3。本站译：我们所说的「人为失误」并不真是事故的原因，而是社会技术系统出了问题的症状。

它把追问的方向倒了过来：事故复盘问到「谁按错了按钮」就停，下一次换一个人照样会按错。作者接着把原因落到组织的优先级上（功能和测试二选一时，很多组织选功能），所以 §3.3 的办法几乎都不是技术手段，而是无责复盘、改激励、改投入。这一节让可靠性从硬件和代码延伸到了人。

Scalability is not a one-dimensional label—it is meaningless to say “X is scalable” or “Y doesn’t scale.”— §4。本站译：可扩展性不是一个一维的标签，说「X 可扩展」或「Y 扩展不了」没有意义。

选型争论里常听到「这个库扩展性好」。这句话要求你接着问：沿着哪个方向增长？加什么资源？到哪一步会碰到墙？它也解释了 §4.1 为什么先要把负载描述清楚，负载的形状不同，「能扩展」的意思就不同。

检查一下理解

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

精彩回顾

一句话：快、稳、能扩展、好维护，都要先说成能测的数字，才能看清代价落在哪里。