🧭 系统设计方法论¶

┌─────────────────────────────────────────────────────────────┐
│                    系统设计面试4步法                          │
├─────────────┬──────────────┬───────────────┬───────────────┤
│  Step 1     │  Step 2      │  Step 3       │  Step 4       │
│  需求澄清   │  高层设计     │  详细设计      │  扩展优化     │
│  5-10 min   │  10-15 min   │  15-20 min    │  5-10 min     │
├─────────────┼──────────────┼───────────────┼───────────────┤
│ • 功能需求   │ • API设计    │ • 数据模型     │ • 扩展性     │
│ • 非功能需求 │ • 架构图     │ • 核心算法     │ • 监控告警    │
│ • 容量估算   │ • 数据流     │ • 存储方案     │ • 故障处理    │
│ • 边界确认   │ • 技术选型   │ • 缓存策略     │ • 成本优化    │
└─────────────┴──────────────┴───────────────┴───────────────┘

功能范围：
  - 系统需要支持哪些核心功能？
  - 用户的使用场景是什么？
  - 有哪些功能是不在范围内的？

用户规模：
  - DAU（日活用户）是多少？
  - 读写比例大概是多少？
  - 数据量级是怎样的？

非功能需求：
  - 对延迟的要求是什么（毫秒级？秒级？）
  - 可用性要求是多少（99.9%？99.99%？）
  - 数据一致性要求（强一致？最终一致？）

技术约束：
  - 有技术栈偏好吗？
  - 是否有成本约束？
  - 是建设新系统还是改造旧系统？

你：这个Twitter系统需要支持哪些核心功能？
面试官：发推、关注/取关、时间线展示

你：用户量级大概是多少？
面试官：DAU 3亿，月活5亿

你：读写比例大概是什么样的？
面试官：读远多于写，大概100:1

你：推文可以包含什么内容？
面试官：文本（140字）和图片

你：时间线有什么特殊要求吗？
面试官：按时间倒序排列，需要实时性

你：可用性方面有什么要求？
面试官：99.99%可用

POST /api/v1/tweet
  - Request: { user_id, content, media_urls }
  - Response: { tweet_id, created_at }

GET /api/v1/timeline?user_id=xxx&page=1&size=20
  - Response: { tweets: [...], next_cursor }

POST /api/v1/follow
  - Request: { follower_id, followee_id }
  - Response: { success }

                        ┌──────────┐
                        │  Client  │
                        └────┬─────┘
                             │
                        ┌────▼─────┐
                        │   CDN    │ ← 静态资源
                        └────┬─────┘
                             │
                        ┌────▼─────┐
                        │    LB    │ ← 负载均衡
                        └────┬─────┘
                             │
              ┌──────────────┼──────────────┐
              │              │              │
        ┌─────▼────┐  ┌─────▼────┐  ┌─────▼────┐
        │ 发推服务  │  │ 时间线   │  │ 关注服务  │
        │          │  │ 服务     │  │          │
        └─────┬────┘  └─────┬────┘  └─────┬────┘
              │              │              │
        ┌─────▼────────────▼────────────▼─────┐
        │            消息队列                   │
        └─────────────┬───────────────────────┘
                      │
         ┌────────────┼────────────┐
         │            │            │
   ┌─────▼────┐ ┌────▼─────┐ ┌───▼──────┐
   │   MySQL  │ │  Redis   │ │ 对象存储  │
   │  (推文)  │ │ (时间线) │ │  (媒体)  │
   └──────────┘ └──────────┘ └──────────┘

需求分类
├── 功能性需求（Functional Requirements）
│   ├── 系统"做什么"
│   ├── 用户可见的功能
│   └── 例：发帖、搜索、支付
│
└── 非功能性需求（Non-Functional Requirements）
    ├── 系统"做得多好"
    ├── 质量属性
    └── 例：性能、可用性、安全性

