豆包
Elasticsearch 核心高频面试题及精华解答
- Elasticsearch（ES）是什么？和关系型数据库的核心区别？
• ES 是基于 Lucene 的分布式全文搜索引擎，主打海量数据的近实时检索、分析，适用于日志、文档、电商搜索等场景。
• 核心区别：关系型数据库（MySQL）是结构化存储，强事务、强一致性；ES 是非结构化/半结构化存储，弱事务，最终一致性，检索性能远超关系型数据库。
- ES 的核心概念（Index、Type、Document、Field、Mapping）？
• Index：对应 MySQL 的 Database，是文档的集合，具有相同结构的文档归为一个索引。
• Type：Elasticsearch 7.x 及以上已废弃，7.x 前对应 MySQL 的 Table，一个索引下可包含多个 Type（后续版本用单一 Type _doc 替代）。
• Document：对应 MySQL 的 Row，是 ES 中最小的数据单元，以 JSON 格式存储。
• Field：对应 MySQL 的 Column，是文档的属性。
• Mapping：对应 MySQL 的 Schema，定义文档的字段类型、分词器、是否索引等属性。
- ES 的倒排索引原理？
• 倒排索引是 ES 高效检索的核心，与传统正排索引（文档 ID → 内容）相反，结构为 关键词 → 文档 ID 列表。
• 构建过程：对文档内容分词 → 记录每个词出现的文档 ID、位置、频率 → 生成词典 + 倒排表；检索时先查词典找到对应文档 ID，再返回结果。
- ES 的分词器（Analyzer）组成？常用分词器有哪些？
• 分词器由三部分组成：Character Filter（预处理文本，如去除 HTML 标签）→ Tokenizer（切分文本为词元，如按空格、标点切分）→ Token Filter（处理词元，如转小写、停用词过滤、同义词替换）。
• 常用分词器：
◦ Standard Analyzer：ES 默认分词器，按词切分，转小写，适合英文。
◦ IK Analyzer：中文分词器，支持 ik_smart（粗粒度分词）和 ik_max_word（细粒度分词），是中文场景的首选。
◦ Keyword Analyzer：不分词，将整个文本作为一个词元，适合精确匹配（如手机号、ID）。
- ES 的集群架构核心组件？各自作用？
• Node：集群中的单个服务器，分角色：
◦ Master Node：管理集群元数据（索引、分片信息），负责分片分配，保障集群稳定（需高可用，建议部署 3 台）。
◦ Data Node：存储数据分片，执行 CRUD、检索、聚合操作，是集群的“数据载体”。
◦ Ingest Node：预处理数据（如添加字段、转换格式），再写入 Data Node。
◦ Coordinating Node：接收客户端请求，分发到对应节点，汇总结果返回（默认所有节点都是）。
• Shard：分片，解决单节点存储上限问题，分为主分片（Primary Shard） 和副本分片（Replica Shard）。
◦ 主分片：数据的原始分片，一个索引的主分片数创建后不可修改。
◦ 副本分片：主分片的备份，可提升读取性能和容灾能力。
- ES 的分片（Shard）和副本（Replica）的作用？
• 主分片：
-
水平扩展数据存储，突破单节点磁盘/内存限制。
-
并行执行检索、聚合操作，提升查询性能。
• 副本分片：
-
容灾：主分片故障时，副本可升级为主分片。
-
提升读性能：读请求可分发到副本分片，分担主分片压力。
-
ES 的文档写入流程？
-
客户端请求发送到 Coordinating Node。
-
Coordinating Node 根据文档 ID 和路由规则（默认 routing = hash(_id) % 主分片数），计算出目标主分片。
-
将请求转发到对应 Data Node 的主分片，写入数据。
-
主分片写入成功后，同步数据到所有副本分片。
-
所有副本分片写入成功后，返回成功响应给 Coordinating Node，再由其返回给客户端。
-
ES 的文档检索流程？
-
客户端发送检索请求到 Coordinating Node。
-
Coordinating Node 转发请求到所有相关分片（主分片或副本分片），执行查询。
-
各分片返回候选结果（文档 ID + 评分 _score）给 Coordinating Node。
-
Coordinating Node 汇总结果，重新排序（按 _score），然后去对应分片拉取完整文档数据。
-
合并最终结果，返回给客户端。
-
ES 的 refresh、flush、translog 分别是什么？
• refresh：默认每隔 1 秒，将内存中的数据（索引缓冲区）写入文件系统缓存，生成不可搜索的段（Segment），并变为可搜索状态，这是 ES 近实时的核心（不是实时，因为有 1 秒延迟）。
• flush：将文件系统缓存中的段持久化到磁盘，同时清空 translog，默认每隔 30 分钟自动执行，或 translog 达到阈值时触发。
• translog：事务日志，记录所有未持久化到磁盘的操作，防止数据丢失；每次写入文档时，先写 translog，再写索引缓冲区，保障故障时数据可恢复。
- ES 的段（Segment）和提交点（Commit Point）？
• 段：ES 中最小的索引单元，是不可变的 Lucene 索引文件；每次 refresh 生成一个新段，段一旦生成不可修改，删除/更新文档只是标记状态，不会立即删除段。
• 提交点：一个文件，记录了当前所有可搜索的段信息；flush 时会生成新的提交点，并将段写入磁盘。
- ES 的合并（Merge）操作？
• 背景：频繁 refresh 会生成大量小分段，导致文件句柄占用过高、检索性能下降。
• 过程：ES 后台会自动合并小分段为大分段，合并完成后删除旧的小分段和标记删除的文档。
• 注意：合并是 IO 密集型操作，会占用大量磁盘 IO，可能影响检索性能，需合理配置合并策略。
- ES 的相关性评分（_score）原理？
• 核心算法：TF-IDF（词频-逆文档频率） + BM25（ES 5.0 后默认算法，优化了 TF-IDF 的缺陷）。
◦ TF（词频）：关键词在当前文档中出现的频率，频率越高，评分越高。
◦ IDF（逆文档频率）：关键词在所有文档中出现的频率，频率越低，评分越高（越稀有越重要）。
◦ BM25：对 TF 做了饱和度处理，避免词频过高导致评分不合理（如关键词重复 100 次，评分不会无限增长）。
- ES 的查询类型？Query 和 Filter 的区别？
• ES 查询分为查询（Query） 和过滤（Filter） 两类：
◦ Query：计算文档的相关性评分（_score），适用于全文检索等需要排序的场景，性能相对较低。
◦ Filter：不计算评分，只判断文档是否匹配，结果可缓存，适用于精确过滤（如状态、时间范围），性能远高于 Query。
• 示例：bool 查询中，must/should 属于 Query 上下文，filter/must_not 属于 Filter 上下文。
- ES 的复合查询有哪些？常用的是哪个？
• 复合查询：将多个查询条件组合起来，常用的有：
◦ bool 查询：最常用，支持 must（必须满足，算分）、should（可选满足，算分）、filter（必须满足，不算分）、must_not（必须不满足，不算分）。
◦ dis_max 查询：取多个查询条件中评分最高的那个，适用于多字段检索（如标题和内容，取匹配度最高的字段评分）。
◦ function_score 查询：自定义评分规则，如按时间、热度调整评分，适用于“最新优先”“热度优先”的场景。
- ES 的聚合（Aggregation）类型？常用的有哪些？
• 聚合是 ES 的数据分析能力，分为桶聚合和指标聚合两大类：
◦ 桶聚合（Bucket）：按条件分组，生成多个桶，每个桶对应一组数据，如 terms（按字段值分组）、range（按范围分组）、date_histogram（按时间分组）。
◦ 指标聚合（Metric）：对桶内数据计算统计指标，如 avg（平均值）、sum（总和）、max/min（最大/最小值）、cardinality（去重计数）。
• 核心特点：支持嵌套聚合（桶聚合 + 指标聚合），如“按省份分组，计算每个省份的订单平均金额”。
- ES 的分页方式有哪些？各自的优缺点？
• from + size 分页：
◦ 原理：from 是起始位置，size 是每页条数；Coordinating Node 从各分片获取 from + size 条数据，汇总后取 size 条。
◦ 优点：简单易用，适合浅分页（前 10000 条数据）。
◦ 缺点：深分页时，from 越大，各分片返回的数据越多，内存和网络开销大，ES 默认限制 from + size ≤ 10000。
• scroll 分页：
◦ 原理：生成一个快照（scroll_id），记录当前索引的分段信息，后续通过 scroll_id 逐页拉取数据，适合海量数据导出。
◦ 优点：支持深分页，性能稳定。
◦ 缺点：快照是静态的，不支持实时数据；占用资源，需手动释放 scroll_id。
• search_after 分页：
◦ 原理：基于上一页的最后一条数据的排序值作为游标，获取下一页数据，适合实时深分页。
◦ 优点：无分页深度限制，支持实时数据，性能优。
◦ 缺点：只能向后翻页，不能跳页。
- ES 的性能优化手段？
• 写入优化：
-
增大 bulk 批量写入的大小（建议 5-15MB），减少请求次数。
-
降低 refresh_interval（如改为 30s），减少段的生成频率。
-
合理设置分片数，避免分片过多或过少。
• 检索优化：
-
多用 filter 上下文，利用缓存提升性能。
-
避免通配符开头的查询（如 *keyword），会导致全表扫描。
-
合理使用聚合，避免嵌套过深的聚合操作。
• 硬件与配置优化：
-
Data Node 使用 SSD 磁盘，提升 IO 性能。
-
增大 JVM 堆内存（建议不超过 32GB，避免 JVM 禁用压缩指针）。
-
关闭不需要的功能（如 _all 字段、动态 mapping）。
-
ES 的脑裂问题是什么？如何解决？
• 脑裂：集群中 Master Node 网络分区时，出现多个 Master 节点，导致集群分裂为多个子集群，数据写入混乱。
• 解决方法：
-
配置 discovery.zen.minimum_master_nodes（ES 6.x）或 cluster.initial_master_nodes（ES 7.x+），设置为 (主节点数 / 2) + 1（如 3 个主节点设为 2），确保只有足够多的主节点才能选举出 Master。
-
优化网络环境，减少网络分区概率；配置超时时间（discovery.zen.ping_timeout）。
-
ES 的动态映射（Dynamic Mapping）是什么？优缺点？
• 动态映射：ES 自动根据文档字段的值，推断字段类型（如数字→long，字符串→text+keyword），无需手动定义 Mapping。
• 优点：降低使用门槛，快速上手。
• 缺点：推断可能不准确（如手机号被推断为 long，导致检索异常）；后续无法修改字段类型，只能重建索引。
• 建议：生产环境关闭动态映射（dynamic: false），手动定义 Mapping，保障字段类型准确。
- ES 中索引别名（Alias）的作用？
• 索引别名是给一个或多个索引起的“别名”，客户端可通过别名操作索引，核心作用：
-
透明切换索引：如创建 user_v2 索引后，将别名 user 从 user_v1 切换到 user_v2，客户端无感知。
-
索引分组：将多个索引（如 log_202501、log_202502）关联到同一个别名 log_all，实现批量查询。
-
过滤数据：给别名添加过滤条件，实现“虚拟索引”（如只查询北京地区的数据）。
我可以帮你整理ES性能优化的实操案例，需要吗？
元宝
ES 高质量面试题 12 题精要
一 原理深挖
- 倒排索引与 FST 细节
◦ 核心结构：词典 Term Dictionary + 倒排表 Posting List + Term Index；词典按字典序组织，配合 FST（Finite State Transducer） 做前缀压缩与快速定位，查询复杂度近似 O(len(term))。倒排表除 docID 外还存 词频、位置、偏移、payload，用于打分与高亮。
◦ 压缩与加速：Posting List 采用 差值编码 + Frame of Reference（FOR） 按块定长压缩；位图 Roaring Bitmap 加速布尔过滤与交并差；Term Index 用 FST 将词典前缀复用，显著降低内存占用并加速定位。
- 相关性评分与 BM25 要点
◦ ES 7.x 起默认使用 BM25（取代 TF/IDF），核心参数：k1（饱和因子，默认 1.2）、b（长度归一化，默认 0.75）。BM25 更贴近自然语言检索，能抑制长文档优势、提升短文本匹配质量。
- DocValues、Fielddata 与 norms
◦ DocValues：列式正排结构，支撑 排序/聚合/脚本，默认对所有非 text 字段开启，常驻 堆外/OS 页缓存，高基数聚合性能稳定。
◦ Fielddata：text 字段的聚合/排序需加载到堆内存，易引发 OOM，生产上建议用 keyword 多字段替代。
◦ norms：存储字段长度与词频归一化因子，影响打分；对不需评分的字段可关闭以省内存（如 "norms": false）。
- 近实时 NRT、refresh、flush、translog 边界
◦ refresh：默认 1s 将内存 buffer 生成新段进入 Filesystem Cache，立即可搜；可调大（批量导入）或设为 -1（暂停）再恢复。
◦ translog：每次写入同步落盘，提供近实时持久化与故障恢复；默认 5s fsync，宕机最多丢约 5s 数据。
◦ flush：提交点推进并清空 translog，默认 30min 或 translog 达 512MB 触发；段合并在后台持续进行。
二 写入与检索机制
- 文档写入全流程与路由分片
◦ 协调节点基于 _routing（默认 _id） 计算目标分片：shard = hash(routing) % num_primary_shards；主分片写入成功后并行复制至副本，多数副本成功才向客户端确认。
◦ 近实时由 refresh 提供；持久化由 flush/translog 保障；段不可变，更新=写入新段并标记旧段删除，合并时物理清理。
- 更新与删除的底层实现
◦ Lucene 段不可变：删除在 .del 文件标记；更新写入新文档并标记旧文档删除；段合并时清理被标记文档，避免频繁小段导致的性能退化。
- 搜索两阶段与深分页治理
◦ Query Then Fetch：协调节点广播查询到相关分片，各分片本地执行并维护 from+size 优先队列，回传 doc_id/排序值；协调节点归并全局排序后进入 Fetch 阶段按 doc_id 拉取源数据。
◦ 深分页代价高：避免 from/size 过大；大数据导出用 scroll；实时翻页用 search_after 基于上一页排序值继续检索。
- 并发控制与版本机制
◦ 乐观并发：使用 _version / if_seq_no + if_primary_term 实现 CAS 更新；冲突时返回 409 Conflict，业务层重试或合并策略。
◦ 一致性：写一致性可用 one/all/quorum（默认 quorum）；读一致性可用 replication=sync 或 _preference=primary 读主分片获取最新版本。
三 集群与数据建模
- Master 选举与脑裂防护
◦ 仅 node.master: true 的候选节点参与；基于 ZenDiscovery 的 Ping/Unicast 发现；投票达阈值（N/2+1）且节点自选举成功即为主。历史版本通过 discovery.zen.minimum_master_nodes 防脑裂；现代版本使用 cluster.initial_master_nodes 引导选举并配合投票配置降低风险。
- 分片与副本设计量化方法
◦ 原则：单个分片承载 10–50GB 数据更利于段合并与恢复；副本提高可用与查询吞吐，但增加写入放大与存储开销。
◦ 估算公式：所需主分片数 ≈ ceil(总数据量 / 目标分片容量)；再结合节点数、并发查询与故障域规划副本数（常见 1–2）。冷热分离与 ILM 管理热/温/冷生命周期。
- 字段类型与多字段设计
◦ text vs keyword：text 会分词，适合全文检索；keyword 不分词，适合精确匹配、聚合与排序。字符串字段常用 multi-fields 同时保留 text（检索）与 keyword（聚合/排序）。
◦ 细节：keyword 默认最长 32766 个 UTF-8 字符，可用 ignore_above 截断超长部分使其不被索引；term 查询不做分析，必须与索引词项精确一致。
- 路由、父子/嵌套与数据倾斜
◦ 自定义 _routing 将相关文档路由到相同分片，提升 父子/嵌套 与聚合性能；路由键选择不当会导致 热点分片 与数据倾斜，需结合业务键与分桶打散。
四 工程实践与可观测性
• 索引与查询：使用 索引模板 + rollover 控制单索引体量；导入期可设 number_of_replicas=0、refresh_interval=-1 提升吞吐，完成后恢复；查询优先 filter 复用缓存，避免 wildcard/大量 terms，先按时间/路由缩小数据集再检索。
• 系统与 GC：关闭 swap；堆内存设为 Min(节点内存/2, 32GB)；提高 文件句柄数；合理设置线程池与队列；磁盘优先 SSD/RAID10；监控 segment memory 与各类 circuit breaker，避免返回超大结果集与聚合。