3. 故障域概念与分类
在构建高可用的 Helm Chart 仓库缓存体系时，故障域（Failure Domain）是决定缓存策略与资源隔离粒度的核心概念。故障域定义了一个组件或资源发生故障时，所影响的范围边界。理解故障域的分类，能够帮助架构师在设计缓存层时，合理规划副本分布、流量调度与数据冗余策略，从而将故障爆炸半径控制在最小范围内。
3.1 故障域定义
故障域是指系统中一组共享单一故障点的资源集合。当该故障点失效时，集合内的所有资源将同时不可用。故障域的边界决定了故障的影响范围，也是设计高可用架构时进行冗余部署的基本单元。
核心原则：故障域越小，故障影响面越窄；故障域之间越独立，系统整体可用性越高。缓存策略应优先将数据副本分布到不同的故障域中。
3.2 物理故障域
物理故障域以硬件和基础设施的物理边界为划分依据，是最直观的故障隔离维度。在 Helm Chart 仓库的缓存部署中，物理故障域直接影响缓存节点的物理位置选择。
| 故障域层级 | 定义 | 典型故障场景 | 缓存策略影响 |
|---|---|---|---|
| 机房级 | 独立建筑内的数据中心，拥有独立的电力、网络、制冷系统 | 市电中断、火灾、光纤被挖断 | 缓存集群必须跨机房部署，禁止单机房承载全部缓存流量 |
| 机架级 | 同一机架内的服务器共享电源分配单元（PDU）和接入交换机 | 机架电源跳闸、ToR 交换机故障 | 缓存副本应分布在不同机架，避免机架级故障导致缓存全部丢失 |
| 节点级 | 单台物理服务器或虚拟机实例 | 磁盘损坏、内存故障、操作系统崩溃 | 缓存数据应在节点间冗余，单节点故障不影响整体缓存命中率 |
3.3 逻辑故障域
逻辑故障域是基于云平台或分布式系统的抽象概念，不直接对应物理硬件，但决定了流量调度、数据复制和故障切换的逻辑边界。在 Kubernetes 和云原生环境中，逻辑故障域通常由 Region 和 Availability Zone（AZ）来定义。
| 逻辑域 | 定义 | 典型隔离特性 | 缓存部署建议 |
|---|---|---|---|
| Region | 地理区域内的独立云服务区域，通常包含多个 AZ | 跨 Region 延迟高（>10ms）、带宽成本高、完全独立控制面 | 缓存数据不跨 Region 同步，每个 Region 维护独立缓存集群 |
| Availability Zone (AZ) | Region 内独立的可用区，拥有独立的电力、网络和冷却设施 | AZ 间延迟低（<2ms）、高带宽、故障隔离但控制面共享 | 缓存副本跨 AZ 分布，实现 AZ 级高可用 |
实践要点：在 Helm Chart 仓库的缓存架构中，建议将缓存主节点部署在多个 AZ 中，每个 AZ 内再分布到不同机架。Region 之间通过异步复制或独立缓存实例解耦，避免跨 Region 的强一致性开销。
3.4 软件故障域
软件故障域以进程、容器、Pod 等软件运行单元为边界。在 Kubernetes 环境中，软件故障域是最细粒度的隔离维度，也是 Helm Chart 仓库缓存策略可以直接控制的层级。
- 进程级故障域：单个操作系统进程崩溃或死锁，影响该进程提供的缓存服务。通过多进程架构或 sidecar 代理实现隔离。
- 容器级故障域：单个容器因 OOM、资源耗尽或配置错误而终止。Kubernetes 通过 Pod 内的容器重启策略进行恢复。
- Pod 级故障域：Pod 整体被驱逐或节点故障导致 Pod 重建。通过 Deployment/StatefulSet 的副本机制和 PDB（PodDisruptionBudget）保障最小可用副本数。
- 命名空间级故障域：Kubernetes 命名空间内的资源隔离。不同团队的缓存实例可部署在不同命名空间，避免相互影响。
3.5 故障域分类总结
下表从故障隔离粒度、恢复方式和缓存策略影响三个维度，对三类故障域进行横向对比：
| 故障域类型 | 隔离粒度 | 典型恢复方式 | 缓存策略关键设计 |
|---|---|---|---|
| 物理故障域 | 粗（机房/机架） | 基础设施冗余、跨机房切换 | 缓存数据跨机房/机架分布，避免单点物理故障 |
| 逻辑故障域 | 中（Region/AZ） | DNS 切换、流量调度、跨 AZ 负载均衡 | 缓存副本跨 AZ 部署，Region 间独立缓存实例 |
| 软件故障域 | 细（进程/容器/Pod） | Kubernetes 自动重启、滚动更新、PDB 保护 | 缓存 Pod 反亲和性调度、多副本、资源配额隔离 |
常见误区：仅关注软件故障域（如 Pod 多副本）而忽略物理故障域（如所有 Pod 调度到同一机架），会导致机架级故障时缓存完全不可用。故障域设计必须从物理层到软件层进行全栈覆盖。