白话 IT 之 从 ElasticSearch 到 ZooKeeper

Posted StuQ

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了白话 IT 之 从 ElasticSearch 到 ZooKeeper相关的知识,希望对你有一定的参考价值。

▲点击关注,学习软件研发新技能

版权声明:本文已获得作者授权,StuQ 微信公众号独家发布。


白话 IT 之 从 ElasticSearch 到 ZooKeeper



作者介绍:


朱赟,MacTalk 池建强老师笔下的神童,就职于 Airbnb 的华人工程师,美丽大方的科技人才,两个孩子的妈妈。


风马牛不相及的两个技术,对吧?


别急,听我把故事讲完就知道了。


前面提到过,有机会用 Solr 做过搜索引擎,后来又用 ElasticSearch 把整个服务重写了一遍。今天先不谈他们两之间的全面的比较,只说一个当年遇到的一个很长姿势的故事。


ElasticSearch 的脑裂 (split brain) 问题


用过 solr 和 ElasticSearch 的都知道,其实做搜索都是两件事,一是把你所有的数据做 indexing,加到索引项里。一是当你有个查询的时候,把这个查询用相应的格式写出来,到索引项里去找满足要求的。


对于单服务器单结点的部署,Solr 和 ElasticSearch 的性能差别是有限的。但是当你的服务器结点比较多的时候。因为 Solr(当时的版本)是不支持 master election 的,所有的建索引都是对单 master 的写,然后内容被拷贝到多个 slave 结点上成为 replica。搜索负载都是简单的对 replica 的读。但是 ElasticSearch 就有个很好的可扩展的架构。

白话 IT 之 从 ElasticSearch 到 ZooKeeper

这里,数据结点是存放搜索索引项的。非 master 的 client 节点简单说来就是一个智能的负载平衡器,可以处理搜索中的一些简单的步骤。master 结点顾名思义,主要是用来做 cluster 的管理,而不去做计算量比较大的实际搜索的操作或者处理。换句话说,有点类似一个内置的 zookeeper。


ElasticSearch 在对 master 节点的选举上,至今仍存在的一个问题就是著名的脑裂 (split brain) 问题。这里有个 blog 对此进行了很好的解释。blog 的链接:http://blog.trifork.com/2013/10/24/how-to-avoid-the-split-brain-problem-in-elasticsearch/(复制后粘贴到浏览器或点击阅读原文可查看)


简单点说,就是比如当你的 cluster 里面有两个结点,它们都知道在这个 cluster 里需要选举出一个 master。那么当它们两之间的通信完全没有问题的时候,就会达成共识,选出其中一个作为 master。但是如果它们之间的通信出了问题,那么两个结点都会觉得现在没有 master,所以每个都把自己选举成 master。于是 cluster 里面就会有两个 master。


当然这是一个很简单的例子,实际情况当你的 cluster 比较大的时候要复杂的多。当时我们经常莫名其妙整个搜索就挂了,当时 ElasticSearch 刚开始火,网上资料也不多,很是挣扎了一段时间。后来明白就是因为这个问题。


那么现在的 ElasticSearch 都怎么解决这个问题呢?两种方案。一种就对你的 cluster 结点数以及 master 个数加一些限制,比如 ES 中可以指定一个参数来决定如果你要想成为 master,你必须至少和几个结点保持通信状态。这样可以确保不会出现多个 master,但是有可能会在一些情况下整个 cluster 都没有 master,照样挂。 而另一个解决方案就是外部加载一个 ZooKeeper 来完成对 cluster 的结点管理。


ZooKeeper 的 Quorums 机制对脑裂的防止


其实 master 选举问题由来以久。最早的比较完整的阐述称为 Paxos 算法。1990 年的一篇文章就对整个问题和算法进行了很完整的阐述。自文章问世以来,各个不同的工具都试图对这个问题进行一个实现。据我所知大都没有得到很广泛的应用。


ZooKeeper 是对结点管理的一个很强大的实现。 ZooKeeper 的选主过程使用的就是 paxos 算法。(ZooKeeper 的是数据复制使用的是 Zab (ZooKeeper atom broadcast) 算法,因为 paxos 无法保证多个写之间因果顺序,要实现的话只能串行执行,效率太低。)别的且不说,就脑裂这个问题,ZooKeeper 就提供了至少三种方式来认定整个集群是否可用,其中majority quorums 就是类似上面说的用结点个数限制的思想来实现的。即只有集群中超过半数节点投票才能选举出 master。这也是 ZooKeeper 的默认方式。还有两种一种是通过冗余通信,允许集群中采用多种通信方式来防止单一通信方式实效。另一种是通过共享资源,比如能看到共享资源就表示在集群中,反之则不是。


新的搜索引擎用不用 ZooKeeper?


正因为 ZooKeeper 很好的解决了脑裂的问题,新的搜索引擎 SolrCloud 就集成了 ZooKeeper 用来做 cluster 管理。但是最近 AWS 提供的 CloudSearch (基于 Solr) 和 Amazon ElasticSearch (基于 ElasticSearch) 则是把对 cluster 的部署嵌入到了 AWS 的资源管理中。可以通过实时的对 CPU 使用的监测自动增减 replica。CloudSearch 感觉很好用。Amazon ElasticSearch 很新,还不是特别了解。


StuQ 2016 微课堂年会会员招募
2016 年我们将邀请更多来自企业的技术专家,分享自己的实战经验和项目实施案例。每个技术领域的内容会更系统,讲师与学员之间的互动会更加紧密。 StuQ 微课堂将在现有服务形式上推出年费会员微课堂服务。课程体系更完美,学习工具更高级、人群更聚焦。

目前,前端课程会员正在火热报名中,会员价 899RMB/年,扫描二维码进入会员群,了解详情请在后台回复 前端会员

以上是关于白话 IT 之 从 ElasticSearch 到 ZooKeeper的主要内容,如果未能解决你的问题,请参考以下文章

大白话讲解Elasticsearch的查询内部原理

白话经典算法系列之九 从归并排序到数列的逆序数对(微软笔试题)

白话经典算法系列之六 快速排序 快速搞定 转

Elasticsearch顶尖高手系列-快速入门篇

白话经典算法系列之六 快速排序 快速搞定

SpringCloud大白话之服务注册中心