可靠、可扩展、可维护的应用

一句话

DDIA 第 1 章不教任何一种具体技术，而是搭起全书的思考框架：一套「数据密集型」系统的好坏，落在三个词上——可靠性（reliability）、可扩展性（scalability）、可维护性（maintainability）。它教你把这三件模糊的事变成能量化、能权衡的工程指标，尤其是用响应时间百分位而非平均值来谈性能，为后面 11 章的所有取舍立好标尺。

Glossary · 术语表

坐标

作者 Martin Kleppmann（剑桥研究者、前 LinkedIn 工程师）。本章是全书 Part I「数据系统的基石」的开篇，也是整本书的总纲：它不接续某个具体技术，而是先立标尺；后面每一章——复制、分区、事务、共识、批 / 流处理——都是在这三把尺子之间做具体取舍。可以说，这一章是读懂后面所有权衡的「坐标系」。

这章要解决什么

工程师张口就说系统要高可用、高性能、好扩展，但这些词太滑：多可靠算可靠？「快」是平均快还是最慢也快？「扩展」到底扩什么？没有统一的量化语言，团队就会各说各话、拍脑袋决策。这一章的任务，就是把三个口号拆成能测量、能对话、能权衡的具体概念——这样后面讨论「用单主复制还是无主复制」时，大家才有共同的评判基准。

核心内容，讲透

可靠性：让「故障」别演变成「失效」

可靠性的定义很朴素：出了岔子，系统还能继续正确工作。关键是分清两个词：故障（fault）是单个组件偏离了它该有的表现（一块盘坏了、一个进程崩了、网络抖了）；失效（failure）是系统作为整体停止对外提供服务。故障几乎不可避免，但可以设法不让它升级成失效——这就叫容错（fault-tolerant）。

作者把故障分三类。硬件故障：磁盘平均无故障时间约 10–50 年，机器一多，几乎每天都有盘坏——传统解法是加冗余（RAID、双电源、热备），趋势是往软件层容错靠。软件故障更阴险，因为常是相关联的、成批爆发的系统性错误（某个触发条件下所有节点同时崩、一次闰秒 bug 放倒一整片）。人为故障——配置错误是线上事故的头号原因。对策不是苛求「别出错」，而是在设计上容错：解耦、快速回滚、充分监控，以及像 Netflix 的 Chaos Monkey 那样主动往生产环境注入故障，逼出脆弱点。

表 1 · 三类故障的性格与对策（DDIA 分类）

可扩展性：先量化「负载」，再量化「性能」

可扩展性不是一个「有 / 没有」的标签，而是要具体回答：当负载增长时，系统靠什么手段维持性能？分两步走。

第一步描述负载：用几个负载参数（load parameters）刻画压力——每秒请求数、读写比、同时在线用户、缓存命中率。书里的经典例子是 Twitter 首页时间线：真正的负载参数不是「发推速率」，而是每个用户的粉丝数分布——名人一条推要推送给几千万人，「扇出（fan-out）」才是难点所在。DDIA 引的实测量级很能说明问题：发推平均 4.6k 请求/秒、峰值 12k+，而首页时间线读取高达 300k 请求/秒——读写比约 65:1，压力压在读侧，且每条推都要扇出给作者的所有粉丝。

表 2 · Twitter 首页时间线：两种扇出的量级对比（数字为 DDIA 所引 2012 年前后 Twitter 实测）

Twitter 的最终答案是混合：绝大多数用户走写时扇出，极少数超大 V 走读时合并、在读时把两条来源拼起来——用负载参数（粉丝数分布）本身来分流。这正是「可扩展性没有通用答案、只能针对具体负载定制」的活样板。

第二步描述性能，这里有本章最重要的一课：别用平均值，用百分位。响应时间不是一个数、而是一个分布——大多数请求快、少数很慢。平均值会被少数极端值带偏，也掩盖了「谁在受苦」。正确姿势是看百分位：p50（中位数，一半用户比它快）、p95、p99、p99.9。尾部（p99 及以后）常常最要紧——因为请求最慢的用户，往往正是数据最多、最有价值的那批。亚马逊就用 p99.9 而非平均来定服务目标。

