- Elasticsearch 和 Lucene 是什么关系？
这是高频第一问。
你可以答：
"Lucene 是底层全文检索库，负责倒排索引、分词、评分这些核心能力。Elasticsearch 是在
Lucene 之上做的分布式封装，提供了集群、分片、副本、REST API、聚合分析这些工程能力。
也就是说，Lucene 更像搜索内核，Elasticsearch 更像可直接落地的分布式搜索引擎。"
一句话版本：
Lucene 解决'怎么搜'，ES 解决'怎么大规模稳定地搜'。
- ES 为什么查询快？
核心答法：
-
倒排索引，不是全表扫描
-
term 到 posting list 的查找很快
-
多分片并行查询
-
Lucene 的 segment 机制和缓存优化
-
ES 协调节点负责聚合结果
你可以说：
"ES 查询快最核心还是因为 Lucene 的倒排索引，把'词 -> 文档列表'提前建好了，不用像数
据库那样扫行。另外 ES 把一个索引拆成多个 shard，可以并行查询，再由协调节点汇总结
果，所以在海量文本场景下性能比传统数据库全文检索更有优势。"
- 什么是倒排索引？
这是必问。
正排：
- 文档 -> 词
倒排：
- 词 -> 出现在哪些文档里
比如：
-
文档1：Java Elasticsearch
-
文档2：Java Kafka
倒排后可能是：
-
Java -> [doc1, doc2]
-
Elasticsearch -> [doc1]
-
Kafka -> [doc2]
你可以答：
"倒排索引本质上是从词项反查文档列表。用户搜一个词时，系统不用扫描所有文档，而是直接
查这个词对应的 posting list，所以查询效率很高。"
- shard 是什么？为什么要分片？
你刚才说的 shared 应该是 shard。
答法：
"Shard 就是分片。因为单机磁盘、内存、CPU 都有限，一个索引的数据量太大时，需要拆成多
个 shard 分布到不同节点上。这样既能横向扩容存储容量，也能让查询并行执行，提高吞吐
量。"
面试官如果继续问"每个 shard 是什么"：
"每个 shard 本质上也是一个独立的 Lucene index。"
这句很关键。
- replica 是什么？为什么需要副本？
答法：
"Replica 是主分片的副本，主要有两个作用。第一是容灾，主分片所在节点挂了，副本可以提
升为新的主分片；第二是提升读性能，因为查询请求可以打到副本分片上做负载分担。"
一句话：
主分片负责写，副本分片负责高可用和读扩展。
- primary shard 和 replica shard 的区别？
高频。
-
primary shard
-
主分片
-
真正负责写入
-
每条文档先写主分片
-
replica shard
-
主分片副本
-
复制主分片数据
-
提供容灾和读扩展
面试话术：
"写请求必须先落主分片，再同步到副本；读请求可以由主分片或副本分片处理。"
- 为什么单节点 ES 经常是 yellow？
很爱问。
答法：
"单节点情况下，主分片可以分配，但副本分片不能和主分片放在同一个节点上，所以副本无法
分配，集群状态通常是 yellow。要变 green，一般可以把副本数设为 0，或者增加节点数。"
- green / yellow / red 分别代表什么？
-
green
-
主分片和副本分片都正常分配
-
yellow
-
主分片正常，副本分片未完全分配
-
red
-
有主分片没分配成功，部分数据不可用
你可以补一句：
"yellow 不一定影响业务可用性，但 red 是高风险状态，因为可能已经有部分数据无法正常检
索。"
- ES 为什么说是近实时，不是实时？
很高频。
答法：
"因为文档写入后，并不是立刻就能被搜索到，要等 refresh 之后才可见。默认 refresh 间隔
通常是 1 秒左右，所以 ES 是 near real-time，不是严格实时。"
一句话：
写成功不代表立刻可搜，要等 refresh。
- refresh / flush / merge 分别是什么？
这是面试很喜欢深挖的点。
refresh
-
把新写入内存缓冲区的数据变成可搜索
-
不一定落盘
-
解决"什么时候能搜到"
flush
-
把内存数据和 translog 更持久化地落到磁盘
-
通常伴随 translog 截断
-
解决"什么时候更安全"
merge
-
合并多个 segment
-
减少 segment 数量
-
提升查询效率，并清理已删除文档
标准答法：
"refresh 解决可搜索性，flush 解决持久化，merge 解决 segment 过多带来的查询和存储问
题。"
- translog 是什么？
答法：
"translog 是事务日志。因为 refresh 只是让数据可搜索，不代表已经稳定持久化，所以 ES
会把写操作先记录到 translog。节点异常恢复时，可以通过 translog 回放最近的写入操作，
减少数据丢失。"
一句话：
translog 是 ES 崩溃恢复的重要保障。
- segment 是什么？
答法：
"Lucene 底层的数据是按 segment 组织的。一个 shard 底层不是一个单一的大文件，而是由
多个不可变的 segment 组成。新数据不断写入时会产生新的 segment，后续再通过 merge 合
并。"
如果被问"为什么不可变"：
"因为不可变 segment 更有利于高并发查询和缓存复用，代价是更新删除会以新增+标记删除的
方式实现。"
- ES 为什么更新和删除成本高一些？
答法：
"因为 Lucene 的 segment 是不可变的，所以 ES 不能直接原地修改文档。更新本质上是写入
新文档，再把旧文档标记删除；删除也是先打删除标记，等后续 merge 再做物理清理。"
这个和你项目里"删除整份文件时按 fileMd5 deleteByQuery"也能联系上。
- keyword 和 text 的区别？
这个你必须会。
-
keyword
-
不分词
-
适合精确匹配、过滤、聚合、排序
-
text
-
分词
-
适合全文检索
对应你项目：
-
fileMd5/userId/orgTag/modelVersion 用 keyword
-
textContent 用 text
标准答法：
"keyword 面向结构化过滤，text 面向全文检索。"
- BM25 是什么？
因为你项目里就用到了。
答法：
"BM25 是 Lucene/ES 默认的相关性评分算法，用来衡量一个文档和查询词的匹配程度。它会综
合考虑词频、逆文档频率以及文档长度归一化，所以比简单 TF-IDF 更适合现代搜索场景。"
在你项目里可以接一句：
"我项目里 BM25 主要用于 textContent 的关键词重排。"
- ES 查询流程是什么？
答法：
"ES 查询一般分两个阶段。第一阶段是 query phase，每个相关 shard 先返回本地 topN；第
二阶段是 fetch phase，协调节点汇总后确定全局 topN，再去对应 shard 取完整文档内容。"
如果面试官追问深分页慢，就接：
"因为每个 shard 都要先准备 from+size 的候选结果，再统一排序，所以深分页成本会很
高。"
- 深分页为什么慢？怎么优化？
答法：
"传统 from + size 深分页会让每个 shard 都保留大量候选结果，内存和排序开销很高。优化
上通常会用 search_after，或者 scroll 处理大批量导出场景，而不是一直翻很深的页码。"
- 你的项目里 ES 为什么适合而不是 MySQL？
这个你一定会被问。
答法：
"因为我的项目本质上是知识库检索，不只是结构化条件查询，还包括中文全文检索、向量语义
召回、BM25 重排和权限过滤。MySQL 更适合事务型结构化数据存储，ES 更适合这类高频全文
搜索和混合检索场景。"
- 你的项目里 ES 和 Lucene 具体怎么体现？
这题很贴项目。
答法：
"我业务代码直接对接的是 Elasticsearch Java Client，没有直接写 Lucene API。但底层全
文检索、倒排索引、BM25 评分这些能力，本质上都来自 Lucene。我的项目更多是通过 ES DSL
去使用 Lucene 能力，比如 textContent 的全文检索、BM25 rescore，以及底层向量检索索引
能力。"
- 你的项目里 shard / replica 怎么讲最稳？
因为你代码里没显式配。
你可以答：
"当前项目里索引主要定义了 mapping，没有在代码层显式设置 number_of_shards 和
number_of_replicas，所以当前更多依赖 ES 默认配置。这个阶段重点是先把混合检索链路跑
通，而不是做大规模集群调优。如果后续数据量继续增长，会结合文档量、节点数和查询吞吐
重新设计 shard 策略。"
这个答法很稳，不会露怯。