文章目录
- Elasticsearch 面试题
- 7.1 为什么要使用Elasticsearch?
- 7.2 Elasticsearch的master选举流程？
- 7.3 Elasticsearch集群脑裂问题？
- 7.4 Elasticsearch索引文档的流程？
- 7.5 Elasticsearch更新和删除文档的流程？
- 7.6 Elasticsearch搜索的流程？
- 7.7 Elasticsearch 在部署时，对 Linux 的设置有哪些优化方法？
- 7.8 GC方面，在使用Elasticsearch时要注意什么？
- 7.9 在并发情况下，Elasticsearch如果保证读写一致？
- 7.11 如何监控 Elasticsearch 集群状态？
- 7.12 Elasticsearch 是否了解字典树？
- 7.13 Elasticsearch中的集群、节点、索引、文档、类型是什么？
- 7.14 Elasticsearch中的倒排索引是什么？
Elasticsearch 面试题
7.1 为什么要使用Elasticsearch?
传统mysql中，过百万的数据做模糊查询效率很低，es转为文本索引而生！
7.2 Elasticsearch的master选举流程？
候选节点（node.master: true）在 master 缺失时触发选举。
节点通过 Ping 交换信息，依据 “集群状态版本更高(整个集群的状态版本信息最高，拥有最新地图)（优先）、节点 ID 更小（次之）” 的规则竞选。
需获得超过 “过半”（(候选节点数 / 2)+1）的投票（含自身）才能当选。
当选后同步集群状态，完成选举。
7.3 Elasticsearch集群脑裂问题？
原因：
- 网络问题：节点间通信中断，各部分以为对方挂了，各自选主
- 节点负载过高：主节点因繁忙没及时响应，被误认为故障
- 配置不当：最小主节点数设置不合理
解决方案：
- 合理设置
discovery.zen.minimum_master_nodes：值为「半数以上」，确保少数派无法选主 - 优化网络：用稳定网络，增加超时时间（
discovery.zen.ping_timeout） - 控制节点负载：避免主节点过载，可分离主节点和数据节点
7.4 Elasticsearch索引文档的流程？
- 客户端发送文档到任意节点（协调节点）
- 协调节点计算文档属于哪个分片（根据 ID 哈希）
- 转发请求到该分片的主节点
- 主节点写入文档并同步给副本节点
- 所有副本确认后，主节点返回成功给客户端
简单说：客户端→协调节点→主分片→副本分片→确认成功
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）控制分片恢复节奏，缩短启动时间。
索引方面：
- 批量导入：用批量请求提交数据，单次批量大小控制在 5–15MB 起步（可根据实际调整），减少请求开销。
- 硬件加速：用 SSD 存储，显著提升索引读写速度（机械盘瓶颈明显）。
- 优化段合并：
- SSD 可将合并速率从默认 20MB/s 提高到 100–200MB/s；纯批量导入时可关闭限流（牺牲搜索性能换写入速度）。
- 调大事务日志刷新阈值（如从 512MB 到 1GB），积累更大段再刷新，减少合并次数。
- 放宽实时性：若不需近实时搜索，将索引刷新间隔（
index.refresh_interval）调至 30 秒（默认 1 秒），减少刷新开销。 - 临时关闭副本：批量导入时先设副本数为 0（
index.number_of_replicas: 0），完成后再恢复，避免副本同步消耗资源。
7.8 GC方面，在使用Elasticsearch时要注意什么？
- 倒排词典索引常驻内存，不会被回收，要盯着数据节点上这部分内存的增长
- 各种缓存（字段、过滤、索引等）要设合适大小，确保满负荷时还有内存给其他任务，别用清缓存自欺欺人
- 别返回太多搜索和聚合结果，大量取数用 scan & scroll 接口
- 超大规模集群可拆分，避免集群统计信息占用内存过多
- 内存够不够，得结合实际场景持续监控
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]
搜索 “苹果” 时，直接通过倒排表定位到相关文档，避免逐文档扫描，大幅提升效率。
不是传统的:文章里有哪些关键字，而是 关键字关联了哪些文章！
