Elasticsearch 分片与副本

一、先搞清楚三个核心概念

点击卡片展开详细说明

🧩

分片 (Primary Shard)

索引数据的「物理子集」。一个索引被水平切成多块，每块就是一个主分片。

类似你把一本书拆成 5 册，每册独立存放。
关键特性：数量在索引创建时确定，之后不可更改。
默认 1 个主分片（ES7+），生产环境通常设为 3~5 个。

🪞

副本 (Replica Shard)

主分片的完整拷贝，用冗余换可靠性和读性能。

每本书的每一册都额外复印一份。副本分片与主分片永远不会在同一节点。
副本数量可动态调整，不影响数据完整性。
副本既可做容灾备份，也可分担读请求。

🖥️

节点 (Node)

运行 ES 实例的服务器。分片的物理载体。

一个节点可以存储多个分片（来自不同索引）。
每个节点默认既是数据节点又是协调节点。
ES 自动决定哪个分片放在哪个节点，无需人工干预。

📦

索引 (Index)

一群主分片 + 副本分片的逻辑集合。

索引 = 所有主分片 ∪ 所有副本分片。
向索引写入时，ES 自动路由到正确的分片；
从索引读取时，ES 可从任一主/副本分片读取。

二、集群沙盘 — 模拟真实的 ES 集群

可视化展示分片在节点间的分布，支持交互操作

集群状态：🟢 GREEN | 3 个节点 | 主分片：3 | 副本：1

图例：■ 主分片 ■ 副本分片

集群健康

总文档数: 0

写入延迟: -

[11:42] 集群已启动，等待操作...

三、写入流程 — 一条文档是如何落地的

从客户端发出请求，到数据安全存储在磁盘的全过程

1 客户端发送写入请求 —— POST /my_index/_doc/1 0ms

2 协调节点路由 —— 根据文档 ID 计算 hash，确定目标主分片 ~1ms

3 主分片写入 —— 目标主分片先写入文档，校验、建索引 ~5ms

4 主分片转发给副本 —— 主分片并行发送写请求给所有副本分片 ~2ms

5 副本确认写入 —— 每个副本分片写入完成后回复 ACK ~5ms

6 主分片收集 ACK，返回成功 —— 主分片向协调节点报告完成 ~1ms

四、读取流程 — 副本如何分担读压力

ES 使用轮询策略，主分片和副本分片都可以响应读请求

1 客户端发送查询请求 —— GET /my_index/_search 0ms

2 协调节点广播 —— 把查询发给所有目标分片（主或副本均可） ~1ms

3 各分片本地查询 —— 在每个分片上并行执行搜索 ~10ms

4 协调节点合并结果 —— 收集各分片返回的 Top-N 结果，全局排序 ~3ms

5 返回最终结果 —— 将合并后的结果返回给客户端 0ms

五、路由算法 — 文档存到哪个分片？

ES 通过一致性哈希决定每个文档落在哪个分片，输入 ID 试试看

公式：shard = hash(_routing) % number_of_primary_shards

默认 _routing = _id。这就是为什么「主分片数量创建后不可更改」—— 改了之后 hash 结果完全不同！

输入文档 ID：

六、故障恢复 — 节点宕机后会发生什么？

副本的核心价值：用空间换可靠性

🔄 场景 A：副本提升

某个只有副本分片的节点宕机 → 集群变 YELLOW → ES 在其它节点重建副本 → 恢复 GREEN

⚠️ 场景 B：主分片丢失 + 副本接替

存有主分片的节点宕机 → ES 立刻将对应副本提升为主分片 → 在新节点重建副本 → 恢复 GREEN

[--:--] 点击上方场景卡片，查看自动恢复过程...

七、总结对比表

维度	主分片 (Primary)	副本分片 (Replica)
本质	数据的原始物理分区	主分片的完整拷贝
数量	创建时确定，不可改	可动态增减
写入	唯一写入入口	从主分片接收数据
读取	可读 ✅	可读 ✅（分担压力）
与主分片位置	—	绝不能和对应主分片同节点
故障时	对应副本提升为主	在其它节点重建
影响性能	分片越多，写入越慢	副本越多，写入越慢（等待更多 ACK），但读取越快
公式关系	总数据量 = 主分片数 × 每个主分片数据量总存储量 = 主分片数 × (1 + 副本数) × 每个主分片数据量

🎯 一句话总结

分片解决的是「存不下」的问题（水平扩展），
副本解决的是「靠不住」的问题（高可用 + 读吞吐）。
两者配合，让 ES 既能存 PB 级数据，又能在节点宕机时自动恢复、无感知对外服务。

Elasticsearch 分片 & 副本