3. 分片采集基础概念：Shard、Replica、一致性哈希与目标分配原理
在 Prometheus 大规模集群中，单个采集器无法承载成千上万个 ServiceMonitor 目标。分片（Shard）与副本（Replica）机制将采集任务水平拆分，配合一致性哈希实现目标在采集器间的均匀、稳定分配。本节从核心概念出发，逐步拆解分片采集的底层原理。
3.1 Shard 与 Replica：水平拆分与冗余采集
| 概念 | 定义 | 作用 | 典型配置 |
|---|---|---|---|
| Shard（分片） | 将采集目标集合按规则拆分为多个子集，每个子集由一个独立的采集器负责 | 水平扩展采集能力，突破单机采集上限 | shards: 3 |
| Replica（副本） | 为每个分片创建多个冗余采集实例，同时采集相同目标 | 提高采集可用性，容忍单点故障 | replicas: 2 |
关键区别： Shard 拆分目标集，每个分片采集不同的目标；Replica 复制采集任务，多个副本采集相同的目标。两者组合使用形成“分片 × 副本”矩阵。
例如，shards: 3 + replicas: 2 将产生 6 个采集器实例：3 个分片各拥有 2 个副本，每个副本独立采集所属分片的目标。
3.2 一致性哈希：目标分配的核心算法
一致性哈希（Consistent Hashing）是分片采集的分配引擎。它将目标与采集器映射到同一个哈希环上，实现以下目标：
- 均匀分布： 目标在环上均匀散列，避免热点分片。
- 最小扰动： 分片数变化时，仅重新分配少量目标，而非全量重排。
- 确定性分配： 相同目标始终分配到相同分片，保证采集一致性。
实践要点： 一致性哈希的虚拟节点（Virtual Node）数量直接影响分配均匀性。在 Prometheus Operator 中，每个采集器默认在环上注册 100 个虚拟节点，以平滑目标分布。
3.3 目标分配原理：从 ServiceMonitor 到采集器
Prometheus Operator 将 ServiceMonitor 中的目标分配到具体采集器的完整链路如下：
- 目标发现： Operator 根据 ServiceMonitor 的 selector 匹配 Service 和 Endpoints，生成采集目标列表。
- 哈希计算： 对每个目标的唯一标识（如
__address__+__metrics_path__）计算哈希值。 - 环上定位： 将哈希值映射到一致性哈希环，顺时针查找最近的采集器虚拟节点。
- 分片归属： 目标被分配到该虚拟节点所属的 Shard。
- 副本分发： 每个 Shard 内的所有 Replica 实例都接收该分片的目标列表，独立执行采集。
容量校准关键点： 目标分配不均匀会直接导致部分分片过载。校准时应检查每个分片的目标数量标准差，标准差超过均值 20% 时需调整虚拟节点数或增加分片。
3.4 分片与副本的容量影响
在容量校准中，Shard 和 Replica 对资源消耗的影响不同：
| 维度 | 增加 Shard | 增加 Replica |
|---|---|---|
| 目标数/实例 | 减少（目标被拆分） | 不变（副本采集相同目标） |
| CPU 总消耗 | 基本不变（拆分后总计算量相近） | 线性增加（每个副本独立计算） |
| 内存总消耗 | 略有增加（更多实例开销） | 线性增加（每个副本独立存储） |
| 网络出口流量 | 不变（总采集量不变） | 线性增加（重复拉取） |
| 可用性 | 不变（单分片故障仍丢失部分目标） | 提升（副本接管故障实例） |
校准建议： 优先通过增加 Shard 解决单采集器过载问题，仅在需要高可用保障时增加 Replica。每增加 1 个 Replica，集群总资源消耗约增加 1 倍（对应该分片）。
3.5 一致性哈希的扰动测试
分片数变更时，一致性哈希的“最小扰动”特性可通过以下公式量化：
重分配比例 = (变更后分片数 - 变更前分片数) / 变更后分片数 × 100%
示例：
- 分片数从 3 增加到 4：重分配比例 ≈ (4-3)/4 = 25%
- 分片数从 3 增加到 6：重分配比例 ≈ (6-3)/6 = 50%
- 分片数从 3 减少到 2：重分配比例 ≈ (3-2)/3 ≈ 33%实际重分配比例受虚拟节点数和目标分布影响，上述公式为理论下限。校准时应监控重分配期间采集器的 CPU 峰值和内存增长，确保不触发 OOM。