3、容量水位概念
3.1 容量水位的定义
容量水位（Capacity Water Level）是衡量集群资源使用程度与剩余承载能力的归一化度量指标。它借鉴了水库水位管理的概念——水位过低意味着资源闲置浪费，水位过高则面临溢坝风险。在 Catalog 集群场景中，容量水位通常以百分比形式表示，反映当前负载与集群安全承载上限之间的比例关系。
核心公式：
容量水位(%) = (当前资源使用量 / 安全承载上限) × 100%其中安全承载上限 ≠ 理论最大容量，而是预留了 Buffer 的可运维上限，通常取理论峰值的 60%～75%。
容量水位覆盖多个资源维度，单一维度的水位不能代表集群整体健康状态。下表列出 Catalog 集群中最关键的五个水位维度：
| 维度 | 度量对象 | 典型安全水位阈值 | 说明 |
|---|---|---|---|
| CPU 水位 | 集群平均 CPU 利用率 | ≤ 70% | 超过 70% 时查询延迟开始非线性增长 |
| 内存水位 | JVM Heap 使用率 / 物理内存占用 | ≤ 75% | 接近 85% 时触发 Full GC 风险 |
| 磁盘水位 | 数据目录磁盘使用率 | ≤ 65% | 超过 70% 影响 compaction 与写入性能 |
| 连接水位 | 活跃客户端连接数 | ≤ 80% 最大连接数 | 连接池耗尽导致请求排队或拒绝 |
| IO 水位 | 磁盘 IOPS / 吞吐量 | ≤ 60% 设备上限 | IO 饱和是集群雪崩的常见诱因 |
3.2 为什么需要评估容量水位
在 Catalog 集群升级场景中，容量水位评估不是可选项，而是升级前置检查的必要环节。缺乏水位评估直接导致以下三类事故：
- 升级中资源耗尽：升级过程需要额外消耗 CPU 做元数据迁移、索引重建、数据校验。若水位已接近警戒线，升级操作会直接触发 OOM 或节点失联。
- 回滚窗口丢失：高水位集群在升级失败后回滚时，存量数据 + 回滚产生的临时数据可能撑爆磁盘，导致集群无法恢复到升级前状态。
- 级联故障扩散：升级期间单节点重启，剩余节点水位瞬时飙升。若初始水位已偏高，剩余节点会连锁过载，引发整个集群雪崩。
真实案例：某在线广告系统 Catalog 集群在未做水位评估的情况下执行滚动升级，升级前磁盘水位已达 68%。升级过程中 compaction 临时数据叠加，磁盘水位突破 92%，导致 3 个节点先后宕机，集群不可用长达 47 分钟。
容量水位评估在升级流程中承担三个关键角色：
- 准入检查：判断集群是否具备升级条件，水位超标则阻塞升级流程。
- 容量规划：为升级过程中的临时资源消耗预留 Buffer，指导是否需要提前扩容。
- 风险量化：将升级风险从定性描述转化为定量指标，便于决策是否执行升级。
3.3 水位与集群健康度的关系
集群健康度是一个综合状态评分，容量水位是其中权重最高的子指标。两者并非线性关系，而是存在明显的拐点效应：
| 水位区间 | 健康度评分 | 典型表现 | 升级可行性 |
|---|---|---|---|
| 0%～39% | 优秀（90～100） | 响应时间稳定，资源充裕 | 可直接升级 |
| 40%～69% | 良好（70～89） | 偶有毛刺，整体平稳 | 需评估升级窗口 |
| 70%～84% | 亚健康（50～69） | 延迟上升，GC 频繁 | 建议先扩容再升级 |
| ≥ 85% | 危险（＜ 50） | 请求超时，节点不稳定 | 禁止升级，立即降级 |
运维经验：健康度评分低于 70 的集群，升级失败率是健康集群的 4.2 倍。建议将水位 65% 设为升级的硬性准入红线，而非等到 70% 警戒线才介入。
水位与健康度的关系还体现在恢复弹性上：低水位集群在升级异常后能快速自愈，高水位集群则容易陷入"越恢复越差"的正反馈循环。因此，容量水位评估不仅是升级前的快照检查，更是贯穿升级全过程的持续监控指标。