Elasticsearch面试题总结

一. 概述

1. 为什么要使用 Elasticsearch？

• 在网络应用中，搜索功能十分常见。而在查询海量数据时， 如果使用传统的关系型数据库进行搜索，往往需要采用模糊查询。而模糊查询会导致查询引擎放弃索引，导致系统查询数据时都是全表扫描，在百万级别的数据库中，查询效率是非常低下的，
• 而Elasticsearch是专业的全文搜索引擎，使用 ES可以大大提升搜索的效率。通过将经常查询的系统功能的某些字段，比如说电商系统的商品表中商品名，描述、价格还有 id 这些字段我们放入 ES 索引库里，可以大大提高查询速度。

二. 核心原理

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

• 集群是一个或多个节点（服务器）的集合，它们共同保存您的整个数据，并提供跨所有节点的联合索引和搜索功能。
• 节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。
• 索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间，映射到一个或多个主分片，并且可以有零个或多个副本分片。
• 文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构(字段)，但是对于通用字段应该具有相同的数据类型。
• 类型是索引的逻辑类别/分区，其语义完全取决于用户。（Elasticsearch7已删除这一概念）

2. Elasticsearch 中的倒排索引是什么？

• 倒排索引是搜索引擎的核心。搜索引擎的主要目标是在查找发生搜索条件的文档时提供快速搜索。ES中的倒排索引其实就是 lucene 的倒排索引，
• 区别于传统的正向索引， 倒排索引会再存储数据时将关键词和数据进行关联，保存到倒排表中，然后查询时，将查询内容进行分词后在倒排表中进行查询，最后匹配数据即可。

3. Elasticsearch 文档写入流程

1. 协调节点收到文档后通过路由计算找到合适的分片，并向目标分片发送写请求
2. 当分片所在的节点接收到来自协调节点的请求后，会将请求写入到 Memory Buffer，然后定时（默认是每隔 1 秒）写入到 Filesystem Cache，这个从 Memory Buffer 到 Filesystem Cache 的过程就叫做 refresh；（写入到Filesystemcache后即可被检索到）
3. 在某些情况下，存在 Momery Buffer 和 Filesystem Cache 的数据可能会丢失， ES 是通过 translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到 translog 中，当 Filesystemcache 中的数据写入到磁盘中时，才会清除掉，这个过程叫做 flush；
4. 在 flush 过程中，内存中的缓冲将被清除，内容被写入一个新段，段的 fsync 将创建一个新的提交点，并将内容刷新到磁盘，旧的 translog 将被删除并开始一个新的 translog。
5. flush 触发的时机是定时触发（默认 30 分钟）或者 translog 变得太大（默认为 512M）时；

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

• 删除和更新也都是写操作，但是 Elasticsearch 中的段是不可变的，因此不能被删除或者改动以展示其变更；
• 磁盘上的每个段都有一个相应的.del 文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del 文件中被标记为删除的文档将不会被写入新段。
• 在新的文档被创建时， Elasticsearch 会为该文档指定一个版本号，当执行更新时，新版本的文档被索引到一个新段。

5. Elasticsearch 搜索的流程？

• 搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch：

1. 在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。 PS：在搜索的时候是会查询Filesystem Cache 的，但是有部分数据还在 Memory Buffer，所以搜索是近实时的。
2. 每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。
3. 接下来就是取回阶段， **协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。**每个分片加载并丰富文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。

• Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时候可能不够准确， DFS Query Then Fetch 增加了一个预查询的处理，询问 Term 和 Document frequency，这个评分更准确，但是性能会变差。

三. 集群

1. Elasticsearch 的 master 选举流程？master节点的职责？

• 对所有可以成为master的节点（node master: true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
• 如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。
• master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理。

2. Elasticsearch 集群脑裂问题？

“脑裂”问题可能的成因：

• 网络问题：集群间的网络延迟导致一些节点访问不到master, 认为master 挂掉了从而选举出新的master,并对master上的分片和副本标红，分配新的主分片。
• 节点负载：主节点的角色既为master又为data,访问量较大时可能会导致ES停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。
• 内存回收：data 节点上的ES进程占用的内存较大，引发JVM的大规模内存回收，造成ES进程失去响应。

脑裂问题解决方案：

• 选举触发：调整discovery.zen.minimum. _master_ nodes参数（默认为1），该参数是用于控制选举行为发生的最小集群主节点数量。当备选主节点的个數大于等于该参数的值，且备选主节点中有该参数个节点认为主节点挂了，进行选举。官方建议为(n / 2) +1（超过半数节点投票才能成为master), n为主节点个数（即有资格成为主节点的节点个数）。
• 减少误判：调整discovery.zen ping_ timeout 节点状态的响应时间，默认为3s，可以适当调大，如果master在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如6s，discovery.zen.ping_timeout:6），可适当减少误判。
• 角色分离：即master节点与data节点分离，限制角色
  主节点配置为：node master: true，node data: false
  从节点配置为：node master: false，node data: true

3. 如何监控 Elasticsearch 集群状态？

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

四. 优化

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

• 倒排词典的索引需要常驻内存，无法 GC，需要监控 data node 上 segment memory 增长趋势。
• 各类缓存， field cache, filter cache, indexing cache, bulk queue 等等，要设置合理的大小，并且要应该根据最坏的情况来看 heap 是否够用。
• 避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用 scan & scroll api 来实现。
• cluster stats 驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过 tribe node 连接。

参考文章：https://www.bilibili.com/video/BV1hh411D7sb?p=62&spm_id_from=pageDriver