Elastic Search常见面试题

Elastic Search常见面试题

1. 为什么要使用ElasticSearch？

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

2. Elastic Search的Master选举流程？

• Elastic Search的选主是ZenDIscovery模块负责的，主要包含Ping(节点之间通过这个RPC来发现彼此)和Unicast(单播模块包含一个主机列表以控制哪些节点需要Ping通)这两部分。
• 对所有可以成为master的节点（node.master:true）根据nodeId字段排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
• 如果对某个节点的投票数达到一定值（可以成为master节点数n/2+1）并且该节点也自己选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。
• master节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data节点可以关闭http功能。

3. Elastic Search集群脑裂问题？

脑裂问题可能产生的原因：

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

脑裂问题解决方案：

• 减少误判: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

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

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

5. 在GC方面，Elastic Search需要注意哪些点？

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

6. 在并发情况下，Elastic Search如何保证读写一致？

1. 可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突;
2. 对于写操作，一致性级别支持quorum/one/all，默认为quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。
3. 对于读操作，可以设置replication为sync(默认)，这使得操作在主分片和副本分片都完成后才会返回;如果设置 replication 为 async 时，也可以通过设置搜索请求参数_preference 为 primary 来查询主分片， 确保文档是最新版本。

7. Elastic Search中的集群、节点、索引、文档和类型是什么？

• 集群是一个或多个节点(服务器)的集合，它们共同保存您的整个数据，并提供跨所有节点的联合索引和搜索功能。群集由唯一名称标识，默认情况下为“elasticsearch”。

• 节点是属于集群一部分的单个服务器。它存储数据并参与群集索引和搜索功能。

• 索引就像关系数据库中的“数据库”。它有一个定义多种类型的映射。索引是逻辑名称空间，映射到一个或多个主分片，并且可以有零个或多个副本分片。 MySQL=>数据库 Elasticsearch=>索引

• 文档类似于关系数据库中的一行。不同之处在于索引中的每个文档可以具有不同的结构(字段)，但是对于通用字段应该具有相同的数据类型。 MySQL => Databases => Tables => Columns / Rows

  Elasticsearch => Indices => Types =>具有属性的文档。

• 类型是索引的逻辑类别/分区，其语义完全取决于用户。

8. Elastic Search 中的倒排索引是什么？

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