16. Elasticsearch面试题汇总

Java全栈面试题汇总目录-CSDN博客

1. 什么是Elasticsearch?

Elasticsearch是一个基于Lucene的搜索引擎。它提供了具有HTTP Web界面和无架构JSON文档的分布式，多租户能力的全文搜索引擎。

Elasticsearch是用Java开发的，根据Apache许可条款作为开源发布。

2. 为什么要使用Elasticsearch?

系统中的数据，随着业务的发展，时间的推移，将会非常多，而业务中往往采用模糊查询进行数据的搜索，而模糊查询会导致查询引擎放弃索引，导致系统查询数据时都是全表扫描，在百万级别的数据库中，查询效率是非常低下的，而我们使用ES做一个全文索引，将经常查询的系统功能的某些字段，比如说电商系统的商品表中商品名，描述、价格还有id这些字段我们放入ES索引库里，可以提高查询速度。

3. ES中的倒排索引是什么？

传统的检索方式是通过文章，逐个遍历找到对应关键词的位置。

倒排索引，是通过分词策略，形成了词和文章的映射关系表，也称倒排表，这种词典+映射表即为倒排索引。

其中词典中存储词元，倒排表中存储该词元在哪些文中出现的位置。

有了倒排索引，就能实现O(1)时间复杂度的效率检索文章了，极大的提高了检索效率。

4. ES是如何实现master选举的?

前置条件：

1. 只有是候选主节点（master：true）的节点才能成为主节点。
2. 最小主节点数（min_master_nodes）的目的是防止脑裂。

Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）这两部分；

获取主节点的核心入口为findMaster，选择主节点成功返回对应Master，否则返回null。

选举流程大致描述如下：

1. 确认候选主节点数达标，Elasticsearch.yml设置的值discovery.zen.minimum_master_nodes;
2. 对所有候选主节点根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
3. 如果对某个节点的投票数达到一定的值（候选主节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。

补充：

• 这里的id为string类型。
• master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。

5. 如何解决ES集群的脑裂问题?

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

网络问题：集群间的网络延迟导致一些节点访问不到master，认为master挂掉了从而选举出新的master，并对master上的分片和副本标红，分配新的主分片

节点负载：主节点的角色既为master又为data，访问量较大时可能会导致ES停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。

内存回收：data节点上的ES进程占用的内存较大，引发JVM的大规模内存回收，造成ES进程失去响应。

选举问题：比如Elasticsearch集群中的节点（共20个），其中的10个选了一个master，另外10个选了另一个master。

脑裂问题解决方案：

减少误判：discovery.zen.ping_timeout节点状态的响应时间，默认为3s，可以适当调大，如果master在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如6s，discovery.zen.ping_timeout:6），可适当减少误判。

选举触发：discovery.zen.minimum_master_nodes:1

该参数是用于控制选举行为发生的最小集群主节点数量。当备选主节点的个数大于等于该参数的值，且备选主节点中有该参数个节点认为主节点挂了，进行选举。官方建议为（n/2）+1，n为主节点个数（即有资格成为主节点的节点个数）

角色分离：即master节点与data节点分离，限制角色主节点配置为：node.master: true node.data: false，从节点配置为：node.master: false node.data: true

6. 详细描述一下ES索引文档的过程？

这里的索引文档应该理解为文档写入ES，创建索引的过程。

1. 客户端向集群某节点写入数据，发送请求（如果没有指定路由/协调节点，请求的节点扮演协调节点的角色）

2. 协调节点接受到请求后，默认使用文档ID参与计算（也支持通过routing），得到该文档属于哪个分片。随后请求会被转到另外的节点

# 路由算法：根据文档id或路由计算目标的分片id
shard = hash(document_id) % (num_of_primary_shards)

3. 当分片所在的节点接收到来自协调节点的请求后，会将请求写入到Memory Buffer，然后定时（默认是每隔1秒）写入到Filesystem Cache，这个从Memory Buffer到Filesystem Cache的过程就叫做refresh

4. 当然在某些情况下，存在Memory Buffer和Filesystem Cache的数据可能会丢失，ES是通过translog的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到translog中，当Filesystem cache中的数据写入到磁盘中时，才会清除掉，这个过程叫做flush