P0（必须满足）：核心功能 + 数据一致性/持久性
P1（应该满足）：性能要求 + 可用性
P2（可以later）：可扩展性 + 高级功能
P3（锦上添花）：监控、分析、A/B测试

已知条件：
  DAU = 3亿
  每人每天平均看20条推文
  每人每天平均发0.5条推文
  读写比 = 40:1

读QPS：
  = 3亿 × 20 / 86,400
  = 6,000,000,000 / 86,400
  ≈ 70,000 QPS

峰值读QPS：
  = 70,000 × 3（峰值因子）
  ≈ 210,000 QPS

写QPS：
  = 3亿 × 0.5 / 86,400
  ≈ 1,750 QPS

峰值写QPS：
  = 1,750 × 3
  ≈ 5,250 QPS

推文存储：
  每日新增推文 = 3亿 × 0.5 = 1.5亿条
  每条推文大小 ≈ 400 bytes（含元数据）

  每日新增 = 1.5亿 × 400B = 60GB/天
  每年 = 60GB × 365 = 21.9TB/年

媒体存储（假设10%的推文含图片）：
  每日含图推文 = 1500万条
  每张图片 ≈ 500KB

  每日新增 = 1500万 × 500KB = 7.5TB/天
  每年 = 7.5TB × 365 = 2.7PB/年

总存储（3年，含3份副本）：
  推文：21.9TB × 3年 × 3副本 ≈ 200TB
  媒体：2.7PB × 3年 × 3副本 ≈ 24PB

出站带宽（读推文）：
  = 70,000 QPS × 400B
  = 28MB/s
  ≈ 224Mbps

出站带宽（读图片，假设30%请求带图）：
  = 70,000 × 30% × 500KB
  = 10.5GB/s
  ≈ 84Gbps

  → 这个量级通常意味着图片/媒体流量需要通过对象存储 + CDN 分发，而不应直接由应用层回源承接。

┌─────────────────────────────────────────────┐
│              容量估算模板                      │
├─────────────────────────────────────────────┤
│ 1. 用户规模                                  │
│    DAU: _______ 万                           │
│    MAU: _______ 万                           │
│    同时在线: _______ 万                       │
│                                              │
│ 2. 读写量                                    │
│    读QPS: _______ / 峰值: _______            │
│    写QPS: _______ / 峰值: _______            │
│    读写比: _______:1                          │
│                                              │
│ 3. 存储                                      │
│    单条数据大小: _______ bytes                │
│    每日新增: _______ GB                       │
│    保存期限: _______ 年                       │
│    总存储(含副本): _______ TB                 │
│                                              │
│ 4. 带宽                                      │
│    入站: _______ Mbps                        │
│    出站: _______ Gbps                        │
│                                              │
│ 5. 结论                                      │
│    需要 _______ 台应用服务器                  │
│    需要 _______ 台数据库服务器                │
│    是否需要CDN: □是 □否                       │
│    是否需要缓存: □是 □否                      │
│    是否需要消息队列: □是 □否                  │
└─────────────────────────────────────────────┘

            C (Consistency)
           一致性
            ╱ ╲
           ╱   ╲
          ╱     ╲
         ╱  只能  ╲
        ╱  选择两个 ╲
       ╱             ╲
      A ─────────────── P
 (Availability)    (Partition
   可用性          Tolerance)
                   分区容错性

网络分区发生时：

CP系统的选择：                  AP系统的选择：
┌─────────────┐                ┌─────────────┐
│  保证一致性   │                │  保证可用性   │
│  放弃可用性   │                │  放弃一致性   │
│             │                │             │
│ 返回错误或    │                │ 返回可能过时  │
│ 等待恢复     │                │ 的数据       │
└─────────────┘                └─────────────┘

场景：A向B转账100元

CP选择（正确）：
  网络分区时 → 拒绝交易 → 宁可服务不可用，也不能出现A扣了钱B没收到

AP选择（危险）：
  网络分区时 → 继续交易 → 可能导致A的钱扣了但B没收到，数据不一致

场景：用户发了一条朋友圈

