Elasticsearch面试八股整理

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