本文共 3139 字，大约阅读时间需要 10 分钟。
Elasticsearch面试题解析与技术要点
为什么要使用Elasticsearch？
随着企业数据的快速增长和业务扩展，传统的关系型数据库在处理大量数据时会面临效率低下的问题。特别是在需要频繁进行模糊查询的情况下，索引可能被忽略，forcing queries to perform full table scans，导致在大型数据库中效率极低。Elasticsearch通过构建全文索引，优雅地解决了这一问题。我们可以将常用查询字段（如电商系统中商品的名称、描述、价格和ID等）存储到Elasticsearch的索引库中，从而大幅提升查询速度。
Elasticsearch主节点选举流程？
Elasticsearch的主节点选举由ZenDiscovery模块负责，主要包括Ping和Unicast两个模块。具体流程如下：
Elasticsearch会对所有可以作为主节点的节点（node.master: true）进行排序。每个节点会将其已知的节点列表排序，并选出第一个节点作为潜在的主节点。 如果某个节点接收到足够的票数（达到n/2+1，其中n为可选主节点数量），并且该节点也选举自己，那么这个节点即为新的主节点。 主节点负责集群管理，包括节点和索引的操作，不直接管理文档级别内容。 data节点可以关闭HTTP功能。 如果出现脑裂问题，可能的原因包括网络延迟、节点负载过高和内存回收压力过大。解决方案包括适当配置的ping_timeout、minimum_master_nodes以及将主节点和数据节点分离，以避免误判和性能问题。
Elasticsearch集群脑裂问题？
成因：
- 网络问题：集群间的延迟可能导致某些节点无法访问主节点，从而触发选举新的主节点。
- 节点负载：主节点承担大量请求，可能无法及时响应其他节点，导致误判。
- 内存回收：data节点上的ES进程占用内存过大，触发大规模内存释放，造成服务失效。
解决方案：
- 减少误判：通过 Tune discovery.zen.ping_timeout（如从3s调整为6s）减少误判。
- 选举触发：设置 discovery.zen.minimum_master_nodes 为1，确保选举发生。
- 角色分离：配置 master 和 data 节点，避免单节点承担过多角色。
Elasticsearch索引文档流程？
Elasticsearch的文档生命周期管理分为以下几个关键环节：
初始索引：
- 指定文档ID或通过路由（如hash(document_id) % num_of_primary_shards）分发到不同的分片。
- 文档内容首先写入Memory Buffer，并定期（如每1秒）刷新到Filesystem Cache。
- 若刷新触发（如每30分钟或translog达到512MB），则内容写入磁盘，创建新段，并刷新到磁盘。
文档删除：
- 文档不会真正被删除，而是标记为删除（通过.del文件）。
- 删除操作不会立即生效，直到段合并或新文档添加时，该文档会被排除在外。
文档更新：
- 新文档会生成新的版本号，旧版本文档会在.del文件中被标记为删除。
- 旧文档仍能查询，但会在结果中被过滤。
Elasticsearch搜索流程？
Elasticsearch搜索分为两个阶段：
查询阶段（Query Then Fetch）：
- 查询广播到所有分片，分片本地执行，利用Filesystem Cache。
- 协调节点合并结果，生成全局排序后的优先队列。
取回阶段（Fetch）：
- 协调节点确定需要取回的文档，向相关分片提交GET请求。
- 文档被加载并丰富，返回给协调节点，最终返回给客户端。
DFS Query Then Fetch方法结合了单副本路由和预查询，提升文档相关性评分，但可能增加性能开销。
Elasticsearch部署优化？
在Linux环境下，优化Elasticsearch表现：
内存管理：
- 建议分配64GB以上内存，尽量避免低于8GB。
- JVM堆内存设置为局部匹配，使用相同的版本和配置。
存储设备：
- 适用SSD提升性能。
- 避免跨数据中心部署，保持集群在近地理位置。
GC优化：
- 避免不必要的缓存清除，定期监控内存使用趋势。
- 设置合理的垃圾回收参数，避免频繁full GC。
网络优化：
- 增加文件描述符数目（如64000），减少socket资源冲突。-icontrol�自适应参数设置，避免集群跨地理位置。
性能调优：
- 通过index.refresh_interval（如30s）延迟刷新，提升性能。
- 关闭副本索引（如设置index.number_of_replicas: 0）在批量导入时。
监控工具：
- 配置Logstash、Graylog和Kibana进行日志和性能监控。
- 使用Elasticsearch自己提供的监控插件进行集群状态跟踪。
Elasticsearch GC注意事项？
Elasticsearch的内存管理与垃圾回收机制需要特别注意：
倒排词典索引：
- 常驻内存，无法GC，需监控segment memory增长。
缓存管理：
- 设置合理的缓存大小，结合最坏场景判断内存需求。
- 避免主动清理缓存，采用更智能的内存管理策略。
避免高并发查询：
- 避免返回大量结果集的搜索和聚合，采用scan & scroll进行分批处理。
集群GC问题：
- 大规模集群可考虑分拆为多个集群，通过tribe node连接，避免单点故障。
Elasticsearch聚合大数据量？
Elasticsearch采用cardinality度量近似聚合，基于HLL算法实现。该度量可配置精度，灵活应对小数据集或大规模唯一值问题。
Elasticsearch一致性问题？
Elasticsearch支持通过版本号和replication设置实现一致性：
乐观并发：
写操作一致性：
- 默认为quorum模式，写入必须在大多数可用分片完成后才能成功。
- 失败的副本会触发重建，确保数据一致性。
读操作一致性：
- 设置replication为sync，确保查询完成后返回最新版本。
- 通过设置/search参数_preference: primary，强制只从主分片查询。
Elasticsearch集群状态监控？
推荐使用：
elasticsearch-head插件：实时监控集群健康和性能指标。 Kibana：分析历史数据和性能趋势。 Prometheus：结合Grafana进行扩展监控。 ELK栈：集成全链路监控和日志分析。
Elasticsearch与字典树？
字典树（Trie）作为Elasticsearch的核心组件之一，用于提升查询效率：
结构特点：
- 每个节点仅包含一个字符。
- 从根节点到某节点的路径即为对应的字符串。
- 子节点字符互不相同。
应用场景：
- 文本词频统计。
- 实时参数查询优化。
- 保存大量串结构数据。
Elasticsearch基础概念？
回答关键概念：
集群：
节点：
索引：
- 类似数据库的“数据库”，定义多种类型，映射到主分片和副本分片。
文档：
类型：
Elasticsearch倒排索引？
倒排索引是Elasticsearch的核心，用于快速定位相关文档：
- 倒排索引关联关键词和文档，存储在倒排表中。
- 查询时，将搜索内容分词，通过倒排表查找相关文档。
- 与正向索引配合使用，实现快速的高效搜索。
转载地址：http://leeyk.baihongyu.com/