表 3 · 响应时间百分位怎么读、代价几何

尾延迟为什么难缠？一是排队延迟常主导尾部：服务器能并行处理的请求数有限，一个慢请求会把后面排队的都拖慢（队头阻塞 head-of-line blocking）。二是尾延迟放大（tail latency amplification）：若一个页面要并行调用多个后端、必须等最慢的那个才能返回，那么后端只要有一点慢请求，页面级的「慢」就会被放大。算个具体量级：一次用户请求并行访问 100 个后端、每个各有 1% 的概率变慢，则整页被至少一个慢调用拖慢的概率高达 1 − 0.99¹⁰⁰ ≈ 63%——单个后端看着很健康，页面级尾部却已惨不忍睹（这正是 Google 的 Jeff Dean 与 Luiz Barroso 在《The Tail at Scale》里量化的现象）。所以度量要在客户端侧、按百分位持续观测，而不是只看服务端平均。

可维护性：可运维、简单、可演化

软件成本的大头不在开发、在长期维护。作者拆成三条：可运维性（operability）——让运维容易把系统跑好（好的监控、文档、自动化）；简单性（simplicity）——管住复杂度，用好的抽象（abstraction）消除偶发复杂度（accidental complexity，指并非问题本身固有、而是实现方式带来的复杂度），别让系统烂成一团「大泥球（big ball of mud）」；可演化性（evolvability）——让需求变化时容易改。三者共同决定一套系统能不能被人长期、低痛地养着。

关键权衡与选型

表 4 · 纵向扩展 vs 横向扩展

现实里常两者混用：几台够强的机器往往比大量小机器更简单、也更划算。没有万能的扩展魔法——架构永远是针对具体应用的负载特征定制的。

• 平均值 vs 百分位：平均值好算但会骗人；百分位（尤其 p99/p99.9）算起来贵一点，却真实反映最差体验。做选型评测时坚持看尾部。
• 写时扇出 vs 读时合并（图 2）：前者读快写重、适合普通用户，后者写轻读重、适合大 V；Twitter 的答案是按负载参数分而治之的混合方案。
• 可靠性的成本：容错要花冗余（多副本、多机房）成本；不是所有系统都值得同等可靠——有时可以牺牲可靠性换低成本（如可以重算的离线分析任务）。

为什么重要 / 落到真实系统

这一章之所以被无数后端工程师奉为「面试与架构的通用底本」，是因为它给了一套跨技术的评判语言：无论你用 PostgreSQL、Cassandra、Kafka 还是自研系统，谈可靠都能落到「故障是否被容错边界挡住」，谈性能都能落到「p99 是多少、尾延迟从哪来」，谈扩展都能落到「负载参数是什么、怎么加机器」。百分位延迟（p99/p99.9）今天已是各大公司 SLA 与监控面板的标准语言；混沌工程（Chaos Engineering）也从 Netflix 扩散成一门通行实践。后面每一章的技术，都可以放回这三把尺子上评判。

易错点与争议

• 把延迟和响应时间混用：响应时间是客户端看到的总耗时（含排队、网络、重试），延迟只是「等待被服务」那段。谈 SLA 要说清是哪一个。
• 用平均延迟做决策：平均值对尾部不敏感，几乎总是错的度量；但反过来一味死磕 p99.9 也可能为极少数请求过度投入，要按业务权衡。
• 以为「可扩展 = 买更大的机器」：真正的可扩展是面对具体负载增长的应对能力，与架构强绑定，没有通用答案。
• 时代局限：本章 2017 年成书，云原生的弹性伸缩、Serverless、更成熟的可观测性（分布式追踪）此后大幅发展；但「三把尺子 + 百分位」的思维框架至今不过时。
• 「可靠性」不等于「零故障」：追求零故障既不现实也不经济，目标是可控地容错。

要点