系统设计：从容量估算到一致性与可观测

0. 元信息

• 主题路径：docs/topics/system-design/README.md
• 主分类：工程技术
• 辅助分类：计算机基础
• 适合对象：会写后端服务、做过 REST API 设计与 SQL 调优，想从单机能写过渡到「能设计支撑百万级用户的可扩展系统」的工程师
• 建议周期：4～8 周（每周 8～12 小时，至少一半时间用于画图与白板推演）
• 前置知识：network、rest-api-design、algo-design、db-and-sql；熟悉至少一门后端语言、容器与 Linux 命令
• 最终目标：拿到一道经典系统设计题（短链 / Twitter timeline / 秒杀 / Feed 流），能在 45 分钟内画出组件图、写清数据流、定量估出容量、列出关键权衡与故障应对

1. 学习路线

容量估算（QPS / 带宽 / 存储 / 成本）
  → 架构分层（DNS / GSLB / 网关 / 业务层 / 缓存 / DB / MQ / 可观测）
  → 缓存体系（CDN / 反向代理 / 进程内 / 分布式 / Cache-Aside / Read-Through / Write-Behind / Bypass）
  → 数据与一致性（关系 / 文档 / 列存 / 时序 / 向量 / 对象存储 / CPA / PACELC）
  → 分布式事务与消息（2PC / Saga / Outbox / CDC / Kafka / RabbitMQ / 死信 / 事件溯源）
  → 限流降级熔断（令牌桶 / 漏桶 / 滑动窗口 / Resilience4j / Bulkhead）
  → 可观测与 SRE（Metrics / Logs / Traces / SLI / SLO / 错误预算 / 混沌工程）
  → 综合项目：百万 QPS 短链 / Feed 流 / 秒杀 / 单体微服务拆分

按真实请求经过的路径学。每张子主题对应一段链路，最后用综合项目把链路串起来。

2. 阶段周数分配

4 周方案只跑通最小可用路径；8 周方案有 2 周用来重做实验与白板。综合项目占最后 1 周。

3. 九阶段表

关键陷阱：把”看过视频/书”当学会；只画组件图不写数据流；不写容量估算就讲可扩展；选缓存策略不解释失效链；把所有一致性问题都套 Saga；只看平均延迟不设 SLO。

4. 第一周任务

Day 1 约定：本计划以 Linux + Docker + 一台 8G 内存的机器为最小实验环境。所有容量估算以「DAU、读写比、对象大小」三参数为输入。所有方案都要画出组件图 + 数据流图 + 容量估算表三件套。

Day 7 步骤 A 跑通业务流；步骤 B 每类故障先在测试环境复现，再讲清防护手段。

5. 阶段通用验收

1. 不看答案独立重写 5 种缓存模式、3 种限流算法、Saga 编排、Outbox 投递；
2. 用自己的话解释每个组件”解决什么问题、为什么有效、什么时候失效”；
3. 画一张图：组件图 + 数据流图 + 状态机图（至少三件套之一）；
4. 测试空数据、流量峰值 10×、节点下线 1/3、依赖超时 5s 四类边界；
5. 准备至少 3 组自定义容量估算并贴出实际推导；
6. 记录 P50 / P95 / P99 延迟、QPS、错误率、饱和度 4 个核心指标；
7. 能修改已有设计（加一层缓存、换一个存储、引入异步）并用同样指标验证。

6. 最终验收

• 独立画出短链 / Twitter timeline / 秒杀 / Feed 流 4 套系统设计组件图 + 容量估算表 + 一致性选型；

• 至少完成 30 个设计题（neetcode system design 100 + Hello Interview + Grokking），分布建议：

  子主题	题目数量	难度	平台建议
  容量估算与分层	6	Easy / Medium	neetcode / Hello Interview
  缓存与数据层	6	Medium	Grokking System Design
  一致性与消息	6	Medium	Designing Data-Intensive 案例
  限流降级熔断与可观测	6	Medium	SRE Book 案例
  综合	6	Hard	YouTube「System Design Interview」

  约束：至少 18 道达到 Medium，至少 6 道达到 Hard；每道题必须留 45 分钟白板视频或录音。

• 完成 1 个综合项目：百万 QPS 短链 / 朋友圈 Feed / 秒杀系统，含设计文档 + 压测报告 + 故障演练；

• 能用 15 分钟讲清整套系统的组件图、数据流、容量估算、一致性选型、限流策略与 SLO 指标。

7. 综合项目

首选：百万 QPS 短链系统（必做：组件图 + 容量估算 + 5 段缓存 + 限流 + 可观测）。