5. 在flush过程中，内存中的缓冲将被清除，内容被写入一个新段，段的fsync将创建一个新的提交点，并将内容刷新到磁盘，旧的translog将被删除并开始一个新的translog

6. flush触发的时机是定时触发（默认30分钟）或者translog变得太大（默认为512M）时

补充：关于Lucene的Segment

• Lucene索引是由多个段组成，段本身是一个功能齐全的倒排索引
• 段是不可变的，允许Lucene将新的文档增量地添加到索引中，而不用从头重建索引
• 对于每一个搜索请求而言，索引中的所有段都会被搜索，并且每个段会消耗CPU的时钟周、文件句柄和内存。这意味着段的数量越多，搜索性能会越低
• 为了解决这个问题，Elasticsearch会合并小段到一个较大的段，提交新的合并段到磁盘，并删除那些旧的小段（段合并）

7. 详细描述一下ES更新和删除文档的过程？

删除和更新也都是写操作，但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更。

磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del文件中被标记为删除的文档将不会被写入新段。

在新的文档被创建时，Elasticsearch会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。

8. 详细描述一下ES搜索的过程？

搜索被执行成一个两阶段过程，即Query Then Fetch；

Query阶段：

查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。每个分片在本地执行搜索并构建一个匹配文档的大小为from + size的优先队列。PS：在搜索的时候是会查询Filesystem Cache的，但是有部分数据还在Memory Buffer，所以搜索是近实时的。

每个分片返回各自优先队列中所有文档的ID和排序值给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。

Fetch阶段：

协调节点辨别出哪些文档需要被取回并向相关的分片提交多个GET请求。每个分片加载并丰富文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。

9. 并发情况下，ES如何保证读写一致？

可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；

另外对于写操作，一致性级别支持quorum/one/all，默认为quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。

对于读操作，可以设置replication为sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置replication为async时，也可以通过设置搜索请求参数preference为primary来查询主分片，确保文档是最新版本。

10. ES对于大数据量（上亿量级）的聚合如何实现？

Elasticsearch提供的首个近似聚合是cardinality度量。它提供一个字段的基数，即该字段的distinct或者unique值的数目。它是基于HLL算法的。HLL会先对我们的输入作哈希运算，然后根据哈希运算的结果中的bits做概率估算从而得到基数。其特点是：可配置的精度，用来控制内存的使用（更精确＝更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量。无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关。

11. 对于GC方面，在使用ES时要注意什么？

1. 倒排词典的索引需要常驻内存，无法GC，需要监控data node上segment memory增长趋势
2. 各类缓存，field cache, filter cache, indexing cache, bulk queue等等，要设置合理的大小，并且要应该根据最坏的情况来看heap是否够用，也就是各类缓存全部占满的时候，还有heap空间可以分配给其他任务吗？避免采用clear cache等“自欺欺人”的方式来释放内存
3. 避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用scan & scroll API来实现
4. cluster stats驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过tribe node连接
5. 想知道heap够不够，必须结合实际应用场景，并对集群的heap使用情况做持续的监控

12. 说说你们公司ES的集群架构，索引数据大小，分片有多少，以及一些调优手段？

部署层面：

1. 最好是64GB内存的物理机器，但实际上32GB和16GB机器用的比较多，但绝对不能少于8G，除非数据量特别少，这点需要和客户方面沟通并合理说服对方
2. 多个内核提供的额外并发远胜过稍微快一点点的时钟频率
3. 尽量使用SSD，因为查询和索引性能将会得到显著提升
4. 避免集群跨越大的地理距离，一般一个集群的所有节点位于一个数据中心中
5. 设置堆内存：节点内存/2，不要超过32GB。一般来说设置export ES_HEAP_SIZE = 32g环境变量，比直接写-Xmx32g -Xms32g更好一点
6. 关闭缓存swap。内存交换到磁盘对服务器性能来说是致命的。如果内存交换到磁盘上，一个100微秒的操作可能变成10毫秒。再想想那么多10微秒的操作时延累加起来。不难看出swapping对于性能是多么可怕
7. 增加文件描述符，设置一个很大的值，如65535。Lucene使用了大量的文件，同时，Elasticsearch在节点和HTTP客户端之间进行通信也使用了大量的套接字。所有这一切都需要足够的文件描述符
8. 不要随意修改垃圾回收器（CMS）和各个线程池的大小
9. 通过设置gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time可以在集群重启的时候避免过多的分片交换，这可能会让数据恢复从数个小时缩短为几秒钟

