容量冗余怎么留
容量冗余是让系统在部分单元失效时仍能承接全量负载：常见说法是 N+1（任一单元故障，其余单元承接全部流量）和 N+2 或多活（容忍更多同时失效，或跨地域接管）。预留的关键有两个常被忽略的前提：冗余单元必须位于独立的故障域，否则会同时失效；以及预留要经过验证——演练摘除单元，确认剩余容量真的能承接，而不是只停留在表格里。
基本信息
| N+1 | 任一单元故障，其余单元承接全量 |
|---|---|
| N+2 或多活 | 更高级别冗余，成本相应上升 |
| 验证 | 演练切换或摘除单元，观察指标是否达标 |
| 前提 | 冗余单元在独立故障域，且不共享同一关键依赖 |
典型使用场景
- 多可用区部署：单个可用区故障时其余可用区承接流量
- 数据库主从与故障切换：主库故障后从库提升并承接写入
- 大促前容量准备：按峰值预测预留额外实例并保持到活动结束
- 滚动发布期间的容量规划：每次摘除的实例量要小于冗余余量
- 跨区域容灾：区域级故障时由备份区域接管服务
冗余级别对照
| 级别 | 含义 | 成本 | 典型场景 |
|---|---|---|---|
| N | 无额外冗余 | 低 | 可中断的批处理任务 |
| N+1 | 单单元故障可承接全量 | 中 | 常规在线服务 |
| N+2 或多活 | 多故障域或更高可用目标 | 高 | 核心交易与合规场景 |
冗余验证要点
冗余验证要点
1. 选择低峰窗口，摘除一个单元或切换一个可用区
2. 观察剩余单元的水位：CPU、内存、连接数与队列等待
3. 对比摘除前后的 P99 与错误率，确认仍在目标内
4. 检查共享依赖：数据库、缓存、消息与外部配额是否成为新瓶颈
5. 记录演练结果与余量，作为下次容量规划的输入
# 只算服务器台数不够，共享依赖常常是最薄弱的一环使用要点
- 冗余单元放在独立故障域：供电、网络与可用区分开
- 演练摘除单元或切换流量，验证其余单元承接后的指标
- 定期核对预留容量与实际负载，防止水位上涨侵蚀冗余
- 把共享依赖纳入余量核算：数据库、缓存与第三方配额往往先于计算资源耗尽
- 预留要持续到峰值结束：活动期间临时释放冗余会带来不可控风险
冗余单元若与主单元共享依赖（同一数据库、同一网络出口），故障时会同时失效，因此冗余设计要从依赖拓扑上审查，而不只数机器台数。
从未演练的冗余等于假设：水位上涨、配置漂移与新依赖都可能让预留失效，定期用摘除或切换演练验证才是可靠做法。