M8-059M8: ML Systems, Engineering & ResearchReliability & Graceful DegradationMedium
Mastery:

Reliability & Graceful Degradation: 解释容量规划与压测的方法。

📐 Mathematical Definition
capacity=peak QPS⋅rreq⋅(1+m)rnode,headroom=1−peakprovisioned\text{capacity}=\frac{\text{peak QPS}\cdot r_{\text{req}}\cdot(1+m)}{r_{\text{node}}},\qquad \text{headroom}=1-\frac{\text{peak}}{\text{provisioned}}
⚡ Executive Summary
Core Concept: 由峰值 QPS × 单请求资源 × 冗余系数估算容量,用负载/压力/浸泡测试验证,并保留 headroom 应对突发与故障切换。

📌 Key Takeaways

  • •
    需求估算——峰值 QPS(含促销/突发)、每请求资源(CPU/GPU/显存/带宽)
  • •
    冗余系数——为突发、故障切换(N+1)、滚动发布留余量(常见 20%-50%)
  • •
    压测类型——负载测试(预期峰值)、压力测试(找拐点)、浸泡测试(长时间稳定性)、尖峰测试
  • •
    拐点与排队——吞吐随并发上升到拐点后延迟剧增,容量应设在拐点前
  • •
    成本-可靠性权衡——headroom 越大越可靠但越贵,需按 SLO 与故障模型定量

📐 Mathematical Derivations

数学机理:<strong>容量规划</strong>——(1) <strong>需求侧</strong>——(a) <strong>峰值 QPS</strong>——含日常峰、促销峰、突发(用历史分位数 + 业务预测);(b) <strong>每请求资源 r_req</strong>——CPU/GPU 时间、显存、内存、带宽;(c) <strong>请求分布</strong>——不同接口/模型资源差异大,需分类。(2) <strong>供给侧</strong>——(a) <strong>单节点容量 r_node</strong>——由压测测定(给定 SLO 下的最大 QPS);(b) <strong>节点数</strong>——capacity = peak·r_req·(1+m) / r_node。(3) <strong>冗余系数 m</strong>——(a) <strong>突发余量</strong>——应对超预期流量;(b) <strong>故障切换</strong>——N+1(一个节点挂了其余承担);多可用区(一个 AZ 挂了另一 AZ 承担);(c) <strong>滚动发布</strong>——发布期间部分节点不可用;(d) <strong>常见取值</strong>——20%-50%,关键系统更高。(4) <strong>排队论视角</strong>——(a) <strong>利用率与延迟</strong>——排队延迟随利用率非线性上升(接近 1 时爆炸);(b) <strong>利特尔法则(Little's Law)</strong>——L = λW(在制请求数 = 到达率 × 停留时间);(c) <strong>结论</strong>——容量不应按 100% 利用率设计,而应留 headroom(如 70% 目标利用率)。(5) <strong>压测类型</strong>——(a) <strong>负载测试</strong>——在预期峰值下验证 SLO;(b) <strong>压力测试</strong>——逐步加压找<strong>拐点</strong>(吞吐不再上升、延迟剧增);(c) <strong>浸泡测试(soak)</strong>——长时间运行检测内存泄漏、连接泄漏、缓存增长;(d) <strong>尖峰测试(spike)</strong>——瞬时高压测试弹性与限流;(e) <strong>故障注入</strong>——杀掉节点验证降级与切换。(6) <strong>拐点(knee)</strong>——(a) 吞吐随并发上升到某点后饱和,继续加压延迟剧增;(b) <strong>容量设在拐点前</strong>(如拐点的 70%);(c) 拐点由资源瓶颈(CPU/GPU/带宽/连接池)决定。(7) <strong>瓶颈定位</strong>——(a) 用资源利用率找瓶颈(哪个资源先到 100%);(b) 常见瓶颈——GPU 显存/算力、CPU、连接池、DB、网络带宽。(8) <strong>成本权衡</strong>——(a) headroom 越大越可靠但越贵(固定成本);(b) <strong>定量</strong>——按 SLO 与故障模型(允许的不可用时间)算所需冗余;(c) <strong>弹性伸缩</strong>——云上用自动扩缩容按需调整(但冷启动有延迟,需预热/预留)。(9) <strong>持续</strong>——(a) 流量增长与代码变更需重新评估容量;(b) 定期压测(而非一次性)。<strong>与其他问题的关系</strong>——(a) 与限流熔断(保护容量);(b) 与延迟分解(拐点由瓶颈决定);(c) 与成本优化(headroom 即成本);(d) 与可靠性(冗余)。<strong>度量</strong>——(a) 峰值利用率与 headroom;(b) 拐点位置;(c) SLO 达标率;(d) 单位容量成本。

🏭 Production Trade-offs

深度剖析与工程权衡:① <strong>容量应设在拐点前</strong>——面试中能解释'吞吐拐点'是深度理解的标志。② <strong>排队延迟随利用率非线性上升</strong>——不能按 100% 利用率设计。③ <strong>冗余需覆盖故障切换</strong>——N+1 与多 AZ 都消耗容量。④ <strong>浸泡测试查泄漏</strong>——短时压测查不出内存/连接泄漏。⑤ <strong>headroom 是成本与可靠性的权衡</strong>——需定量而非拍脑袋。⑥ <strong>弹性伸缩有冷启动</strong>——需预热或预留容量。⑦ <strong>面试要点</strong>——被问怎么定容量,应给出'<strong>需求(峰值 QPS × 每请求资源)+ 冗余(突发/N+1/多 AZ/发布)+ 压测(负载/压力/浸泡/尖峰)找拐点 + headroom 定量 + 弹性与预热</strong>';能指出拐点与排队非线性是深度理解的标志。
⚠️ Common Interview Pitfalls
  • ✕
    按 100% 利用率设计容量(无 headroom)
  • ✕
    只做短时压测(漏掉内存/连接泄漏)
🎯 Interviewer Follow-ups
  • ?
    为什么容量要设在吞吐拐点之前?
  • ?
    N+1 冗余与多可用区如何影响容量估算?
📚

Associated Knowledge Base Guides & Mindmaps

Explore the comprehensive technical article, exam cards, and global architecture tree.

← PreviousM8-058: Reliability & Graceful Degradation: 解释超时与重试的设计要点。📋Back to BankNext →M8-060: Reliability & Graceful Degradation: 解释事故复盘的要点与产出。