ES的Zen发现机制

Zen发现机制是ElasticSearch默认的发现模块。它提供的是单播发现，但是可被拓展为支持云环境下或者其他形式的发现机制。zen 发现模块集成了其他模块，如在发现期间，节点的通信就是通过transport模块实现 。

zen发现模块可以细分以下几块：

lPing

这是一个节点通过发现机制查找其他节点的进程

lUnicast

单播发现需要一组主机列表来充当gossip routers，这些主机可以提供主机名称或者主机的IP；当在Ping的过程中，提供名称的主机被解析成IP地址。需要注意的是你的环境中如果DNS解析如果随着时间变化的话，你需要调整JVMsecurity settings.

推荐设置是将单播列表作为当前集群的master后续列表。

单播发现提供的配置是以discovery.zen.ping.unicast开头：

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为前缀的，相关参数如下：

• 集群状态更新

Master节点是集群中唯一可以更新集群状态的节点。Master节点一次处理一个集群状态的更新，应用所需的更改，并将集群的状态发布给集群中的其他节点。每一个节点接受到状态后，确认收到消息，但是并不应用该消息。如果master节点没有在规定的时间内（discovery.zen.commit_timeout默认30s）的得到discovery.zen.minimum_master_nodes节点的认可，则集群状态更新废弃。

一旦得到足够的响应，则集群的状态将被提交，同时，消息也会告知其他节点。然后，节点将状态应用到期内部状态中。Master节点会等待所有节点的响应直到超时，然后去处理队列中新的更新。这discovery.zen.publish_timeout默认是30s，是从状态发布开始计算的。这个超时时间是可以通过api动态更新。

lNo master block

一个集群可以完整的操作，它必须有一个活的master节点和足够数量的候选master节点来满足discovery.zen.minimum_master_nodes。discovery.zen.no_master_block控制哪些操作将被丢弃，当集群没有master节点时。

discovery.zen.no_master_block有两个有效值：

discovery.zen.no_master_block这个参数对于节点相关的api无效（如集群属性，节点信息，节点属性）。这些请求的api都不会被拒绝，并且可以运行在任意可用节点。

———————–

ES集群的主节点发现机制采用单播形式,主要配置有三行,如下:

discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["localhost:9001","localhost:9101","localhost:9701"]

第一行的配置说明如下:

# Discovery infrastructure ensures nodes can be found within a cluster
# and master node is elected. Multicast discovery is the default.

# Set to ensure a node sees N other master eligible nodes to be considered
# operational within the cluster. This should be set to a quorum/majority of 
# the master-eligible nodes in the cluster.
#
discovery.zen.minimum_master_nodes: 2

了解Zookeeper的话,这个配置就比较容易理解了; 数值取值为 (有资格当选为Master的节点个数/2+1), 这样做是为了防止脑裂现象, 防止某些主节点自成一个集群. 考虑到Zookeeper的一些配置, 主节点的个数最好是奇数个,并且不少于3个;但是会带来一个问题,如必须至少一半以上的主节点是可用的,如果不能满足这个要求,则系统就会崩溃.

第二行和第三行的配置说明如下:

# Unicast discovery allows to explicitly control which nodes will be used
# to discover the cluster. It can be used when multicast is not present,
# or to restrict the cluster communication-wise.
#
# 1. Disable multicast discovery (enabled by default):
#
discovery.zen.ping.multicast.enabled: false
#
# 2. Configure an initial list of master nodes in the cluster
#    to perform discovery when new nodes (master or data) are started:
#
discovery.zen.ping.unicast.hosts: ["localhost:9001","localhost:9101","localhost:9701"]

1是关闭多播,采用单播;置为false

2是给出所有的Master节点的IP和Port.端口用数据交换接口即可;

集群的节点打算分三种角色, master节点,仅充当master作用,不存储数据; data节点, 仅存储数据,不能当选为master节点; observer节点, 既不充当master,也不存储数据;

—-

ElasticSearch（七）管理ES

发现，故障修复以及恢复

