ElasticSearch架构思考(转)

一个ElasticSearch集群需要多少个节点很难用一种明确的方式回答，但是，我们可以将问题细化成一下几个，以便帮助我们更好的了解，如何去设计ElasticSearch节点的数目：

1. 打算处理多少数据？
2. 打算处理多少搜索请求？
3. 请求的复杂度是怎样？
4. 每个节点有多少资源数？
5. 打算建立多少索引，支持多少应用？

一个集群解决所有问题？

需要回答的问题远不止以上这些，但是第五个问题往往是容易被我们忽视的，因为单个ElasticSearch集群有能力支持多索引，也就能支持多个不同应用的使用。我们可以将公司里所有的日志都放在一个ElasticSearch集群下处理，无论是网站上的一个简单查询，还是一个非常复杂的分析。了解一个集群能支持多少个应用程序的日志需求，能帮助我们分析出合适的节点数目。

节点数与内存相关

ElasticSearch 的节点数受RAM的限制，对于某个服务器或虚拟机，我们分配的物理或虚拟内存是有限的，这样自然限制了我们分配节点的数量。

万能节点数——3

如果我们要建立一个ElasticSearch集群，一个比较合适的数字是3。为什么3？很大程度上一个集群3个节点可以防止“split-brain”出现，尽管，对于一个分布式的集群，每个节点都是对等的，但是我们仍然需要一个主节点master。这个节点承担协调自己以及其他所有节点间的通信任务。在ES中，主节点除了负责以上工作，它还会对分片与副本的存储进行优化，同时还要处理索引、写入数据和路由索引优化等问题。

三个和尚投票

当主节点master出现问题，从节点slave不能与主节点通信时，从节点会发起选举任命新的主节点，同时新的master会接管旧master的所有工作，如果旧master重新恢复并加入到集群中，新master会将原来旧的master降级为slave，这样就不会有冲突发生。所有这个过程都由ElasticSearch自己处理，使用者无需任何参与。

两个和尚投票

但是，当只有两个节点的时候，一主（master）一从（slave），如果主从直接的通信出现问题时，从节点slave会自我提升为master，但是当恢复通信时，我们就会同时有两个master。因为此时，对于原来的主节点（master）角度考虑，它认为是原来的从节点（slave）出现问题，现在仍然需要作为slave重新加入。这样，两个节点的时候，我们就出现了集群不知道将哪个节点选举为主节点的情况，也就是我们通常说的“分脑”。

为了防止这种情况的发生，第三个节点的出现会打破平衡，解决冲突问题。

三个和尚仍然存在问题

分脑的问题同样会出现在具有三或三个以上节点的集群中，为了降低发生的概率，ElasticSearch提供了一个配置 discovery.zen.minimummasternodes 它规定了在选举新的master时，一个集群下最少需要的节点数。例如，一个3节点集群，这个数字为2，2个节点可以防止单个节点在脱离集群时，将其自己选举成master，相反，它会等待直到重新加入到集群中。这个数值可以通过一个公式确定：

N/2 + 1 N的值为集群下所有节点的数目。

牺牲可用性

防止两个节点集群出现“分脑”情况有一个办法，就是将其中一个节点 node.data 的配置设置为 false，这样，这个节点就永远不会成为master，当然，这也会降低集群的可用性。

小结

对于ElasticSearch集群的节点数没有定论，ElasticSearch的工程师在Quora上也给出了他的相似意见https://www.quora.com/Whats-the-maximum-number-of-nodes-Elasticsearch-can-have-How-many-max-have-you-used-in-practice

资料

elasticsearch系列：http://www.cnblogs.com/richaaaard/category/783901.html