性能 · 可靠性 · 可伸缩性 · 可维护性
（用最简单的话，把概念关系讲清楚）

1. 这章到底在说什么？

软件系统除了“功能要能用”之外，还必须 快、稳、能扩、好维护。
这一章介绍的就是这四个关键的“非功能性需求”：

四者之间的关系：

• 性能是用户体验最直观的。
• 可靠性保证系统不“突然死掉”。
• 可伸缩性保证“变大之后还能保持性能和可靠性”。
• 可维护性保证系统能在多年后仍能不断被改进。

它们相互影响、互相支撑：
性能和可靠性是短期用户体验，可伸缩性和可维护性是长期系统质量。

2. 用社交网络首页时间线讲清楚这四件事

书中用“类似 Twitter 的时间线系统”作为贯穿案例。

2.1 基础模型：关注关系 + 帖子

• 用户可以发帖、关注他人。
• 读操作最重要：读取“首页时间线”。

2.2 性能瓶颈：查询太贵

直接查询关注的 200 人的最新帖子 → 每秒数百万重查询 → 不可能。

2.3 解决方案：物化时间线（Materialized Timeline）

把每次发的帖 提前写入粉丝的时间线（扇出 fan-out），然后 read 很快。

3. 性能（Performance）

性能主要看两个指标：

3.1 ① 吞吐量（Throughput）

系统每秒能处理多少请求
（例如每秒发 5,700 条帖子、100 万次写入时间线）

3.2 ② 响应时间（Response Time）

用户发起一个请求，到响应返回的时间。

响应时间不是固定的，是 分布，要用 百分位数（p50 / p95 / p99） 描述：

• p50（中位数）：典型用户体验
• p95 / p99：尾部延迟（少量慢请求）
• p999：极端慢请求

百分位数比平均值更真实，因为平均值容易被极慢请求拖歪。

3.3 延迟组成（为什么会慢？）

• 服务处理时间
• 网络延迟
• 排队延迟（最重要，尤其在高负载）

3.4 性能与可伸缩性的联系

什么时候需要扩容？
→ 当吞吐量逼近系统极限、排队变长、p99 变慢。

4. 可靠性（Reliability）

可靠性关注的是：
系统“出问题”时是否还能正常对外提供服务。

关键概念：

4.1 故障（Fault） vs 失效（Failure）

• 故障：部分组件坏了（某台机器挂了）
• 失效：整个系统无法提供服务（整个网站挂了）

可靠系统必须能容忍故障不变成失效。

4.2 容错（Fault Tolerance）

通过冗余、数据副本、心跳检测、failover 等方式确保部分节点坏了系统仍能工作。

4.3 三类故障来源

1. 硬件故障（磁盘坏、机器挂、电源出问题）
2. 软件故障（bug、内存泄漏、闰秒导致挂死）
3. 人为故障（配置错误、误操作）

特别是软件故障往往是“高相关性”的，会导致大面积宕机。

4.4 提升可靠性的手段

• 冗余、数据备份
• 故障注入（Chaos Engineering）
• 自动化运维
• 无责备事后分析（blameless postmortem）

5. 可伸缩性（Scalability）

可伸缩性关注的是：
当负载变大时，系统能否保持性能不变。

5.1 负载（Load）要怎么描述？

• 每秒请求数
• 并发在线用户数
• 数据大小增长率
• 读/写比例
• 极端用户（例如粉丝 1 亿的名人）

描述负载之后，才知道系统瓶颈在哪里。

5.2 两种扩展方式

① 纵向伸缩（Scale Up）

买更大的机器
优点：简单
缺点：贵、有天花板

② 横向伸缩（Scale Out）

加更多的机器，通过分布式系统协作
优点：可以无限扩
缺点：复杂（需要分片、容错、分布式协议等）

5.3 共享架构类型

• 共享内存（shared memory）：同一台机器多线程共享 RAM
• 共享磁盘（shared disk）：多机器使用同一存储
• 无共享架构（shared nothing）：每台机器独立运行（主流）

无共享架构是现代互联网系统的核心。

6. 可维护性（Maintainability）

可维护性关注的是：
系统能否长期演进、好维护、不变成大泥球。

可维护性分为三个子目标：

6.1 可操作性（Operability）

让运维更容易，例如：

• 可观察性（logs / metrics / tracing）
• 自动化部署
• 能安全地滚动升级
• 错误处理可预测

6.2 简单性（Simplicity）

减少偶然复杂性，让系统更容易理解。

这里强调了本质复杂性 vs 偶然复杂性：

• 本质复杂性：问题本身就难（例如大规模社交图结构）
• 偶然复杂性：工具、框架、实现方式带来的额外麻烦（可避免）

减少偶然复杂性 → 提高可维护性。

6.3 可演化性（Evolvability）

系统随着需求变化能轻松修改，比如：

• 数据库迁移可回滚
• 模块松耦合
• 架构能支持未预料的用例

本质是：
系统越易改 → 越能在多年后保持生命力。

7. 四大非功能性需求之间的关系总结

下面是最关键的关系图（大白话版）：

性能（快）  
   ↑          ↘  
   |            可伸缩性（负载变大仍保持快）
   |          
可靠性（不挂） ↗    
   |
可维护性（能改、能运维）

换成一句话：

性能决定体验，可靠性保证不会挂，可伸缩性保证变大也不挂，可维护性保证未来还能变好。

它们互相补充，是现代数据密集型系统的共同目标。

8. 本章的核心 takeaway（精华）

• 性能：用响应时间百分位数衡量真实体验
• 可靠性：关键是容错，让故障不变成系统失效
• 可伸缩性：描述负载、发现瓶颈、用横向扩展解决
• 可维护性：减少复杂度、提升可操作性、保证系统可演化

理解这些概念，是后续章节（复制、分片、事务、一致性、流处理等）的基础。