• 输入：用户提交长 URL，生成 7~8 字符短链，跳转短链返回 302/301；
• 输出：必输出（1）组件图：DNS → GSLB → CDN → 网关 → 短链生成服务 → Redis → MySQL / 列存；（2）容量估算表：DAU=10M、QPS=10k peak=100k、存储 30T、Redis 内存 200G；（3）5 种缓存模式 + 3 种限流算法 + Saga/Outbox 落库；
• 关键指标：P99 跳转延迟 < 50ms、写 QPS 5k、读 QPS 50k、Redis 命中率 > 95%；
• 进阶可选：接入 OpenTelemetry、配置 SLO 99.9%、用 k6 或 wrk2 压出 100k QPS。

备选：朋友圈 Feed 流（推拉结合 + 热点 + 限流）。
备选：秒杀系统（库存预热 + Redis 原子扣减 + 异步下单 + 防超卖）。
备选：对一套遗留单体做微服务拆分并验证一致性与降级方案。

任何综合项目都必须包含：

1. 需求与成功标准（延迟 / QPS / 可用性 / 一致性）；
2. 容量估算（DAU / 读写比 / 峰值倍数 / 存储 / 带宽 / 成本）；
3. 组件图 + 数据流图 + 状态机图；
4. 关键代码（5 种缓存 + 3 种限流 + Saga/Outbox + Resilience4j + OpenTelemetry）；
5. 边界测试（雪崩 / 击穿 / 穿透 / 节点下线 / 依赖超时）；
6. 压测脚本与报告（wrk / k6 / vegeta）；
7. README（设计取舍、已知限制、下一步）；
8. 故障复盘（模拟 1 次 P0，写 retrospective.md）。

8. 推荐开源资料

默认使用顺序：先读 DDIA 14 章建立概念 → 读 SRE Book 第 13 章建立 SLO 思维 → 用 neetcode 100 题练白板 → 选综合项目落地 → 用 Hello Interview 视频查漏 → 写复盘到 notes/retrospective.md。

9. 学习资料汇聚（v0.3 自包含）

本节由本计划生成。链接指向原始材料或作者公开内容。规范会演进，记录时务必写明版本与日期。

9.1 背景与动机

分布式系统从单机能解决到多机协作，不是简单加机器。1990 年代后期互联网爆发，Eric Brewer 在 PODC 2000 提出 CAP 猜想，两年后由 Gilbert、Lynch 证明，定理 12 年后 Brewer 自己写了「CAP Twelve Years Later」纠正误读并提出 PACELC。Amazon 2007 年披露 Dynamo 论文，把最终一致性、向量时钟、Quorum、可调一致性写进工业实践。Google 2003~2012 年陆续发布 GFS、Bigtable、MapReduce、Spanner、Chubby，把共识、复制、事务的边界从论文推到工程。Martin Kleppmann 2017 年把这一切写成 Designing Data-Intensive Applications，今天它几乎是系统设计学习的标配。

今天每一个百万级系统都把”估算 → 缓存 → 一致性 → 异步 → 限流 → 观测”六个字拆成具体组件。一句话总结：系统设计不是画一张漂亮的组件图，是把 QPS、存储、延迟、可用性、故障这五个变量约束到具体技术选型上。

9.2 概念地图

flowchart LR
  Estimate[容量估算 QPS/带宽/存储/成本] --> Layers[架构分层]
  Layers --> LB[L4/L7/GSLB]
  Layers --> Gateway[API 网关]
  Layers --> App[无状态业务]
  App --> Cache[缓存体系]
  Cache --> CDN[CDN/反向代理]
  Cache --> Local[进程内]
  Cache --> Distributed[分布式 Redis/Memcached]
  App --> Data[数据层]
  Data --> SQL[关系/分库分表]
  Data --> NoSQL[文档/列存/时序/向量/对象]
  App --> MQ[消息与异步]
  MQ --> Kafka[Kafka/RabbitMQ]
  App --> Pattern[事务模式]
  Pattern --> Saga[Saga/Outbox/CDC]
  Pattern --> CAP[CPA/PACELC]
  App --> RateLimit[限流降级熔断]
  RateLimit --> Bulkhead[隔离舱/熔断/重试]
  App --> Observability[可观测]
  Observability --> SLI[SLI/SLO/错误预算]
  Observability --> Chaos[混沌工程]

关系说明：容量估算决定每一层的容量目标；缓存与数据层受一致性模型约束；消息与事务解决跨服务一致；限流与熔断是边界保护；可观测提供反馈环。每一层都对应一个失败模式，必须在设计里写明应对。

9.3 基础知识讲解

9.3.1 经典论文 / 规范

9.3.2 经典书籍

9.3.3 优秀博客

9.3.4 核心人物

9.3.5 开发方法

9.3.6 重点训练材料

