【ES】[教程]----第七章：Elasticsearch 面试题

Elasticsearch 面试题

7.1 为什么要使用Elasticsearch?

传统mysql中，过百万的数据做模糊查询效率很低，es转为文本索引而生！

7.2 Elasticsearch的master选举流程？

候选节点（node.master: true）在 master 缺失时触发选举。

节点通过 Ping 交换信息，依据 “集群状态版本更高(整个集群的状态版本信息最高，拥有最新地图)（优先）、节点 ID 更小（次之）” 的规则竞选。

需获得超过 “过半”（(候选节点数 / 2)+1）的投票（含自身）才能当选。

当选后同步集群状态，完成选举。

7.3 Elasticsearch集群脑裂问题？

原因：

1. 网络问题：节点间通信中断，各部分以为对方挂了，各自选主
2. 节点负载过高：主节点因繁忙没及时响应，被误认为故障
3. 配置不当：最小主节点数设置不合理

解决方案：

1. 合理设置discovery.zen.minimum_master_nodes：值为「半数以上」，确保少数派无法选主
2. 优化网络：用稳定网络，增加超时时间（discovery.zen.ping_timeout）
3. 控制节点负载：避免主节点过载，可分离主节点和数据节点

7.4 Elasticsearch索引文档的流程？

1. 客户端发送文档到任意节点（协调节点）
2. 协调节点计算文档属于哪个分片（根据 ID 哈希）
3. 转发请求到该分片的主节点
4. 主节点写入文档并同步给副本节点
5. 所有副本确认后，主节点返回成功给客户端

简单说：客户端→协调节点→主分片→副本分片→确认成功

7.5 Elasticsearch更新和删除文档的流程？

更新流程：
a) 客户端发更新请求到任意节点（协调节点）
b) 协调节点找到文档所在的主分片
c) 主分片先标记旧文档为删除状态，再创建新文档（ES 不直接修改原文档）
d) 同步新文档到副本分片
e) 所有副本确认后，返回成功

删除流程：
a) 客户端发删除请求到协调节点
b) 协调节点找到文档所在的主分片
c) 主分片标记文档为删除状态（不直接物理删除，后续由 ES 定期清理）
d) 同步删除标记到副本分片
e) 所有副本确认后，返回成功

简单说：都是先找主分片，做标记（更新是标记旧的 + 建新的，删除是只标记），同步副本后完事。

7.6 Elasticsearch搜索的流程？

客户端发搜索请求到任意节点（协调节点）

协调节点确定需要查询的所有分片（主或副本均可）

并行向这些分片发送查询请求，获取候选结果（limit100 ）

协调节点汇总、排序所有结果，返回给客户端（3个节点各返回100条，再limit100返回 ）

7.7 Elasticsearch 在部署时，对 Linux 的设置有哪些优化方法？

硬件配置：

• 内存优先选 16-64GB（8GB 以下性能会受影响），分配给 ES 的堆内存不超过物理内存一半，且上限 32GB（剩余内存留给 Lucene 缓存文件，提升性能）。
• CPU 核心数比主频更重要，多核心支持更高并发。
• 优先用 SSD，读写性能远超机械硬盘，尤其提升查询和索引速度。

集群部署：

• 避免跨数据中心或地理距离部署，网络延迟会严重影响集群协同。
• 用单播发现节点（默认），防止无关节点误加入；不要用组播。

系统设置：

• 禁用内存交换（swap），否则会导致操作延迟从微秒级飙升到毫秒级，严重拖慢性能。
• 调大文件描述符限制（如设为 64000），因为 Lucene 和网络通信会用到大量文件和套接字。

JVM 与配置：

• 确保应用与 ES 用相同 JVM 版本，避免序列化问题。
• 不随意修改默认垃圾回收器（CMS）和线程池配置，保持官方优化的平衡。
• 集群重启时，通过 gateway 相关参数（如recover_after_nodes）控制分片恢复节奏，缩短启动时间。

索引方面：

1. 批量导入：用批量请求提交数据，单次批量大小控制在 5–15MB 起步（可根据实际调整），减少请求开销。
2. 硬件加速：用 SSD 存储，显著提升索引读写速度（机械盘瓶颈明显）。
3. 优化段合并：
   • SSD 可将合并速率从默认 20MB/s 提高到 100–200MB/s；纯批量导入时可关闭限流（牺牲搜索性能换写入速度）。
   • 调大事务日志刷新阈值（如从 512MB 到 1GB），积累更大段再刷新，减少合并次数。
4. 放宽实时性：若不需近实时搜索，将索引刷新间隔（index.refresh_interval）调至 30 秒（默认 1 秒），减少刷新开销。
5. 临时关闭副本：批量导入时先设副本数为 0（index.number_of_replicas: 0），完成后再恢复，避免副本同步消耗资源。

7.8 GC方面，在使用Elasticsearch时要注意什么？

1. 倒排词典索引常驻内存，不会被回收，要盯着数据节点上这部分内存的增长
2. 各种缓存（字段、过滤、索引等）要设合适大小，确保满负荷时还有内存给其他任务，别用清缓存自欺欺人
3. 别返回太多搜索和聚合结果，大量取数用 scan & scroll 接口
4. 超大规模集群可拆分，避免集群统计信息占用内存过多
5. 内存够不够，得结合实际场景持续监控

7.9 在并发情况下，Elasticsearch如果保证读写一致？

乐观锁控版本冲突通过文档版本号控制，新版本不会办法覆盖旧版本，冲突由应用层处理（比如重试或提示），避免并发写入互相覆盖。

写操作的一致性保障默认要求 “大多数分片可用”（quorum）才允许写入，确保集群多数节点能接收数据。即使偶发副本同步失败，也会标记故障分片并在新节点重建，最终保证数据一致。

读操作的实时性控制

• 默认同步读写（replication=sync），需主分片和副本都写完才返回，读时能拿到最新数据。
• 若用异步写入（async），可指定优先读主分片（_preference=primary），确保读到最新版本。

核心逻辑是：用版本号防冲突，靠分片多数派保写入可靠，通过读写策略平衡实时性与性能，适合分布式场景下的并发控制。

7.11 如何监控 Elasticsearch 集群状态？

通过 Kibana 监控 Elasticsearch。你可以实时查看你的集群健康状态和性能，也可以分析过去的集群、索引和节点指标

7.12 Elasticsearch 是否了解字典树？

简单说，字典树就像一本按前缀排序的字典，查词时顺着共同前缀快速定位，这和 Elasticsearch 快速处理关键词、前缀搜索的需求高度契合。

7.13 Elasticsearch中的集群、节点、索引、文档、类型是什么？

• 集群：由多台服务器（节点）组成的整体，共同存储数据并提供联合查询能力，用唯一名称标识（默认 elasticsearch）。
• 节点：集群中的单台服务器，负责存储数据和参与索引、搜索工作。
• 索引：类似数据库（如 MySQL 的 DB），是存储相关数据的逻辑容器，对应多个数据分片。
• 文档：类似数据库表中的一行记录，是最小数据单元，可灵活定义字段（但同字段建议类型一致）。
• 类型：索引内的逻辑分类（类似表），但在新版本 ES 中已被弱化，逐渐被移除，建议避免过度使用。

7.14 Elasticsearch中的倒排索引是什么？

苹果→[文档 1, 文档 2]

手机→[文档 1]

搜索 “苹果” 时，直接通过倒排表定位到相关文档，避免逐文档扫描，大幅提升效率。

不是传统的:文章里有哪些关键字，而是 关键字关联了哪些文章！