ES的Zen发现机制
ES的Zen发现机制
Zen发现机制是ElasticSearch默认的发现模块。它提供的是单播发现，但是可被拓展为支持云环境下或者其他形式的发现机制。zen 发现模块集成了其他模块，如在发现期间，节点的通信就是通过transport模块实现 。
zen发现模块可以细分以下几块：
l Ping
这是一个节点通过发现机制查找其他节点的进程
l Unicast
单播发现需要一组主机列表来充当gossip routers，这些主机可以提供主机名称或者主机的IP；当在Ping的过程中，提供名称的主机被解析成IP地址。需要注意的是你的环境中如果DNS解析如果随着时间变化的话，你需要调整JVMsecurity settings.
推荐设置是将单播列表作为当前集群的master后续列表。
单播发现提供的配置是以discovery.zen.ping.unicast开头：
|
名称 |
描述 |
默认值 |
|
hosts |
可以是数组设置或者通过“，”分割的设置，每个值的格式是：host:port或者host，如果port可以通过transport.profiles.default.port设置，如果不设置，将会使用transport.tcp.port（默认是9300），需要注意的是如果使用的IPv6的话，必须通过括号括起来 |
127.0.0.1,[::1] |
|
Hosts.resolve_timeout |
DNS解析的时间。需要指定单位 |
5s |
Master选举
作为ping进程的一部分，集群的master被选举出来或者加入其中。这个过程是自动完成的。discovery.zen.ping_timeout（默认是3s）决定了一个节点在决定开始选举还是加入一个存在集群的等待时间。在超过这个时间后，会尝试3次ping。如果已经达到了超时时间，还没有做出决定，则pnig进程会重启。在一个缓慢的或者拥挤的网络中，3s或许不足以在做出决定前，发觉环境中的其他节点。在这种情况下，应该提升超时时间，进而让选举工作慢下来。一旦一个节点决定加入一个现有的网络，则其会向master发送一个20倍ping超时的加入请求。
当master节点停止或者发生问题时，集群则重新开始选举。这个互相ping也作为了网络出问题的一种保障，当一个节点没有意识到master已经失败了（这个理解应该有错误）。在这种情况下，一个节点可以从其他节点处的得到当前的master节点。
discovery.zen.master_election.ignore_non_master_pings被设置为true，在选举过程中，来自非master候选节点的pings将会被忽略。默认值是false.
通过node.master设置为false，将该节点排除，避免其成为matster节点。
discovery.zen.minimum_master_nodes设置参选master的最小值，需要加入新选的master，来完成选举工作，同时，接受master节点的身份。这个参数同样控制最少活跃候选节点的数量，这些节点应该是集群的一部分。如果没有达到这个值，则当前master将要下台，开始新的选举工作。
这个参数必须设置候选节点的有效值。建议避免有两个候选节点，因为两个的有效值是两个。这样，当丢失其中一个候选节点的结果是集群不可用。
l 故障检测
在es集群中会存在两种故障检测进程，一种是master节点发起的，检测是否可以ping通集群中的节点，同时判断节点是否还存活；另一种是由其他节点发起的，用于判断master节点是否还存活以及是否有必要重新发起选举。相关故障检测参数配置是由discovery.zen.fd为前缀的，相关参数如下：
|
名称 |
描述 |
默认值 |
|
ping_interval |
Ping的时间间隔 |
1s |
|
ping_timeout |
等待结果响应的超时时间 |
30s |
|
ping_retries |
失败或者超时后重试的次数 |
3s |
- 集群状态更新
Master节点是集群中唯一可以更新集群状态的节点。Master节点一次处理一个集群状态的更新，应用所需的更改，并将集群的状态发布给集群中的其他节点。每一个节点接受到状态后，确认收到消息，但是并不应用该消息。如果master节点没有在规定的时间内（discovery.zen.commit_timeout默认30s）的得到discovery.zen.minimum_master_nodes节点的认可，则集群状态更新废弃。
一旦得到足够的响应，则集群的状态将被提交，同时，消息也会告知其他节点。然后，节点将状态应用到期内部状态中。Master节点会等待所有节点的响应直到超时，然后去处理队列中新的更新。这discovery.zen.publish_timeout默认是30s，是从状态发布开始计算的。这个超时时间是可以通过api动态更新。
l No master block
一个集群可以完整的操作，它必须有一个活的master节点和足够数量的候选master节点来满足discovery.zen.minimum_master_nodes。discovery.zen.no_master_block控制哪些操作将被丢弃，当集群没有master节点时。
discovery.zen.no_master_block有两个有效值：
|
all |
所有的操作，如读和写都将被丢弃。这个同样应用在集群状态的读写api操作，如get index setting, put mapping 和集群状态的api |
|
write |
(默认)写操作将被丢弃。根据最后的已知的集群配置，读操作可以成功。这个可能读取部分结果，因为查询的节点可能是一个与其他节点隔离（其实简单的说，就是已经脑裂了）。 |
discovery.zen.no_master_block这个参数对于节点相关的api无效（如集群属性，节点信息，节点属性）。这些请求的api都不会被拒绝，并且可以运行在任意可用节点。