• DDIA 配套案例：第 5~9 章每章末尾的”案例研究”是顶级题源（Twitter timeline 用 Cassandra、LinkedIn 用 Espresso、Facebook 用 MySQL + Memcached）。
• neetcode system design 100：按难度分层的题库，覆盖短链、URL 限流、Twitter、Uber、DropBox 等经典题。
• Grokking System Design（Educative）：题库配合图解，适合白板练习。
• Hello Interview：视频 + 思维框架，按 15 步白板法练习。
• SRE Book 案例：第 8~11 章真实故障复盘，每篇都是 SLI/SLO 的实战教学。

9.4 经典问题与经典案例

9.5 学习难点

概念难点

思维难点

工程难点

9.6 技术标准与接口

9.6.1 Entity

9.6.2 Scope

• CAP / PACELC：分布式系统的理论边界，不直接指导实现。
• Saga / Outbox / CDC：跨服务事务模式，不替代单库事务。
• W3C Trace Context / OpenTelemetry：跨进程追踪协议，不替代应用日志。
• SLI / SLO：错误预算的具体载体，不替代告警规则。
• Resilience4j：JVM 上的稳定性库，不替代网关层限流。

9.6.3 Structure

• 容量估算公式：QPS = DAU × 每用户操作数 / 时间窗口；存储 = 留存期 × QPS × 对象大小 × 副本系数。
• 写策略：Cache-Aside（应用层管）、Read-Through（缓存层管）、Write-Behind（异步写回）、Write-Through（同步写穿）、Bypass（直写）。
• Saga：编排（Orchestration）由中央协调器调用；编舞（Choreography）由事件驱动。
• 错误预算：Budget = (1 - SLO) × 时间窗口。
• 必会接口：Redis INCR / Lua、Kafka Producer / Consumer / Consumer Group、Sentinel / Hystrix 风格的熔断配置、OpenTelemetry SDK / OTLP。

9.6.4 Ecosystem

• 缓存：Redis、Memcached、CDN（Nginx / Cloudflare / Akamai）、Hazelcast、Caffeine。
• 数据库：MySQL、PostgreSQL、TiDB、CockroachDB、MongoDB、Cassandra / ScyllaDB、ClickHouse、InfluxDB、Milvus、Weaviate、MinIO。
• 消息：Kafka、RabbitMQ、Pulsar、NATS、Redis Streams。
• 网关与限流：Kong、Envoy、APISIX、AWS API Gateway、Sentinel、Resilience4j。
• 可观测：Prometheus、Grafana、OpenTelemetry、Jaeger、Tempo、Elastic、Loki、Datadog。
• 混沌：ChaosBlade、Litmus、Gremlin、Chaos Mesh。

9.6.5 Depth Tiers

本计划目标：L3。综合项目可触及局部 L4，但不作为 4~8 周的硬门槛。

9.6.6 Source

• Martin Kleppmann 主页 与 DDIA：数据系统原理。
• Werner Vogels 博客：Amazon Dynamo 思想。
• Jeff Dean 2009 LADIS 演讲：大规模系统设计哲学。
• Google SRE Book 全文：SLI / SLO / 错误预算。
• AWS Well-Architected：五大支柱。
• High Scalability：经典案例。
• 引用版本快照日期：2026-07-30。规范与论文版本相对稳定；库版本以 2026 年 7 月为准。

10. 常见误区

• 把”画组件图”当系统设计；不写容量估算、不写数据流、不写失败应对；
• 把 CAP 当”三选二”，忽略网络分区是常态；
• 所有跨服务事务都上 2PC，忽略 Saga 更适合业务；
• 写策略只用 Cache-Aside，忽略 Read-Through / Write-Behind / Bypass；
• 限流只在网关做，忽略进程内 Bulkhead；
• 缓存失效用”加随机 TTL”一句话带过，不做雪崩演练；
• 限流后不返回 Retry-After，客户端瞎重试；
• 消息总线只关心发送，不做幂等、不做死信、不做重放；
• 把平均延迟当 SLO，忽略 P99 / P999；
• 没有错误预算，告警阈值随手设；
• 混沌工程只在测试环境做，忽略预发与生产低风险实验；
• traceid 不进日志，跨服务排障靠猜；
• 用 SLO 当 KPI，导致团队不敢发版；
• 综合项目只画图不写代码；
• 学完不复盘，下次面试依然答不上来。

11. 所有知识点分类（统一规则）

1. 编程语言
2. 数据结构与算法
3. 计算机基础
4. 工程技术
5. Web 与后端
6. 前端与客户端
7. 数据与人工智能
8. 项目与职业能力
9. 安全与可靠性

本计划归属：工程技术 主 + 计算机基础 辅。