第1章 可靠、可扩展与可维护的应用系统

本课程对应Martin Kleppmann著，赵军平、吕云松、耿煜、李三平译《数据密集型应用系统设计》第1版，中国电力出版社2018年9月出版，纸书519页，ISBN 9787519821968。英文原版由O'Reilly于2017年3月出版，616页，ISBN 9781491903063。

O'Reilly第1版完整目录确认3部分、12章与术语表。英文第2版由Martin Kleppmann与Chris Riccomini合著，于2026年出版并重排目录；当前课程对应2018中文第1版，不把第2版静默混入。课程独立重构核心知识、图示与实验，不复制原文。本页逐项覆盖15个正式章/节节点。

从一个不可判定的用户结果开始

先预测：客户端超时后，这次写入究竟未发生、已提交还是仍可能提交？先写用户不变量、允许陈旧窗口、尾延迟和恢复目标，再选择模型、协议或存储结构。不要先看监控图再编故事；先固定输入和预期，运行后才允许修正。

本页主问题是“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”。最终交付不是概念摘要，而是服务目标表、负载画像、故障树、容量曲线与可维护性评审，由独立复跑证明：故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界。

核心词汇与运行边界

可靠性、负载参数、吞吐量、尾延迟、可演化性 构成本页共同语言。每个词都必须回答：谁观察、观察哪个状态、顺序依据是什么、部分故障时会看到什么，以及哪条证据能推翻解释。

正式目录逐节点重构

认识数据系统

目录节点 1/15。 系统边界应按数据责任和用户结果划分，而不是按采购产品名称划分。

把“认识数据系统”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“用户结果与本章问题”，下游是“可靠性”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

可靠性

目录节点 2/15。 可靠不是永不出错，而是在故障存在时持续完成约定功能并限制损害。

把“可靠性”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“认识数据系统”，下游是“硬件故障”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

硬件故障

目录节点 3/15。 冗余只有在故障检测、切换和修复流程被演练后才构成能力。

把“硬件故障”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“可靠性”，下游是“软件错误”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

软件错误

目录节点 4/15。 共享错误输入、资源泄漏与级联重试可同时击穿多个副本。

把“软件错误”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“硬件故障”，下游是“人为错误”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

人为错误

目录节点 5/15。 沙箱、最小权限、审计和可回滚变更比要求人永不犯错更有效。

把“人为错误”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“软件错误”，下游是“可靠性有多重要”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

可靠性有多重要

目录节点 6/15。 可靠性目标取决于业务损失、合规和安全，不能让错误结果冒充高可用。

把“可靠性有多重要”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“人为错误”，下游是“可扩展性”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

可扩展性

目录节点 7/15。 必须先说明增长维度、当前瓶颈和目标服务水平。

把“可扩展性”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“可靠性有多重要”，下游是“描述负载”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

描述负载

目录节点 8/15。 负载参数应捕捉写入率、读写比、热点键、扇出和数据分布。

把“描述负载”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“可扩展性”，下游是“描述性能”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

描述性能

目录节点 9/15。 性能包含吞吐和响应时间分布，P50不能替代P95与P99。

把“描述性能”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“描述负载”，下游是“应对负载的方法”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

应对负载的方法

目录节点 10/15。 纵向、横向、缓存与分区都在重新分配瓶颈和故障成本。

把“应对负载的方法”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“描述性能”，下游是“可维护性”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

可维护性

目录节点 11/15。 运营、理解和变更成本决定系统在长期是否可持续。

把“可维护性”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“应对负载的方法”，下游是“可运维性：让运维更轻松”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

可运维性：让运维更轻松

目录节点 12/15。 状态、依赖、容量和标准操作应可见、可重复、有停止条件。

把“可运维性：让运维更轻松”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“可维护性”，下游是“简单性：管理复杂度”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

简单性：管理复杂度

目录节点 13/15。 简单性是减少意外耦合和隐含状态，不是机械减少代码行数。

把“简单性：管理复杂度”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“可运维性：让运维更轻松”，下游是“可演化性：让变更更容易”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

可演化性：让变更更容易

目录节点 14/15。 兼容接口、渐进迁移和反馈循环决定系统能否持续适应。

把“可演化性：让变更更容易”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“简单性：管理复杂度”，下游是“小结”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

小结

目录节点 15/15。 三类目标相互约束，必须在真实负载和故障下共同验收。

把“小结”放回“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”主线：上游是“可演化性：让变更更容易”，下游是“本章交付与独立验收”。先写权威输入、局部状态、跨边界消息和用户可见结果，再标出延迟、并发、崩溃或重试在哪条边上改变观察。若只能复述术语，不能预测状态转移或构造失败历史，就还没有掌握这个节点。

实验保持版本、数据分布和请求不变，只改变一个机制或故障条件；同时记录正常结果、尾延迟、消息顺序、恢复终点与独立对账。用“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”判断是否通过，不能用进程存活、平均耗时或一次演示成功代替系统语义。

机制推演：状态、顺序与失败

第一步固定状态所有权。写出哪个数据集是权威事实，哪些只是缓存、索引、仓库或UI等派生视图；再写每次转换的输入版本、输出版本和提交点。没有所有权就无法区分恢复、覆盖和冲突，也无法判断“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”中的结果由谁负责。

第二步展开时间线。客户端发送、节点接收、本地持久化、复制或派生、确认和后续读取是不同事件；超时只提供观察者的等待上界，不提供远端提交事实。为每个事件记录逻辑顺序，墙钟仅作诊断。

第三步施加负载与故障。正常路径不能证明队列增长、热点、进程暂停、消息重复、节点崩溃或网络分区时仍满足“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”。最小实验一次只改变一个因素，并保留能复盘状态转移的原始历史。

第四步从外部核对。服务自报成功、任务完成或副本在线都属于被测路径内部证据；必须用业务标识、数量、约束、校验和或独立读取核对。最终材料“服务目标表、负载画像、故障树、容量曲线与可维护性评审”还要包含未覆盖边界与回退。

证据解释与独立交接

契约证据说明什么必须成立：记录业务不变量、请求身份、成功定义、允许陈旧度、顺序模型和SLO。任何模糊词都改写成可观察历史，例如高可用要说明分区哪侧可写，一致要说明允许哪些并发历史。

机制证据说明为什么可能成立：保存数据模型、分区与副本映射、事务或日志位置、消息顺序、版本和配置。只截最终仪表盘会丢失中间状态，无法区分修复、掩盖和错误重试。

负载证据说明在什么规模成立：记录请求分布、热点、并发、数据量、缓存状态、P50/P95/P99、吞吐和资源等待。平均值会隐藏最慢分区、锁队列、压实、检查点与网络抖动。

故障证据说明边界在哪里：在确认、持久化、复制或派生前后分别注入故障，观察重试、选举、回放与补偿。最后用外部读者对账，确认没有丢失、重复、顺序颠倒或约束破坏。

本章回顾

重新完成“把数据库、缓存、索引与消息系统视为一个数据系统，用可靠性、可扩展性和可维护性约束架构”：固定版本和目录，写出用户不变量与权威状态，展开消息时间线，运行基线，再以单一故障寻找反例。最终交付服务目标表、负载画像、故障树、容量曲线与可维护性评审，证明“故障、负载增长或团队变更时，系统仍保持数据正确性、用户SLO和可理解的运维边界”，并保留未解决风险。

复习与生产验收

← 上一页：第1版权威学习地图 · 下一页：第2章 数据模型与查询语言 →