风马牛不相及的两个技术，对吧？
别急，听我把故事讲完就知道了。
前面《那些年我们一起 hack 的日子》提到过，有机会用 Solr 做过搜索引擎，后来又用 ElasticSearch 把整个服务重写了一遍。今天先不谈他们两之间的全面的比较，只说一个当年遇到的一个很长姿势的故事。
ElasticSearch 的脑裂 (split brain) 问题
用过 solr 和 ElasticSearch 的都知道，其实做搜索都是两件事，一是把你所有的数据做 indexing，加到索引项里。一是当你有个查询的时候，把这个查询用相应的格式写出来，到索引项里去找满足要求的。
对于单服务器单结点的部署，Solr 和 ElasticSearch 的性能差别是有限的。但是当你的服务器结点比较多的时候。因为 Solr（当时的版本）是不支持 master election 的，所有的建索引都是对单 master 的写，然后内容被拷贝到多个 slave 结点上成为 replica。搜索负载都是简单的对 replica 的读。但是 ElasticSearch 就有个很好的可扩展的架构。
这里，数据结点是存放搜索索引项的。非 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 很新，还不是特别了解。
注：本号谈技术，在力求准确的前提下尽量保证浅显、白话，更适合入门者阅读。按朋友的说法，属于技术入门的开胃菜。专家慎入。
讲述技术、白话硅谷。偶尔八八程序员身边的事儿。关注长按二维码：
继续阅读
阅读原文