企业官网建设流程全解析

节点角色 · 集群发现 · 分片路由 · 近实时引擎

目 录

一、导读
二、Lucene 索引与近实时引擎
2.1 段（Segment）与提交
2.2 近实时刷新（Refresh）
2.3 段合并与 flush
三、节点角色与集群组织
3.1 节点角色
3.2 集群发现
四、分片路由与协调
4.1 分片与副本
4.2 协调节点处理流程
4.3 读写路径与副本一致
五、架构要点对比
5.1 本篇小结

一、导读
第 01 篇认识了 Elasticsearch 的定位与倒排索引。本讲逐层拆解其架构：底层是「Lucene 索引与近实时引擎」，负责段文件、刷新与合并；中层是「节点与集群」，以角色划分主/数据/协调/摄取节点并通过集群发现互相感知；上层是「分片路由与协调」，把请求分发到目标分片聚合返回。理解这三层，才能看懂 ES 为何近实时、如何水平扩展。
二、Lucene 索引与近实时引擎
2.1 段（Segment）与提交
Elasticsearch 底层封装 Apache Lucene。每个分片内部由若干不可变的「段」（Segment）组成，一个段就是一个倒排索引子集。段一旦生成便只读，配合删除标记实现更新，避免原地修改带来的锁与磁盘碎片。
2.2 近实时刷新（Refresh）
写入先进入内存缓冲并追加到 translog（事务日志，保障崩溃可恢复）。默认每约 1 秒（index.refresh_interval）把缓冲中新文档生成一个可被搜索的新段，这就是「近实时」的来源——刚写入的数据约 1 秒后可被检索。
2.3 段合并与 flush
随时间推移会产生大量小段，后台「段合并」（Merge）按分层策略把小的合并为大的，减少段数量、提升检索效率，但合并瞬间可能增大 I/O 压力。flush 则是把内存段持久化到磁盘并清空 translog 的过程。
三、节点角色与集群组织
3.1 节点角色
节点角色 职责
主节点 master 集群元数据管理、分片分配决策
数据节点 data 承载主/副本分片，负责索引与检索
协调节点 coordinating 接收请求并分发聚合（默认角色之一）
摄取节点 ingest 写入前的管道预处理
机器学习/转换节点 ML 任务与跨索引聚合
生产建议：单节点可同时承担多角色；大规模集群宜让「仅 master」与「仅数据」节点分离，并用专用协调节点隔离聚合开销，避免主节点负载过重。
3.2 集群发现
节点通过集群发现（Discovery）互相感知并选出一个活跃主节点。Elasticsearch 8 默认使用基于安全证书的权威主机（discovery.seed_hosts + cluster.initial_master_nodes），不再默认依赖组播或 Zen Ping 的无鉴权发现，提升安全性。
四、分片路由与协调
4.1 分片与副本
索引创建时指定主分片数（不可轻易修改），每个主分片可有若干副本分片（默认 1）。文档按路由值（默认 _id 哈希）路由到具体分片，分片分布在不同节点上实现水平扩展与容错。生产建议单个主分片控制在 10–50 GB 左右，过小则分片过多、过大则均衡与恢复缓慢。
路由示例：
// 按 _id 哈希路由到分片，同一索引所有节点共享分片
shard = hash(routing) % number_of_primary_shards
PUT /article/_doc/1
4.2 协调节点处理流程
•接收请求，解析集群状态确定目标索引与分片。
•将请求分发到相关主/副本分片所在节点。
•各分片本地检索后，协调节点归并排序、执行聚合。
•返回最终结果给客户端。
4.3 读写路径与副本一致
写入由主分片完成并同步到副本（副本写确认后可配置 wait_for_active_shards 控制）；检索默认在主、副本分片间负载均衡，可设置 routing 或 preference 控制读哪个副本，兼顾一致性与读扩展。
五、架构要点对比
维度 机制 作用
存储 Lucene 不可变段 + 倒排索引 高效全文检索
近实时 refresh 每约 1 秒 + translog 秒级可见、崩溃可恢复
集群 节点角色 + 集群发现 元数据一致、选主
分片 主分片 + 副本 水平扩展与容错
协调 协调节点分发聚合 统一检索归并
合并 后台段合并 减少段数、提升效率
5.1 本篇小结
本讲从引擎、集群、路由三层拆解 ES 架构：底层 Lucene 段文件支撑近实时检索与后台合并；节点角色划分与集群发现组织起分布式集群；分片路由与协调节点完成请求分发与结果归并。理解这三层，是后续核心原理、部署与选型的基础。
下一篇进入核心原理，深入倒排索引物理结构、BM25 相关性打分与段合并策略。