索引层面：

1. 使用批量请求并调整其大小：每次批量数据5–15MB大是个不错的起始点
2. 段合并：Elasticsearch默认值是20MB/s，对机械磁盘应该是个不错的设置。如果你用的是SSD，可以考虑提高到100-200MB/s。如果你在做批量导入，完全不在意搜索，你可以彻底关掉合并限流。另外还可以增加index.translog.flush_threshold_size设置，从默认的512MB到更大一些的值，比如1GB，这可以在一次清空触发的时候在事务日志里积累出更大的段
3. 如果你的搜索结果不需要近实时的准确度，考虑把每个索引的index.refresh_interval改到30s
4. 如果你在做大批量导入，考虑通过设置index.number_of_replicas: 0关闭副本
5. 需要大量拉取数据的场景，可以采用scan & scroll API来实现，而不是from/size一个大范围

存储层面：

1. 基于数据+时间滚动创建索引，每天递增数据。控制单个索引的量，一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑+及早避免
2. 冷热数据分离存储，热数据（比如最近3天或者一周的数据），其余为冷数据。对于冷数据不会再写入新数据，可以考虑定期force_merge加shrink压缩操作，节省存储空间和检索效率

13. ES分配多少内存?VM参数如何优化？

生成大量长生命周期的对象，是给heap造成压力的主要原因，例如读取一大片数据在内存中进行排序，或者在heap内部建cache缓存大量数据。如果GC释放的空间有限，而应用层面持续大量申请新对象，GC频度就开始上升，同时会消耗掉很多CPU时间。

Lucene的倒排索引(Inverted Index)是先在内存里生成，然后定期以段文件(segment file)的形式刷到磁盘的。每个段实际就是一个完整的倒排索引，并且一旦写到磁盘上就不会做修改。API层面的文档更新和删除实际上是增量写入的一种特殊文档，会保存在新的段里。不变的段文件易于被操作系统cache，热数据几乎等效于内存访问。

基于以上2个基本事实，我们不难理解，为何官方建议的heap size不要超过系统可用内存的一半。heap以外的内存并不会被浪费，操作系统会很开心的利用他们来cache被用读取过的段文件。

Heap分配多少合适？遵从官方建议就没错。不要超过系统可用内存的一半，并且不要超过32GB。JVM参数呢？对于初级用户来说，并不需要做特别调整，仍然遵从官方的建议，将xms和xmx设置成和heap一样大小，避免动态分配heap size就好了。虽然有针对性的调整JVM参数可以带来些许GC效率的提升，当有一些“坏”用例的时候，这些调整并不会有什么魔法效果帮你减轻heap压力，甚至可能让问题更糟糕。

14. ES的heap被什么占用？

Segment不是file吗？segment memory又是什么？前面提到过，一个segment是一个完备的Lucene倒排索引，而倒排索引是通过词典(Term Dictionary)到文档列表(Postings List)的映射关系，快速做查询的。由于词典的size会很大，全部装载到heap里不现实，因此Lucene为词典做了一层前缀索引(Term Index)，这个索引在Lucene4.0以后采用的数据结构是FST(Finite State Transducer)。这种数据结构占用空间很小，Lucene打开索引的时候将其全量装载到内存中，加快磁盘上词典查询速度的同时减少随机磁盘访问次数。

说白了,ES的data node存储数据并非只是耗费磁盘空间的，为了加速数据的访问，每个segment都有会一些索引数据驻留在heap里。因此segment越多，瓜分掉的heap也越多，并且这部分heap是无法被GC掉的！理解这点对于监控和管理集群容量很重要，当一个node的segment memory占用过多的时候，就需要考虑删除、归档数据，或者扩容了。

怎么知道segment memory占用情况呢

GET /_cat/segment/
GET /_cat/nodes?v&h=name, port

15. 那么有哪些途径减少data node上的segment memory占用呢？

