2 万字详解，彻底讲透 Elasticsearch( 三 ) _Elasticsearch

discovery.zen.ping.unicast.hosts: ["host1", "host2:port"] 节点启动后先 Ping ，如果
discovery.zen.ping.unicast.hosts有设置，则 Ping 设置中的 Host ，否则尝试 ping localhost 的几个端口。
Elasticsearch 支持同一个主机启动多个节点，Ping 的 Response 会包含该节点的基本信息以及该节点认为的 Master 节点。
选举开始，先从各节点认为的 Master 中选，规则很简单，按照 ID 的字典序排序，取第一个。如果各节点都没有认为的 Master ，则从所有节点中选择，规则同上。
这里有个限制条件就是
discovery.zen.minimum_master_nodes，如果节点数达不到最小值的限制，则循环上述过程，直到节点数足够可以开始选举。
最后选举结果是肯定能选举出一个 Master ，如果只有一个 Local 节点那就选出的是自己。
如果当前节点是 Master ，则开始等待节点数达到
discovery.zen.minimum_master_nodes，然后提供服务。
如果当前节点不是 Master ，则尝试加入 Master。Elasticsearch 将以上服务发现以及选主的流程叫做 Zen Discovery。
由于它支持任意数目的集群（ 1- N ），所以不能像 Zookeeper 那样限制节点必须是奇数，也就无法用投票的机制来选主，而是通过一个规则。
只要所有的节点都遵循同样的规则，得到的信息都是对等的，选出来的主节点肯定是一致的。
但分布式系统的问题就出在信息不对等的情况，这时候很容易出现脑裂（Split-Brain）的问题。
大多数解决方案就是设置一个 Quorum 值，要求可用节点必须大于 Quorum（一般是超过半数节点），才能对外提供服务。
而 Elasticsearch 中，这个 Quorum 的配置就是
discovery.zen.minimum_master_nodes 。

②节点的角色每个节点既可以是候选主节点也可以是数据节点，通过在配置文件
../config/elasticsearch.yml 中设置即可，默认都为 true 。
node.master: true //是否候选主节点 node.data: true //是否数据节点数据节点负责数据的存储和相关的操作，例如对数据进行增、删、改、查和聚合等操作，所以数据节点（Data 节点）对机器配置要求比较高，对 CPU、内存和 I/O 的消耗很大。
通常随着集群的扩大，需要增加更多的数据节点来提高性能和可用性。
候选主节点可以被选举为主节点（Master 节点），集群中只有候选主节点才有选举权和被选举权，其他节点不参与选举的工作。
主节点负责创建索引、删除索引、跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点、追踪集群中节点的状态等，稳定的主节点对集群的健康是非常重要的。

文章插图
一个节点既可以是候选主节点也可以是数据节点，但是由于数据节点对 CPU、内存核 I/O 消耗都很大。
所以如果某个节点既是数据节点又是主节点，那么可能会对主节点产生影响从而对整个集群的状态产生影响。
因此为了提高集群的健康性，我们应该对 Elasticsearch 集群中的节点做好角色上的划分和隔离。可以使用几个配置较低的机器群作为候选主节点群。
主节点和其他节点之间通过 Ping 的方式互检查，主节点负责 Ping 所有其他节点，判断是否有节点已经挂掉。其他节点也通过 Ping 的方式判断主节点是否处于可用状态。
虽然对节点做了角色区分，但是用户的请求可以发往任何一个节点，并由该节点负责分发请求、收集结果等操作，而不需要主节点转发。
这种节点可称之为协调节点，协调节点是不需要指定和配置的，集群中的任何节点都可以充当协调节点的角色。

③脑裂现象同时如果由于网络或其他原因导致集群中选举出多个 Master 节点，使得数据更新时出现不一致，这种现象称之为脑裂，即集群中不同的节点对于 Master 的选择出现了分歧，出现了多个 Master 竞争。
“脑裂”问题可能有以下几个原因造成：