M8-059M8: ML Systems, Engineering & ResearchReliability & Graceful DegradationMedium
Mastery:
Reliability & Graceful Degradation: 解释容量规划与压测的方法。
📐 Mathematical Definition
⚡ 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.