集群架构：节点、分片与高可用

这一课你将能做到

1. 说出 master、data、coordinating、ingest 等节点角色各自的职责
2. 画图解释主分片（primary shard）与副本分片（replica shard）如何协作，以及一次写入在分片间的流转过程
3. 解释脑裂（split-brain）的成因，以及 7.x 之后集群投票机制如何防住它；能对本站题库索引规划合理的分片数

为什么要学

单机 Lucene 的容量和吞吐有天花板：一块盘装不下、一个 CPU 算不过来、机器宕了服务就没了。ES 在 Lucene 外面套了一层分布式壳——把一个索引切成多个分片散布到多台机器，每个分片再放副本做冗余。理解这套结构，你才看得懂「为什么我建索引时指定 5 个主分片」「为什么一台机器挂了搜索没断」「为什么集群状态变红/变黄」。

人话：分片就像把一本厚题库拆成 5 本分册放在不同书架上，任何一个书架只扛五分之一的量；副本就是每本分册再复印一份放到别的书架，原书架塌了复印件顶上。本站当前规模一台机器就装得下，但知识必须按生产标准学——面试和工作中，分片规划不当（过度分片）是 ES 最常见的性能事故来源。

先建立图像

一个 3 节点集群、索引设 3 个主分片、每分片 1 个副本的布局：

          节点A              节点B              节点C
       ┌──────────┐      ┌──────────┐      ┌──────────┐
       │ P0       │      │ P1       │      │ P2       │
       │ R1       │      │ R2       │      │ R0       │
       └──────────┘      └──────────┘      └──────────┘

P = 主分片(primary)   R = 副本分片(replica)，R0 是 P0 的副本
规则：主分片和它的副本永不在同一节点（否则宕机一起没）

一次写入的流转（文档 ID 为 1，路由到 P2）：

客户端 → 任意节点(协调节点)
  → 按 hash(_id) 算出该文档属于 P2，转发给节点B
  → P2 写入成功后，同步转发给节点C 上的 R2
  → P2 与 R2 都成功后，协调节点向客户端返回成功

一次搜索的流转则不同：协调节点把请求发给每个分片（主或副本任选其一），各分片返回本地 Top N，协调节点汇总归并出全局排序——这叫 scatter-gather（分散-汇聚）。

集群健康状态三色：

GREEN  所有主分片和副本分片都正常
YELLOW 主分片全正常，但有副本分片未分配（单节点集群必然 YELLOW：副本没地方放）
RED    有主分片未分配，部分数据无法读写

跟着做

步骤 1：查看集群健康与节点信息

# 健康状态
curl -u elastic:abcd1234 "http://localhost:9200/_cluster/health?pretty"

# 节点列表及角色，node.role 字段：m=master, d=data, i=ingest 等
curl -u elastic:abcd1234 "http://localhost:9200/_cat/nodes?v"

单节点环境下你会看到 status: yellow，原因就是上节说的：主分片有了，但 1 个副本无处安放。

步骤 2：建索引时指定分片数

curl -u elastic:abcd1234 -X PUT "http://localhost:9200/questions" -H "Content-Type: application/json" -d'
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  }
}'

关键规则：主分片数在索引创建后不能修改（只能通过 split/拆分或 reindex 重建），副本数可以随时调整。所以分片数是需要提前想的决策。

查看分片分布：

curl -u elastic:abcd1234 "http://localhost:9200/_cat/shards/questions?v"