Elasticsearch6.2版本_默认集群节点发现机制(zendiscovery) Api翻译

官网api地址：https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-zen.html#modules-discovery-zen

Zen Discovery

zen discovery是elasticsearch默认的内置的发现模块。它提供单播发现的方式，但是可以扩展为云环境或者其他形式的发现模式。zendiscovery是和其他模块集成的，例如，所有节点间正常的单播通信都是通过transport模块。

zendiccovery还有几个子模块，介绍如下：

Ping

ping是节点间互相发现的机制

unicast(单播)

单播发现需要一个主机列表充作路由列表。这些主机可以是主机名称也可以是IP地址，在每次pinging的时候主机名称会相应地被解析为对应的ip地址。注意：如果您的DNS协议处在随时变化的环境，也许需要调整您的JVM安全设置。

建议设置单播host列表为所有的master-eligible node (master=true的节点即备选主节点)。

单播发现依赖前缀为（elasticsearch.yml文件中的）discovery.zen.ping.unicast的配置:

配置	描述
discovery.zen.ping.unicast.hosts	格式为数组或以逗号分隔的字符串，每个值的格式都应该为host或host:port(port的默认值为transport.profiles.default.port后的参数，如果未设置transport.profiles.default.port，则使用transport.tcp.port)，如果是ipv6的(除了用逗号分隔)主机还必须用方括号括起来，例如：127.0.0.1,[::1]
discovery.zen.ping.unicast.hosts.resolve_timeout	DNS解析时间，需要指定单位，默认5s

单播发现(unicast discovery)应用transport 模块实现发现(discovery)。

Mater Election主节点选举

作为ping过程的一部分，一个集群的主节点需要是被选举或者加入进来的(即选举主节点也会执行ping，其他的操作也会执行ping)。这个过程是自动执行的。通过配置discovery.zen.ping_timeout来控制节点加入集群或者选举的响应时间(默认3s)。在这段时间内有3个ping会发出。如果超时,重新启动ping程序。在网络缓慢是，3秒时间可能不够，这种情况下，可以慎重增加超时时间，增加超时时间会减慢选举进程。一旦节点决定加入一个存在的集群，它会发出一个加入请求给主节点，这个请求的超时时间由discovery.zen.join_time控制，默认是ping超时时间(discovery.zen.ping_timeout)的20倍。

当主节点停止或者出现问题，集群中的节点会重新ping并选举一个新节点。有时一个节点也许会错误的认为主节点已死，所以这种ping操作也可以作为部分网络故障的保护性措施。这种情况下，节点可以简单的从其他节点监听当前活动的住节点信息。

如果discovery.zen.master_election.ignore_non_master_pings设置为true时,node.master为false的节点不参加主节点的选举，同时选票也不包含这种节点。

通过设置node.master为false,可以将节点设置为非备选主节点，永远没有机会成为主节点。

discovery.zen.minimum_master_nodes设置了最少有多少个备选主节点参加选举，同时也设置了一个主节点需要控制最少多少个备选主节点才能继续保持主节点身份。如果控制的备选主节点少于discovery.zen.minimum_master_nodes个，那么当前主节点下台，重新开始选举。

discovery.zen.minimum_master_nodes必须设置一个恰当的备选主节点值(quonum，一般设置 为备选主节点数/2+1),尽量避免只有两个备选主节点，因为两个备选主节点quonum应该为2，那么如果一个节点出现问题，另一个节点的同意人数最多只能为1，永远也不能选举出新的主节点(知识链接：脑裂)

Fault Detectionedit故障检测

有两个故障检测线程在集群的生命周期中一直运行。一个是主节点的，ping集群中所有的其他节点，检查他们是否活着。另一种是每个节点都ping主节点，确认主节点是否仍在运行或者是否需要重新启动选举程序。

使用discovery.zen.fd前缀设置来控制故障检测过程，配置如下

配置	描述
ping_interval	节点多久ping一次 默认1s
ping_timeout	等待响应时间  默认30s
ping_retries	失败或超时后重试的次数 默认3

Cluster state updates 集群状态更新

主节点是唯一一个能够更新集群状态的节点。一个时间段内住节点只能更新一个集群状态(cluster state),应用所需更改，并将更改的集群状态发送给其他节点，当其他节点接收到状态时，先确认收到消息，但是不应用最新状态。如过主节点在规定时间（discovery.zen.commit_timeout 默认30s）内没有收到大多数节点(discovery.zen.minimum_master_nodes)的确认，集群状态更新不被通过。

一旦足够的节点响应了更新的消息，新的集群状态(cluster state)被提交并且会发送一条消息给所有的节点。这些节点开始在内部应用新的集群状态.在处理更新队列中的下一个更新之前，主节点会从发布那一次开始等待所有的节点响应，直到超时(discovery.zen.publish_timeout默认设置为30秒)。上述两个超时设置都可以通过集群更新api动态设置更改。

No master block没有主节点时的操作

对于一个可以正常充分运作的集群来说，必须拥有一个活着的主节点和正常数量(discovery.zen.minimum_master_nodes个)活跃的备选主节点。discovery.zen.no_master_block设置了没有主节点时限制的操作。它又两个可选参数

all：所有操作均不可做，读写、包括集群状态的读写api，例如获得索引配置(index settings)，putMapping，和集群状态(cluster state)api

write：默认为write，写操作被拒绝执行，基于最后一次已知的正常的集群状态可读，这也许会读取到已过时的数据。

discovery.zen.no_master_block对于节点相关的基本api这个参数是无效的，如集群属性，节点信息，节点属性，（cluster stats、 node info、 node stats apis）这些请求不会被拒绝。

-------------完-----------------------

后记：

还需读源码，看书，浏览打牛的博客，希望我的每一天都有进步。