ElasticSearch 2 的节点调优（ElasticSearch性能）

摘要

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

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

版本

elasticsearch版本: elasticsearch-2.x

内容

一个集群解决所有问题？

需要回答的问题远不止以上这些，但是第五个问题往往是容易被我们忽视的，因为单个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.minimum_master_nodes 它规定了在选举新的master时，一个集群下最少需要的节点数。例如，一个3节点集群，这个数字为2，2个节点可以防止单个节点在脱离集群时，将其自己选举成master，相反，它会等待直到重新加入到集群中。这个数值可以通过一个公式确定：

N/2 + 1

N的值为集群下所有节点的数目。

牺牲可用性

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

小结

对于ElasticSearch集群的节点数没有定论，ElasticSearch的工程师在Quora上也给出了他的相似意见，可供参考

参考

参考来源:

How many nodes should an Elasticsearch cluster have?

What's the maximum number of nodes Elasticsearch can have? How many, max, have you used in practice?

Elasticsearch Internals: Networking Introduction