容量规划
在构建前为预期峰值负载配好每个组件并留余量。
为什么
在 100 用户能用、1000 用户就垮的系统是没做容量规划的系统。容量规划是取预期峰值负载（请求/秒、GB 存、并发用户）并给每个组件配 2-3 倍余量，使首个流量尖峰不变成事故。它还在能重设计时暴露不可扩展组件（单实例 DB、单区域 API）。跳过意味着你在生产、凌晨 3 点、上线时发现极限。
何时使用
系统设计时、配资源前。半天。任何预期 >2 倍流量事件（上线、营销推）前重跑。
如何做
1. 定义峰值负载：RPS、并发用户、GB 存、GB 传 - 预测峰值乘 2-3 倍留余量 2. 每组件算其极限： - API：每实例 RPS × 实例数；查 CPU/连接限制 - DB：连接、IOPS、存储；查最大查询/秒 - 缓存：所需命中率、工作集内存 - 队列：消息/秒、留存、消费者吞吐 3. 找瓶颈（余量最低组件）——那是先破的地方 4. 扩瓶颈或重设计移除它（如 DB 前加缓存） 5. 记规划+假设；实际负载偏离 > 30% 时重访
示例
峰值预测：5000 RPS，20 万并发，2TB 存，10TB/月出口 组件极限（3 倍余量 = 1.5 万 RPS 目标）： API： 1500 RPS/实例 → 需 10 实例（现有 4）← 瓶颈 DB： 3000 连接，1.2 万 IOPS → 查询行，1.5 万 RPS 时连接紧 缓存：20GB 工作集，95% 命中 → Redis r6g.large（25GB）行 队列：8k 消息/秒，7 天留存 → Kafka 3 broker 行 行动：API 扩到 12 实例（2 备），加 DB 连接池（pgbouncer）。 瓶颈现：1.8 万 RPS 时 DB IOPS——可接 受，监控。
常见问题
- ⚠按平均负载规划而非峰值——系统扛得住周二下午却死于上线尖峰；永远按峰值 × 余量规划。
最佳实践
- ✓上线前按规划峰值压测——假设 30% 是错的，只有测试揭示。
- ✓把容量规划放 ADR 让假设（每实例 RPS、命中率）在证错时可审计。