1. 集群高可用与容量工程导论

在 Elasticsearch 生产环境中，稳定性问题往往不是由单一故障引起的，而是“高可用能力不足”与“容量规划失衡”叠加的结果。理解这两条主线的定义、目标与协同关系，是后续所有工程实践的基础。

一、什么是高可用与容量工程

高可用（High Availability，HA）关注的是：当节点、磁盘、网络、机房甚至整个可用区发生故障时，集群能否继续提供可接受的服务，并在故障恢复后自动回到健康状态。它的核心指标是可用性，通常用“年停机时间”衡量，例如 99.9% 对应年停机约 8.76 小时，99.99% 对应约 52.6 分钟。

容量工程（Capacity Engineering）关注的是：集群在给定硬件、数据量、写入速率和查询负载下，能否稳定承载预期业务，并在业务增长时以可预测的方式扩展。它的核心指标是资源水位与性能余量，例如 CPU 使用率、JVM 堆占用、磁盘使用率、写入延迟和查询 P99 延迟。

两者不是独立的两件事。高可用决定了“故障时还能不能用”，容量工程决定了“平时够不够用、增长时撑不撑得住”。只做高可用不做容量，集群会在业务增长中逐渐被压垮；只做容量不做高可用，一次节点故障就可能让整个索引不可用。

二、核心目标与关键挑战

高可用的目标可以归纳为三点：故障可容忍（单节点、单磁盘、单可用区故障不导致数据丢失和服务中断）、恢复可自动（主分片迁移、副本提升、重新分配自动完成）、状态可观测（集群健康、分片状态、恢复进度可被及时发现）。

容量工程的目标同样可以归纳为三点：资源可预测（知道当前水位和增长趋势）、扩展可规划（提前知道加多少节点、加多少磁盘）、性能可保障（在目标负载下延迟和吞吐满足 SLA）。

在实际生产中，这两条主线会同时遇到以下挑战：

• 分片数量与大小的平衡：分片过多会放大集群状态和协调开销，分片过大则导致恢复慢、单点故障影响面大。
• 副本与成本的权衡：副本提升可用性，但占用额外存储和写入放大；副本不足则故障时可能丢数据或无法提升主分片。
• 热点与倾斜：按时间或业务键分片时，容易出现写入或查询集中在少数分片，导致局部资源耗尽。
• 恢复风暴：节点故障后大量分片同时恢复，会争抢网络和磁盘 IO，反而拖慢整体恢复。
• 容量与性能的非线性：磁盘使用率超过约 85% 后，写入和合并性能会明显下降；JVM 堆超过约 75% 后，GC 停顿风险显著上升。

三、二者在 Elasticsearch 中的协同关系

在 Elasticsearch 中，高可用与容量工程通过分片分配、副本策略和资源水位三个机制紧密耦合。分片分配决定了数据在节点间的分布，副本策略决定了故障时的数据冗余，资源水位决定了集群是否还能接受新的分片和写入。

一个典型的协同场景是：当某个数据节点故障时，集群需要将该节点上的主分片对应的副本提升为主分片，并在其他节点上重新分配副本。这个过程既依赖高可用配置（有副本可提升），也依赖容量余量（其他节点有足够磁盘和 CPU 承接迁移）。如果容量已经接近上限，恢复过程会变慢甚至失败，高可用目标就无法达成。

下面的 SVG 展示了高可用与容量工程在 Elasticsearch 集群中的协同关系：左侧是可用性维度，右侧是容量维度，中间通过分片分配和资源水位相互约束。

四、一个可执行的协同检查示例

下面给出一个用于评估“高可用与容量是否协同”的检查表，字段和判断依据均围绕 Elasticsearch 生产环境设计，可直接用于日常巡检或变更前评估。

五、从导论到工程实践

理解高可用与容量工程的协同关系后，后续章节会分别展开：如何设计分片与副本策略、如何监控资源水位、如何规划扩容、如何处理故障恢复、如何做容量预测。每一部分都会围绕“可用性”和“容量”两个维度同时评估，避免只优化一端而让另一端成为瓶颈。

在实际工作中，建议把这两个维度写进同一份运维基线文档：每次变更前，同时回答“故障时还能用吗”和“增长时还够用吗”两个问题。只有两个答案都成立，集群才算真正处于可交付状态。