Appearance
第八部分：Elasticsearch 8 分布式高可用、倒排索引与 BM25 混合检索
第 1 章：Elasticsearch 8 分布式高可用架构与 Node 节点角色
在海量数据检索场景下，Elasticsearch 8 通过 分布式集群 (Cluster)、主从节点选举与 Shard 副本机制 实现 99.99% 的物理高可用。
text
[ ES 8 集群 (Cluster) ]
│
┌─────────────────────────────────┼─────────────────────────────────┐
↓ (专职候选主节点) ↓ (数据分片节点) ↓ (协调节点)
[ Master Node (3个) ] [ Data Node (N个) ] [ Coordinating Node ]
(掌管 ClusterState 元数据) (存储 Shard 倒排索引) (接收请求/Scatter-Gather)1.1 节点角色 (Node Roles) 生产部署规范
在 elasticsearch.yml 中，建议按物理职责分离节点角色：
| 节点角色 (Node Role) | 物理配置 node.roles | 物理职责 | 生产部署建议 |
|---|---|---|---|
| Master-eligible (候选主节点) | [ master ] | 参与 Leader 选举，维护全局 ClusterState (索引元数据、Shard 路由映射表) | 物理独立部署 3 个专职 Master 节点 |
| Data Node (数据节点) | [ data ] | 保存磁盘 Shard，负责文档的 CRUD 写入与 BM25 倒排索引检索 | 大内存 + 高性能 NVMe SSD 磁盘 |
| Ingest Node (预处理节点) | [ ingest ] | 在数据写入前执行 Pipeline 管道预处理 (如 JSON 转换/正则提取) | 独立部署轻量节点，防抢占 Data 内存 |
| Coordinating Node (协调节点) | [ ] (空列表) | 接收 Client 请求，分发 Scatter 至各 Shard，汇总 Gather 全局 Top-K 结果 | 所有节点默认均可充当 Coordinating Node |
1.2 Shard 分片路由与分布式高可用机制
text
[ 索引 order_index ] ➔ 拆分为 3 个 Primary Shards (P0, P1, P2) + 每个主分片配置 1 个 Replica Shard (R0, R1, R2)
[ Data Node 1 ] ➔ 存放 P0, R1
[ Data Node 2 ] ➔ 存放 P1, R2 <-- 强行铁律: Primary Shard 与其对应的 Replica Shard 绝不能在同一个物理 Node！
[ Data Node 3 ] ➔ 存放 P2, R0💬 面试官追问：“如果 Data Node 1 突然宕机，ES 集群如何自动完成故障转移 (Failover)？”
- 副本提升为主分片： Master 节点感知到 Node 1 离线后，立即将 Node 3 上存放的
R0(Replica 副本) 提升为P0(Primary 主分片)，保证写服务不中断； - 重新补全副本：集群从剩余的 Node 2 和 Node 3 中分配空白物理磁盘空间，重新生成新的
R0副本，使分片副本数恢复到健康状态 (Green)。
第 2 章：ES 写流程与读流程 (Scatter-Gather) 物理全过程
2.1 文档写入物理流程 (Write Pipeline)
text
[ Client 请求 ] ➔ [ Coordinating Node ] ➔ 根据 Hash(doc_id) % primary_shards 定位到 P0 (Node 1)
│
↓
[ P0 物理写入并生成 Segment ] ──(并发复制)──> [ R0 (Node 3) 物理写入 ] ➔ [ 收到 ACK 确认 ] ➔ [ 返回 Client 成功 ]2.2 检索流程物理原理 (Scatter-Gather 散发与聚合)
text
[ Client 搜索请求 ] ➔ [ Coordinating Node ]
│
├─────── 1. Scatter (散发阶段) ───────┐
↓ ↓
[ Shard P0 / R0 ] [ Shard P1 / R1 ]
(计算 BM25 得分) (计算 BM25 得分)
(返回 Top 10 Doc ID) (返回 Top 10 Doc ID)
│ │
└─────── 2. Gather (汇总阶段) ───────┘
│
↓
[ Coordinating Node 汇总排序 ]
(挑选出全局真正的 Top 10 Doc ID)
│
↓
[ 重新向各 Shard 提取全量 Source ] ➔ [ 返还 Client ]第 3 章：ES 脑裂 (Split-Brain) 防范与 ES 8 选主机制
💬 ES 脑裂产生原因与 ES 8 选主算法
- 脑裂现象：由于网络分区，部分 Master-eligible 节点与原 Master 断开，各自选出了新的 Master，导致集群分裂为两个独立的子集群，数据发生严重冲突；
- 旧版 ES (<7.0) 解决方案：手动配置
discovery.zen.minimum_master_nodes = (N/2) + 1； - ES 7/8 现代解决方案：摒弃了 Zen Discovery，引入了 Raft 变体分布式选主协议 (Voting Configurations)：
- ES 在集群元数据中动态维护一个法定得票配置列表 (Voting Config)；
- 选主时无需手动指定节点数，只有拿到法定列表半数以上选票的节点才能成为 Master，物理上彻底根除了脑裂风险。
🔍 本章 6 重自审计报告
- 【知识审计】：已全量补充 ES 8 节点角色分类 (Master-eligible/Data/Ingest/Coordinating)、Shard 主副本防同机铁律与 Failover 故障转移、写入写路、搜索 Scatter-Gather 物理过程，以及 ES 8 Raft 变体 Voting Config 防脑裂机制！已适配移动端
::: info 💬自适应排版！