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

ElasticSearch 在对 master 节点的选举上，至今仍存在的一个问题就是著名的脑裂 (split brain) 问题。这里有个 blog 对此进行了很好的解释。blog 的链接：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 很新，还不是特别了解。

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

ElasticSearch 在对 master 节点的选举上，至今仍存在的一个问题就是著名的脑裂 (split brain) 问题。这里有个 blog 对此进行了很好的解释。blog 的链接：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 很新，还不是特别了解。