多活机房按100%全量峰值负载规划容量，灾备服务器依冷/热/温备定位设定冗余标准；电力、网络等基础设施冗余须与上层架构对齐；所有容量方案必须通过压测、灾备演练和容量漂移监测三类验证闭环。
容量规划中，多活机房与灾备服务器的冗余容量标准不是靠经验拍板，而是由业务连续性目标（RTO/RPO）、流量分布模型、故障切换能力三者共同决定的。核心逻辑是：冗余不是“多配几台”，而是“确保任何单点失效后，剩余资源仍能承载全量业务且不降级”。
多活机房的容量冗余标准：按“100% 全量承接”设计，而非按日常流量配比
同城多活或异地多活场景下，每个“活”的机房都必须具备独立运行全业务的能力。哪怕日常只分担30%流量，其计算、存储、网络、电力容量都要按100%峰值负载来规划。
- 例如某系统常态峰值QPS为12万，部署在A、B两个同城机房，A承担70%、B承担30%，B机房仍需按12万QPS的处理能力配置服务器、数据库连接池、缓存容量和带宽；
- 电力方面须满足2N架构：双路市电+UPS+柴发，任一路径中断不影响B机房满载运行；
- 数据库需支持双向同步或单元化分片，避免主从依赖导致B机房无法独立写入。
灾备服务器（冷备/热备）的冗余标准：区分场景，明确是否“可接管”
灾备不等于闲置。标准取决于其定位——是仅用于数据恢复（冷备），还是可快速升为生产（热备/温备）。
- 冷备服务器：无需实时承载流量，但需定期验证镜像可用性；容量只需满足“最小可运行集”（如核心数据库+关键应用），不要求支撑全量并发，但备份窗口内RPO必须≤5分钟；
- 热备服务器：必须与生产环境配置一致（同型号、同规格、同版本），并保持服务常驻、缓存预热、连接池活跃；容量冗余度为1:1，即1台故障，1台立即顶上，无性能衰减；
- 温备服务器：介于两者之间，服务已部署但未完全预热，允许30–120秒启动延迟；容量可按1.2倍日常峰值预留，重点保障数据库和中间件的快速拉起能力。
电力与基础设施层面的冗余匹配不能滞后
服务器容量再冗余，若供电或制冷跟不上，一切归零。多活与灾备的物理层冗余必须对齐上层架构要求：
- 多活机房必须采用2N供配电架构（非N+1），即每路设备都有独立输入、独立UPS、独立柴发，任意单路全链路故障不影响另一路满载运行；
- 灾备机房若定位为热备，其PUE、冷却冗余率、电池续航时间（建议≥15分钟）须与主机房一致；
- 跨机房网络带宽冗余不低于30%，尤其针对数据同步流量，要单独评估DB双向复制、日志传输等带宽占用，避免因网络拥塞拖慢RPO。
验证机制比容量数字更重要
再精确的容量公式，不验证就是纸面指标。必须通过三类实操验证闭环：
- 压测验证：模拟单机房故障，将100%流量切至另一机房，持续压测≥30分钟，观察CPU、内存、延迟、错误率是否越界；
- 灾备演练验证：每季度执行一次真实灾备切换，包含DNS/SLB重定向、数据库主从提升、配置中心刷新，全程计时并记录RTO；
- 容量漂移监测：接入APM与基础设施监控，设置阈值告警——当某机房CPU均值连续2小时＞70%、或网络延迟突增＞50ms，自动触发容量复评流程。
