高可用为什么要预留冗余容量？
简化版
冗余容量用于在实例、可用区或依赖失效后承接转移流量，并吸收扩容延迟、重试和缓存冷启动；平时跑满的系统没有故障恢复空间。 容量应按目标故障模型做 N+1 或 N-1 校验，并同时检查应用、数据库、连接池、网络和第三方配额，而不是只留 CPU。
详细版
若两个机房各承载 50% 流量且当前利用率 70%，失去一个后另一边会升到约 140%，无法接管。要么平时将每边控制在 50% 以下，要么故障时降级非核心流量、快速扩容，并确保下游也有余量。
规划使用峰值而非平均值，并加入故障重试、发布下线、数据恢复和容量预测误差。冗余是否有效要靠“下线一个实例/AZ后仍满足 SLO”的压测和演练验证；自动扩容只能补充，不能替代启动前的即时冗余。
完整版教学
一、容量为什么是高可用前提
副本能接替角色，不代表有能力接替流量。健康状态下 90% CPU 的两节点集群，任一节点退出后另一节点面对近两倍请求，通常先排队、超时，再触发重试雪崩。冗余容量让故障切换具有物理可行性。
记忆钩子：高可用不只要“还有节点活着”，还要“活着的节点吃得下转来的工作”。
二、按故障模型计算而非统一留 30%
故障后利用率 = 总峰值负载 / 故障后可用容量
目标：故障后利用率 <= 安全水位10 个实例每个额定承载 200 QPS，总峰值 1400 QPS。失去 2 个后额定容量为 8×200=1600 QPS，故障后利用率 87.5%。若为了延迟与突发余量要求利用率不超过 70%，现有冗余仍不够；按该水位，8 个实例的安全承载量只有 1600×70%=1120 QPS。
三、N+1、N+2 与跨域冗余
| 模型 | 含义 | 适用风险 |
|---|---|---|
| N+1 | 多一个等效单元 | 单实例故障 |
| N+2 | 可失去两个单元 | 发布叠加故障 |
| 跨 AZ N-1 | 丢一 AZ 后仍达标 | 可用区故障 |
| 双地域接管 | 单地域承载核心流量 | 地域灾难 |
“单元”可以是实例、机架、AZ 或地域。只按实例 N+1 无法抵抗整 AZ 同时失效。
四、瓶颈链条必须全部留余量
应用 CPU 只有 40%，数据库连接池却已 85%，扩应用实例不会增加数据库容量。容量表要覆盖 CPU、内存、线程、连接、磁盘 IOPS、网络、MQ 分区和供应商配额，并找到故障后的最小瓶颈。
缓存冷启动也会改变链路：命中率从 95% 降到 70%，10000 QPS 下回源从 500 增至 3000 QPS，数据库可能先被压垮。因此故障容量测试要包含冷缓存。
五、扩容速度决定需要多少静态冗余
流量故障后立即转移，而云实例从申请、启动、拉镜像到预热可能要 8 分钟。前 8 分钟只能依赖已有容量和降级。扩容越慢、预测越不确定，静态冗余越多；秒级 serverless 也要验证并发配额和下游承载。
可将非核心功能作为“逻辑容量储备”：事故时关闭推荐和报表，释放 25% CPU 给交易。但这种储备必须通过演练证明，不能凭感觉估算。
六、监控和验证
监控正常/故障两种容量利用率、headroom、扩容耗时、限流量、下游配额和恢复任务占用。用预测峰值和当前健康单元数实时计算 N-1 是否满足，而不是只告警 CPU>80%。
演练下线最大实例或一个 AZ，同时注入缓存冷启动与重试，检查 P99、成功率和数据库水位。发布也会减少可用实例，因此滚动批次必须计入故障并发风险。
七、常见误区与追问
- 误区：平均 CPU 低就说明容量充足。 峰值、单节点偏斜和下游瓶颈可能完全不同。
- 误区：自动扩容可以替代预留容量。 启动和预热期间仍需要即时承载能力。
- 误区：每个机房各 50% 就是双活冗余。 若已高利用率，失去一边后无法接管。
- 误区：只给应用层做冗余。 数据库、网络和第三方配额会成为新瓶颈。
- 追问：冗余是否越多越好？ 受成本约束，应按业务损失、故障模型和扩容时间优化。
- 追问：如何利用降级降低冗余成本？ 预先量化可释放资源，并保证降级不破坏核心语义。
- 追问：怎样验证 N-1？ 实际移除目标故障域，在峰值和冷缓存条件下压测 SLO。
八、加强记忆
容量冗余按“故障模型—峰值负载—剩余单元—全链瓶颈—扩容时间”计算。N+1 只是起点，跨 AZ 要做 N-1，缓存冷启动和重试要进入压力模型。最终用真实摘除与压测证明剩余系统仍能守住 SLO。
容量报告应同时给出稳态利用率和接管利用率；只报平均 CPU 会掩盖线程池、连接池、磁盘 IOPS 等先于 CPU 饱和的瓶颈。
若依赖弹性扩容，还要把实例启动、镜像拉取、数据预热和负载均衡注册的总时长与业务可承受时间比较。