Elasticsearch 中 index、shard、replica 是什么？集群健康状态怎么判断？

简化版

index 是逻辑上的文档集合，shard 是 index 被切分后的物理分片，replica 是主分片的副本。集群健康通常看 green、yellow、red：green 表示主分片和副本都正常，yellow 表示主分片正常但副本未完全分配，red 表示至少有主分片不可用。

详细版

Elasticsearch 是分布式搜索引擎，一个索引的数据不会只放在一个“大文件”里，而是拆成多个 shard 分布在不同节点上。

index：面向业务的逻辑索引，例如 orders、logs-2026.07.19。
primary shard：主分片，负责承载数据写入，每个文档根据路由规则进入某个主分片。
replica shard：副本分片，用来提高可用性，也能分担读请求。
node：集群中的一台 Elasticsearch 进程实例。
cluster：多个节点组成的集群。

集群健康状态常见解释：

状态	含义	影响
green	所有主分片和副本分片都已分配	最健康
yellow	所有主分片已分配，但至少一个副本未分配	数据可查可写，但容灾不足
red	至少一个主分片未分配	部分数据不可用，必须排查

常见追问：

单节点集群为什么经常 yellow？因为副本不能和对应主分片放在同一个节点，单节点无法分配副本。
shard 越多越好吗？不是。分片太多会增加集群状态、文件句柄、内存和查询协调成本。
replica 只是备份吗？不只是。它还可以承担读请求，提高搜索吞吐。

完整版教学

一、index 是逻辑概念，shard 是真正承载数据的单位

业务上我们通常说“建一个商品索引”：

PUT /products

但底层不会把所有商品都塞进一个不可拆分的结构里。Elasticsearch 会把 index 切成一个或多个 primary shard，每个 shard 都是一个 Lucene 索引。

所以关系是：

index
  ├─ primary shard 0
  ├─ primary shard 1
  └─ primary shard 2

分片带来的好处是：

数据量大时可以横向分布到多个节点；
查询可以并行打到多个分片；
节点扩容后可以迁移部分分片实现负载均衡。

二、文档如何进入某个分片

Elasticsearch 会根据路由值决定文档落到哪个主分片。默认路由值通常是文档 _id，简化公式可以理解为：

shard = hash(routing) % number_of_primary_shards

这也解释了为什么主分片数量在索引创建后通常不能随便改：如果主分片数量变了，同一个文档 id 的路由结果可能完全不同，历史数据位置就乱了。

实际设计时要提前估算：

单个索引的数据规模；
未来增长速度；
查询并发；
单分片大小；
节点数量和磁盘规划。

三、replica 的两个作用：高可用和读扩展

副本分片保存主分片的数据副本。主分片所在节点故障时，某个副本可以提升为新的主分片，保证数据继续可用。

例如一个索引有 2 个主分片、1 份副本：

nodeA: primary-0, replica-1
nodeB: primary-1, replica-0

如果 nodeA 挂了，nodeB 上的 replica-0 可以被提升为 primary-0。同时，搜索请求也可以打到主分片或副本分片，因此副本还能提高读吞吐。

副本不能替代备份。副本解决节点故障下的高可用，误删除、误更新、逻辑污染仍然需要快照备份来恢复。

四、green、yellow、red 应该怎么排查

健康状态不要只看颜色，还要看原因。

常见排查命令：

GET /_cluster/health
GET /_cat/shards?v
GET /_cluster/allocation/explain

判断思路：

red：先确认哪些主分片未分配，是否节点丢失、磁盘满、索引损坏、分配规则限制。
yellow：看副本为何未分配，单节点集群、副本数过高、磁盘水位线、节点角色不匹配都可能导致。
green 但慢：颜色只代表分片分配状态，不代表查询一定快，还要看 CPU、JVM、磁盘 IO、慢查询和线程池。

五、分片数量设计的常见坑

分片不是越多越快。每个 shard 都有固定管理开销，分片太多会带来：

cluster state 变大；
查询需要协调更多 shard；
segment、文件句柄、缓存占用增加；
recovery 和 relocation 更慢。

但分片太少也有问题：单分片过大时迁移慢、恢复慢、单节点压力集中。生产环境通常结合数据量、保留周期和查询压力来设计，时间序列数据常配合 data stream、rollover 和 ILM 控制单个 backing index 的大小。

六、常见误区与追问

判断点	正确理解	常见风险
primary shard	数据路由和写入的主承载单元	创建后数量通常不应随意改
replica shard	高可用和读扩展	不能和对应 primary 放同一节点
yellow	主分片可用，副本未完全分配	单节点或副本数过高很常见
red	至少有主分片不可用	部分数据不可读写，要优先处理

3 个 primary，1 个 replica
理论 shard 总数 = 3 * (1 + 1) = 6
如果只有 1 个节点，副本无法分配，集群通常是 yellow。

易错点：green/yellow/red 只说明分片分配健康，不等于查询性能、写入吞吐和磁盘水位都健康。

如果一个日志索引每天 600GB，设置 12 个 primary，则单主分片大约 50GB；如果只设 1 个 primary，单分片会膨胀到 600GB，后续迁移和恢复都会非常重。反过来，如果每天只有 5GB 却建 50 个 primary，元数据和小分片管理成本会超过收益。

误区：shard 越多查询越快。 shard 越多，协调、调度、segment、文件句柄和 cluster state 成本越高，小数据量过度分片反而更慢。
误区：replica 就等于备份。 replica 会同步错误写入和删除，能抗节点故障，不能替代快照备份。
误区：yellow 一定是严重故障。 单节点开发环境配置 1 个副本时常见 yellow，生产要结合副本策略、节点数和分配解释判断。
追问：为什么主分片数量创建后不宜改？ 默认路由近似 hash(routing) % primary_count，主分片数变化会影响文档归属，需要 shrink、split 或重建索引等专门方案。
追问：副本能提升写入性能吗？ 通常不能，写入需要主分片处理并复制到副本，副本主要提升读吞吐和可用性。
追问：red 状态优先看什么？ 先定位未分配 primary shard，再查节点丢失、磁盘水位、allocation 规则、索引损坏或快照恢复情况。

七、加强记忆

记住“index 是业务入口，shard 是数据切片，replica 是容灾和读扩展”。green/yellow/red 的核心判断只看分片分配：主副本都好是 green，主好副本缺是 yellow，主分片缺就是 red。

简化版

详细版