面试 - ElasticSearch

原创
03/24 18:58
阅读数 102

ElasticSearch是如何实现Master选举的?
ElasticSearch的选主是ZenDiscovery模块负责的,主要包含Ping(节点之间通过这个RPC来发现彼此)和Unicast(单播模块包含一个主机列表以控制哪些节点需要ping通)这两部分。
对所有可以成为master的节点(node.master: true)根据nodeId字典排序,每次选举每个节点都把自己所知道节点排一次序,然后选出第一个(第0位)节点,暂且认为它是master节点。
如果对某个节点的投票数达到一定的值(可以成为master节点数n/2+1)并且该节点自己也选举自己,那这个节点就是master。否则重新选举一直到满足上述条件。

ElasticSearch中的节点(比如共20个),其中的10个选了一个master,另外10个选了另一个master,怎么办?
当集群master候选数量不小于3个时,可以通过设置最少投票通过数量(discovery.zen.minimum_master_nodes)超过所有候选节点一半以上来解决脑裂问题。
当候选数量为两个时,只能修改为唯一的一个master候选,其他作为data节点,避免脑裂问题。

详细描述一下ElasticSearch索引文档的过程?
协调节点默认使用文档ID参与计算(也支持通过routing),以便为路由提供合适的分片。
当分片所在的节点接收到来自协调节点的请求后,会将请求写入到Memory Buffer,然后定时(默认是每隔1秒)写入到Filesystem Cache,这个从Momery Buffer到Filesystem Cache的过程就叫做Refresh。
当然在某些情况下,存在Momery Buffer和Filesystem Cache的数据可能会丢失,ES是通过TransLog的机制来保证数据的可靠性的。其实现机制是接收到请求后,同时也会写入到TransLog中,当Filesystem Cache中的数据写入到磁盘中时,才会清除掉,这个过程叫做Flush。
在Flush过程中,内存中的缓冲将被清除,内容被写入一个新段,将创建一个新的提交点,并将内容刷新到磁盘,旧的TransLog将被删除并开始一个新的TransLog。
Flush触发的时机是定时触发(默认30分钟)或者TransLog变得太大(默认为512M)时。

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

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

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

如何监控Elasticsearch集群状态?
Marvel让你可以很简单的通过Kibana监控Elasticsearch。你可以实时查看你的集群健康状态和性能,也可以分析过去的集群、索引和节点指标。

常用的字典数据结构?
排序列表Array/List:使用二分法查找,不平衡。
HashMap/TreeMap:性能高,内存消耗大,几乎是原始数据的三倍。
Skip List:跳跃表,可快速查找词语,在Lucene、Redis、HBase等均有实现。相对于TreeMap等结构,特别适合高并发场景。
Trie:适合英文词典,如果系统中存在大量字符串且这些字符串基本没有公共前缀,则相应的Tire树将非常消耗内存。
Double Array Trie:适合中文词典,内存占用小,很多分词工具采用此种算法。
Ternary Search Tree:三叉树,每一个Node有三个节点,兼具省空间和查询快的优点。
Finite State Transducers(FST):一种有限状态装移机,Lucene4有开源实现,并大量使用。

是否了解字典树?
Trie的核心思想是空间换时间,利用字符串的公共前缀来降低查询时间的开销以达到提高效率的目的。
基本性质:
1.根节点不包含字符,除根节点外每一个节点都只包含一个字符。
2.从根节点到某一节点,路径上经过的字符连接起来,为该节点对应的字符串。
3.每个节点的所有子节点包含的字符都不相同。

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

ElasticSearch中的分片是什么?
在大多数环境中,每个节点都在单独的盒子或虚拟机上运行。
索引:在ElasticSearch中,索引是文档的集合。
分片:因为ElasticSearch是一个分布式搜索引擎,所以索引通常被分割成分布在多个节点上的被称为分片的元素。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部