AP选择（合理）：
  网络分区时 → 北京用户先看到，上海用户1秒后看到
  结果：最终一致，用户体验可接受

CP选择（不必要）：
  网络分区时 → 所有人都看不到 → 过度设计

PACELC = if Partition → AC else → LC

解读：
  如果发生分区(P)  → 需要在 可用性(A) 和 一致性(C) 之间选择
  否则(Else)       → 需要在 延迟(L) 和 一致性(C) 之间选择

ACID（传统关系数据库）           BASE（分布式系统）
┌─────────────────┐            ┌─────────────────┐
│ Atomicity  原子性 │            │ Basically        │
│ Consistency 一致性│            │ Available 基本可用│
│ Isolation  隔离性 │            │ Soft State 软状态│
│ Durability 持久性 │            │ Eventually       │
│                  │            │ Consistent最终一致│
├─────────────────┤            ├─────────────────┤
│ 强一致性          │            │ 弱一致性         │
│ 优先保证正确性     │            │ 优先保证可用性    │
│ 适合小规模、      │            │ 适合大规模、      │
│ 对一致性要求高     │            │ 对可用性要求高    │
└─────────────────┘            └─────────────────┘

写入                  最终一致
  │                     │
  ▼                     ▼
  ┌──────────────────────┐
  │    不一致时间窗口      │
  │                      │
  │  节点A: new_value    │
  │  节点B: old_value    │
  │  节点C: old_value    │
  │         ↓            │
  │  节点A: new_value    │
  │  节点B: new_value    │
  │  节点C: old_value    │
  │         ↓            │
  │  节点A: new_value    │
  │  节点B: new_value    │
  │  节点C: new_value    │ ← 达到一致
  └──────────────────────┘

  通常在毫秒~秒级内达到一致

垂直扩展 (Scale Up)              水平扩展 (Scale Out)
┌─────────────┐                ┌───┐ ┌───┐ ┌───┐
│             │                │   │ │   │ │   │
│             │                │   │ │   │ │   │
│  更强的机器  │                │   │ │   │ │   │
│             │                └───┘ └───┘ └───┘
│             │                ┌───┐ ┌───┐ ┌───┐
│             │                │   │ │   │ │   │
│             │                │   │ │   │ │   │
│             │                └───┘ └───┘ └───┘
└─────────────┘                更多的普通机器

当前系统是否到了瓶颈？
    │
    ├── 否 → 不需要扩展
    │
    └── 是 → 垂直扩展是否还有空间？
              │
              ├── 是 → 先垂直扩展（成本低、风险小）
              │        └── 但要同时预研水平扩展方案
              │
              └── 否 → 水平扩展
                       ├── 无状态服务 → 加机器 + LB
                       ├── 有状态服务 → 需要考虑分片/复制
                       └── 数据层 → 分库分表/读写分离

有状态服务（难扩展）          无状态服务（易扩展）
┌──────────────┐            ┌──────────────┐
│   Server A   │            │   Server A   │
│ session: {..}│            │   无状态      │──┐
└──────────────┘            └──────────────┘  │
     ❌ 用户只能              ┌──────────────┐  │  ┌────────┐
     访问同一台机器            │   Server B   │──┼──│ Redis  │
                             │   无状态      │  │  │Session │
                             └──────────────┘  │  └────────┘
                             ┌──────────────┐  │
                             │   Server C   │──┘
                             │   无状态      │
                             └──────────────┘
                             ✅ 任何机器都可处理

"在这里，我们有两个选择：A和B。

A的优势是___，劣势是___。
B的优势是___，劣势是___。

考虑到我们的场景（具体需求），我倾向于选择A，
因为___。

但如果未来需求变化（具体变化），我们可能需要迁移到B。"

2^10 = 1,024          ≈ 千 (K)
2^20 = 1,048,576      ≈ 百万 (M)
2^30 = 1,073,741,824  ≈ 十亿 (G)
2^40 = 1,099,511,627,776 ≈ 万亿 (T)