在发现节点，主要是使用ES的zen模块来进行发现，发现的目的就是加入集群，zen的发现有两种模式分别是单播和组播，单播是指配置好了要发现的节点IP，组播则是指不配置具体IP，向局域网广撒网，寻找同名节点，并组成集群。

为了避免在组成集群的时候导致”脑裂”情况，即因为网络通信原因，集群通信被分成了几部分，因为ES集群具有选主的功能，每个部分有组成小集群；通过配置集群的最小组织成员数，比如半数+1，保证了当前集群机器，最多只能组成一个集群，如果有因为某个原因，某台机器离开，也无法再组织处一个新的集群。

集群选举出来的master和data/client节点将会当时互相ping；如果master无法和data/client节点ping通，那么将会标记该节点下线；data/client节点无法和master通信，那么将会触发选主。

关于故障修复，在ES里面故障修复就是发生在本地，ES里面的名词叫”本地网关”，他是一个组件，用于恢复ES在本地里面的数据，这里包括元数据以及文档数据。恢复API是_recovery?pretty；但是恢复我理解应该是在集群重启之后自动进行的这个过程其实并不需要太多的人为干预。但是修复并不是像我们想象的那么简单，里面有很多配置，比如可以指定节点数达到多大才开始进行恢复，如果后来进入的节点可能因为错过了而无法恢复，因为恢复过程是由ES内容通过UDP指令方式（Java API）下发下去的，比如8台机器，配置满足了5台机器恢复，那么剩下的三台可能会因为加入完了而被推迟恢复，或者不背恢复。除非重启。

部落（tribe）

接着说一下ES里面的部落：tribe，可以在查询过程中链接两个集群的数据，查询的数据将会汇总到tribe节点，有tribe节点对数据进行整合再发送给client；tribe还可以写数据，但是这里有一个限制就是写的索引只能是一个集群所有；如果写入两个集群同名索引，那么只能成功写入一个，至于写入哪一个可以通过配置偏好实现。可以通过配置指明tribe只能读，不能写。

提高性能

如果数据频繁的更新，查询性不可重复（比如日志量更新量很大，不断查询最近15分钟日志），其实缓存的价值并不是很大；

对于内存压力很大的排序，汇总等处理，使用docValues来进行数据的字段级别的缓存，他占用极少的内存；

建议关闭Unix的内存关闭，bootstrap.mlockall=true；

热点线程：_nodes/hot_threads；可以获取那些占用了大量内存和cpu的线程，可以指定返回的条数，另外返回的内容不是json，而是一段组织好的文本；

扩展ES：有水平和垂直两种，重点说一下垂直。两种方式：多分片和多副本；如果瓶颈在于硬盘不够了，那么增加分片，做存储的负载均衡；如果瓶颈在于查询的压力，那么增加副本做请求的负载均衡；

关于副本，ES提供了一种自动创建副本的机制，就是实现某些索引的数据自动在所有的节点进行部署副本，这类数据首先是别频发使用的，比如基础数据，另外就是占用空间不能太大，否则每个节点都部署，存储压力会很大。

提高新能之对于高负载的场景：

存储使用default，

考虑延长刷新时间，默认是1s，设置为10s~30s，减少I/O压力；

优化线程池，注意大多数情况下默认配置是OK的，当且仅当主机计算能力有富余，同时操作有队列（有积压）的情况下，需要考虑调整线程池；

控制合并过程，主要控制段（segment）的大小，段是Lucene里面的物理存储单元，段越小，导致段很多，会导致查询变慢，内存使用量增加，但是索引会变得很快；如果你希望加快查询那么控制段的大小在一个相对较大的程度，这样会减少段的数量；

限流，可以控制I/O流量；

分布式，通过分布式，比如分片来减轻存储的压力；

提高性能之对于高频查询的场景：

尽量多利用缓存，比如过滤器缓存（倒排索引），分片缓存（非倒排索引）；

使用路由；减少因为合并各方数据浪费的时间；

提高性能之对于高索引场景：

批量索引，注意控制段的大小，不要过大。