三个约束的相互牵制
容量、性能与可用性并非独立指标。提高可用性意味着更多冗余副本或控制器，直接占用可用容量并增加成本；提高性能往往要用更贵的介质或更多控制器，压缩同等预算下的容量；而追求极致容量效率（如高比例纠删码）又会延长重建时间，降低可用性保障。因此选型的第一步是确定「底线」：业务能接受的最长中断时间、可承受的数据丢失点、必须达到的时延上限，以及三年内的容量需求。底线确定后，再评估不同方案在剩余维度上的表现，用成本作为最后的比较尺度。反过来先看报价再补指标，通常会在验收阶段返工。
三要素的取舍关系
| 追求目标 | 通常的代价 | 缓解方式 |
|---|---|---|
| 更高可用性 | 冗余占用容量、成本上升 | 按业务分级，仅关键系统做高等级冗余 |
| 更低时延 | 介质成本上升 | 分层与缓存，只让热点数据用高成本介质 |
| 更高容量效率 | 重建时间延长，风险窗口变大 | 提高重建带宽、留足预留空间 |
| 更低成本 | 性能或冗余被削弱 | 用限流与隔离保护关键业务 |
基本信息
| 容量约束 | 三年可用容量需求，含冗余与预留开销 |
|---|---|
| 性能约束 | 业务可接受的时延上限与高峰期并发能力 |
| 可用性约束 | 允许的中断时长与数据丢失点，对应所需的冗余等级 |
| 成本口径 | 设备、机柜、供电、运维与扩容周期的总投入 |
| 验证手段 | 按真实负载做混合并发测试并演练单点故障 |
典型使用场景
- 核心系统选型：时延与可用性优先，容量在预算内尽量满足
- 外围与归档系统：容量与成本优先，性能要求可放低
- 虚拟化平台：需要三者在同一套基础设施上取得平衡，通常靠分层实现
- 灾备建设：可用性目标决定副本与异地策略，同时带来成倍容量需求
- 老系统替换：对比现状瓶颈，明确本次要解决的是容量、性能还是可靠性问题
可用性目标要用数字表达：例如「单控制器故障时业务不中断、单站点故障时数据不丢失，恢复时间不超过某时长」。没有数字的目标无法转成具体冗余设计，也无法验收。
冗余设计要覆盖整条链路：控制器、链路、交换机、供电与固件升级路径都要逐项确认单点。只做控制器冗余而忽略供电或交换设备，实际可用性提升有限。