1. 删除不用的索引
2. 关闭索引（文件仍然存在于磁盘，只是释放掉内存）。需要的时候可以重新打开
3. 定期对不再更新的索引做optimize(ES2.0以后更改为force merge API)。这Optimize的实质是对segment file强制做合并，可以节省大量的segment memory

16. 在实践过程中,索引越来越大,那么单个shard分片也越来越大,查询速度也越来越慢。是选择分索引还是分shards？

实验中更多的shards会带来额外的IO压力.

Elastic官方文档建议：一个Node最好不要多于三个shards。

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

1. 集群是一个或多个节点（服务器）的集合，它们共同保存您的整个数据，并提供跨所有节点的联合索引和搜索功能。群集由唯一名称标识，默认情况下为“Elasticsearch”。此名称很重要，因为如果节点设置为按名称加入群集，则该节点只能是群集的一部分
2. 节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能
3. 索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间，映射到一个或多个主分片，并且可以有零个或多个副本分片。MySQL=>数据库Elasticsearch=>索引
4. 文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构（字段），但是对于通用字段应该具有相同的数据类型。MySQL=>Databases=>Tables=>Columns/Rows，Elasticsearch=>Indices=>Types=>具有属性的文档
5. 类型是索引的逻辑类别/分区，其语义完全取决于用户

18. Elasticsearch是否有架构？

Elasticsearch可以有一个架构。架构是描述文档类型以及如何处理文档的不同字段的一个或多个字段的描述。Elasticsearch中的架构是一种映射，它描述了JSON文档中的字段及其数据类型，以及它们应该如何在Lucene索引中进行索引。因此，在Elasticsearch术语中，我们通常将此模式称为“映射”。

Elasticsearch具有架构灵活的能力，这意味着可以在不明确提供架构的情况下索引文档。如果未指定映射，则默认情况下，Elasticsearch会在索引期间检测文档中的新字段时动态生成一个映射。

19. Elasticsearch中的分片是什么？

在大多数环境中，每个节点都在单独的盒子或虚拟机上运行。

• 索引：在Elasticsearch中，索引是文档的集合
• 分片：因为Elasticsearch是一个分布式搜索引擎，所以索引通常被分割成分布在多个节点上的被称为分片的元素

20. Elasticsearch中的副本是什么？

一个索引被分解成碎片以便于分发和扩展。副本是分片的副本。一个节点是一个属于一个集群的Elasticsearch的运行实例。一个集群由一个或多个共享相同集群名称的节点组成。

21. Elasticsearch中的分词器是什么？

分词是将文本转换成一系列单词（Term or Token）的过程，也可以叫文本分析，在ES里面称为Analysis

分词器是ES中专门处理分词的组件，英文为Analyzer，它的组成如下：

• Character Filters：针对原始文本进行处理，比如去除html标签
• Tokenizer：将原始文本按照一定规则切分为单词
• Token Filters：针对Tokenizer处理的单词进行再加工，比如转小写、删除或增新等处理

22. 是否了解字典树？

常用字典数据结构如下所示：

字典树又称单词查找树，Trie树，是一种树形结构，是一种哈希树的变种。典型应用是用于统计，排序和保存大量的字符串（但不仅限于字符串），所以经常被搜索引擎系统用于文本词频统计。它的优点是：利用字符串的公共前缀来减少查询时间，最大限度地减少无谓的字符串比较，查询效率比哈希树高。

Trie的核心思想是空间换时间，利用字符串的公共前缀来降低查询时间的开销以达到提高效率的目的。它有3个基本性质：

1. 根节点不包含字符，除根节点外每一个节点都只包含一个字符。
2. 从根节点到某一节点，路径上经过的字符连接起来，为该节点对应的字符串。
3. 每个节点的所有子节点包含的字符都不相同。

1. 可以看到，trie树每一层的节点数是26^i级别的。所以为了节省空间，我们还可以用动态链表，或者用数组来模拟动态。而空间的花费，不会超过单词数×单词长度
2. 实现：对每个结点开一个字母集大小的数组，每个结点挂一个链表，使用左儿子右兄弟表示法记录这棵树
3. 对于中文的字典树，每个节点的子节点用一个哈希表存储，这样就不用浪费太大的空间，而且查询速度上可以保留哈希的复杂度O(1)