容量规划需按故障场景差异化设计：同城双机房每中心按100%峰值配置，异地灾备按30%~50%计算资源但存储带宽须100%，异地多活需叠加分片流量120%及20%~30%接管余量，并以RPO=0和RTO≤3分钟倒推CPU≤60%、网卡余量30%等硬约束。
容量规划在多机房容灾和异地多活架构下，不能简单按“总流量 × 1.5 倍”来估算。它必须与故障场景、数据同步能力、流量调度策略深度耦合——冗余不是堆资源，而是为特定故障留出可执行的接管窗口。
明确每层冗余对应的具体故障域
不同距离的机房间，承载的容灾目标不同，容量冗余逻辑也不同：
- 同城双机房（如A城机房1 & 机房2）：目标是应对单机房断电、网络中断、局部火灾等。要求任一机房故障时，另一机房能100%承接全部流量。因此，每个机房的计算与数据库资源需按峰值流量的100%配置，而非50%——因为故障切换不是“分摊”，而是“全量接管”。
- 异地灾备中心（如B城机房）：目标是应对城市级灾难（地震、光缆被挖断、市政断电）。该中心平时不承担线上写流量，只做数据同步和只读分流。其容量只需满足RTO约束下的快速拉起能力，例如：数据库副本需在5分钟内完成主升备、应用集群需在3分钟内完成服务注册与健康检查。因此，其计算资源可按峰值的30%~50%预留，但存储空间和网络带宽必须100%匹配主中心，否则同步延迟或回档失败会直接破坏RPO=0承诺。
- 异地多活中心（如C城机房）：与主中心共同承担写流量，需按业务单元（如用户ID哈希、地域分片）划分写入责任。此时容量冗余的关键是写分区的交叉覆盖能力：例如A城负责华东用户写入，C城负责华北；但当A城故障时，C城需具备临时接管华东部分只读+关键事务的能力。因此，C城的数据库连接数、事务处理吞吐、热点缓存容量，需按自身分片流量的120% + 跨区接管预备量（通常为20%~30%）综合配置。
把RPO/RTO指标翻译成容量硬约束
容量不是越大越好，而是要卡在RPO和RTO的工程临界点上：
- RPO=0（零数据丢失）：意味着所有跨机房写操作必须走强同步（如OceanBase Paxos多数派提交）。这会抬高单次写延迟，进而影响单位时间内的最大TPS。因此，数据库节点的CPU与网络IO冗余必须保障：在同步链路出现20ms抖动时，仍能维持99.9%请求延迟＜100ms。实测中，建议写节点CPU长期负载不超过60%，网卡吞吐预留30%余量。
- RTO≤3分钟：要求故障检测（
用流量染色验证真实冗余水位
静态容量评估容易失真。真正可靠的冗余方案，必须通过带业务标识的压测来校准：
- 在正常多活状态下，对某一分片（如“深圳用户”）注入120%峰值流量，观察同城另一机房是否自动分担、异地机房同步延迟是否突破阈值（如＞500ms）；
- 主动切断A城机房出口网络，验证B城或C城能否在RTO内完成全量接管，并检查其CPU、内存、连接数是否瞬间冲顶——若某项指标达95%，说明该维度冗余不足，需针对性扩容而非整体加机器；
- 模拟数据库主节点宕机，观察仲裁服务选举与新主提供服务的时间，同时记录从库回放延迟曲线。若延迟在切换后持续＞2s，说明备库IO或重放线程配置不足，需调大replay并发度或SSD IOPS配额。
避免常见冗余陷阱
很多团队踩坑是因为混淆了“资源存在”和“容量可用”：
- 不要假设“有备份机房=有冗余容量”：灾备机房若未部署监控探针、未打通日志采集链路、未预热中间件连接池，故障时首次拉起可能超时失败；
- 不要用平均负载代替峰值水位：异地多活下，节假日或活动期间的跨区流量突增（如红包雨引发全国用户集中访问上海中心），可能让原本闲置的异地节点瞬间过载；
- 不要忽略“隐性容量瓶颈”：例如全局唯一ID生成器、分布式锁中心、配置中心ZooKeeper集群——这些组件若未做多机房部署或读写分离，会在切换时成为单点瓶颈，导致整个冗余架构失效。
容量冗余不是保险柜里的备用金，而是高速路上的应急车道——它必须时刻保持畅通、标线清晰、限速合理，才能在真正需要时让车流无缝并道。
