Elasticsearch (ES) 的核心原理可以概括为：基于 Lucene 的分布式、近实时（NRT）搜索引擎。它通过分片（Sharding）实现水平扩展，通过副本（Replica）实现高可用，通过倒排索引（Inverted Index）实现极速检索。
以下是 Elasticsearch 核心原理的深度详解：
1. 底层基石：Lucene 与 倒排索引
Elasticsearch 本身不存储数据，也不直接进行全文检索，它是对 Apache Lucene 的封装和分布式扩展。
倒排索引 (Inverted Index)
这是 ES 快如闪电的核心。与传统数据库的“正排索引”（文档 ID -> 内容）不同，倒排索引建立了 词项 (Term) -> 文档列表 (Doc IDs) 的映射。
- 结构：
- Term Dictionary (词典)：所有不重复的词项，按字典序排序（通常使用 FST - 有限状态转换器压缩存储）。
- Term Index (词典索引)：词典的索引，用于快速定位词典中的位置（类似书的目录）。
- Posting List (倒排表)：包含该词项的所有文档 ID 列表，以及词频、位置信息等。
- 优势：查询 "apple" 时，直接在词典中找到 "apple"，直接获取包含它的文档 ID 列表，无需遍历所有文档。
分词 (Analysis)
在建立索引前，文本会经过 Analyzer 处理：
- Character Filters: 去除 HTML 标签，转换字符（如
&->and）。 - Tokenizer: 将文本切分为词项（Token），如
"I love ES"->["I", "love", "ES"]。 - Token Filters: 小写化、去停用词、同义词替换、词干提取（
running->run）。
2. 分布式架构：分片与副本
为了处理 PB 级数据和高并发，ES 采用了 Share Nothing 的分布式架构。
索引 (Index) 与 分片 (Shard)
- Index: 逻辑上的命名空间，类似关系型数据库的 "Database"。
- Shard: 物理上的数据单元。一个 Index 被拆分成多个 Shard，分布在集群的不同节点上。
- 主分片 (Primary Shard): 负责数据的写入和读取。数量在创建索引时确定，不可动态修改（除非重建索引）。
- 设计原则: 分片数决定了集群的最大容量上限。
副本 (Replica)
- 作用:
- 高可用 (HA): 当主分片所在节点宕机，副本自动晋升为主分片。
- 读扩展: 副本也可以处理读请求（搜索），从而提升查询吞吐量。
- 动态性: 副本数量可以随时动态调整。
节点角色 (Node Roles)
- Master Node: 管理集群元数据（创建/删除索引、分片分配）。不存储数据，避免大对象阻塞。
- Data Node: 存储数据，执行 CRUD、搜索、聚合操作。资源消耗最大（CPU/内存/磁盘）。
- Coordinating Node: 接收客户端请求，分发到对应分片，汇总结果后返回。相当于负载均衡器（所有节点默认都是协调节点）。
- Ingest Node: 在数据写入前进行预处理（类似 Logstash 的功能）。
3. 写入原理 (Write Path)
ES 的写入流程体现了其 近实时 (NRT) 的特性。
- 路由 (Routing): 客户端发送请求给任意节点（协调节点）。协调节点根据
routing = hash(doc_id) % num_primary_shards计算出文档属于哪个主分片。 - 转发: 协调节点将请求转发给对应的主分片节点。
- 写入内存缓冲 (Memory Buffer):
- 数据首先写入内存中的 Buffer。
- 同时写入 Translog (事务日志，存储在磁盘)，防止断电丢失。
- 此时数据尚未可搜。
- Refresh (刷新):
- 默认每隔 1秒，ES 执行 Refresh 操作。
- Buffer 中的数据被清空，生成一个新的 Segment (Lucene 的只读文件) 并写入文件系统缓存 (OS Cache)。
- 新的 Segment 对搜索可见。这就是“近实时”的来源（延迟约 1 秒）。
- Flush (落盘):
- 默认每 30 分钟或 Translog 满时执行。
- 将内存中的所有 Segment 强制刷入磁盘 (fsync)。
- 清空 Translog。
- Merge (合并):
- 后台线程会将多个小的 Segment 合并成大的 Segment，删除已标记删除的文档，优化查询性能。这是一个重 IO 操作。
复制流程: 主分片写入成功后，并行将请求发送给所有副本分片。只有当主分片和大多数副本写入成功后，才向客户端返回成功。
4. 读取原理 (Read Path)
ES 的搜索遵循 Query Then Fetch 两阶段模式。
阶段一：Query (查询)
- 协调节点将查询请求广播到所有相关的分片（主分片或其副本）。
- 每个分片在本地执行搜索，构建一个优先队列，只保留 Top-K 个最匹配的文档 ID 及其排序值（Score）。
- 分片将这些精简的结果返回给协调节点。
- 协调节点合并所有分片的结果，进行全局排序，选出最终的 Top-K 文档 ID。
阶段二：Fetch (取回)
- 协调节点根据最终确定的 Doc IDs，向对应的分片发起请求，获取完整的文档源数据 (
_source)。 - 分片返回完整文档。
- 协调节点组装最终结果返回给客户端。
注意: 如果需要深度分页（如 from=10000, size=10），性能会急剧下降，因为每个分片都要准备 10010 条数据。此时应使用 search_after 或 scroll API。
5. 关键机制详解
近实时性 (NRT) vs 实时性
ES 不是严格实时的（写入后立即可见），而是 NRT。这是因为 Lucene 的 Segment 一旦生成就是只读的。频繁生成 Segment 会导致大量小文件，影响性能。1 秒的 Refresh 间隔是性能与实时性的最佳平衡点。
相关性评分 (Relevance Scoring)
ES 默认使用 BM25 算法（早期版本用 TF-IDF）计算文档与查询的相关度分数。
- TF (Term Frequency): 词频，词在文档中出现越多，分数越高。
- IDF (Inverse Document Frequency): 逆文档频率，词在所有文档中越稀有，分数越高。
- Field Length Norm: 字段越短，匹配权重越高。
- 注: 在 ES 8.0+ 中，引入了基于机器学习的排序学习 (Learning to Rank) 和向量搜索 (Vector Search/Cosine Similarity)，以支持语义检索。
并发控制 (Optimistic Concurrency Control)
ES 不使用锁，而是利用 _seq_no (序列号) 和 _primary_term 来实现乐观锁。
- 更新文档时带上
if_seq_no和if_primary_term。 - 如果当前文档的版本号不匹配，则更新失败，防止覆盖其他人的修改。
脑裂问题 (Split Brain)
在旧版本中常见，当网络分区导致集群分裂成两个都选举出 Master 的子集群时发生。
- 解决:
discovery.zen.minimum_master_nodes(7.x 之前) 或 Quorum 机制。 - 现状: ES 7.x+ 重构了选举协议，基于 Raft 算法思想，彻底解决了脑裂问题，不再需要手动配置最小主节点数。
6. 总结：Elasticsearch 的核心权衡
| 特性 | 原理支撑 | 权衡 (Trade-off) |
|---|---|---|
| 高吞吐写入 | 内存 Buffer + 顺序写 Translog + 异步 Refresh | 数据有约 1 秒的可见延迟 (NRT) |
| 极速搜索 | 倒排索引 + FST 压缩 + OS Cache | 随机读性能较差，不适合高频单点更新 |
| 水平扩展 | 自动分片 (Sharding) + 路由哈希 | 分片数一旦设定难以缩减，规划需前瞻 |
| 高可用 | 多副本 (Replica) + 自动故障转移 | 写入成本增加 (需写多份)，存储空间翻倍 |
| 复杂分析 | 列式存储优化 (Doc Values) | 占用额外磁盘空间，但极大加速排序/聚合 |
理解这些原理，有助于在设计索引映射 (Mapping)、调整分片策略、优化查询语句 (DSL) 以及进行集群调优时做出正确的决策。