如何配置Elasticsearch集群的Zen发现机制

Elasticsearch

集群的

Zen

发现机制配置指南

在大规模的分布式系统中，节点间的发现机制是非常关键的一部分。Elasticsearch

集群的默认发现机制是

Zen

Discovery，它提供了多播和单播两种发现方式，能够很好地应对各种复杂的情况，如节点失效、网络分区等。以下是关于如何配置

Elasticsearch

集群的

Zen

发现机制的一些详细信息。

Zen

Discovery

实现机制

Zen

Discovery

是

Elasticsearch

的内置机制，用于节点发现。所有节点间通讯必须使用

transport

模块来完成。集群中的节点相互发现集群负责

master

选举。Master

选举是由

mastereligible

节点发起的，当一个

mastereligible

节点发现满足以下条件的时候，发起选举：①本

mastereligible

不是

master；②本

mastereligible

节点通过

Zen

模块的

ping

操作询问其他已知节点，如果

ping

成功，则发起选举。

Zen

Discovery

使用***节点（seednodes）列表来开始发现过程。在启动时，或者在选举新主节点的时候，Elasticsearch

会尝试连接到其列表中的每个***节点，并与他们进行类似

'闲聊'

的对话，以查找其他节点并构建集群的完整成员图。

Zen

Discovery

配置详解

多播发现：这种方式通过向其他节点发送一个或多个多播请求来实现，存在的节点将会接收并且响应。提供下面的一组配置，以

`discovery.zen.ping.multicast`

前缀：

`group`：默认值为

`224.2.2.4`。

`port`：默认值为

`54328`。

`ttl`：多播消息的

ttl。默认为

`3`。

单播发现：依赖

transport

模块实现。注意

`port`

默认应该是

`9300`，不是

`9200`，因为使用的是

tranposrt。

主节点选举：这是自动完成的。`discovery.zen.ping_timeout`（默认

`3`

秒）的配置用于处理网络速度慢或网络拥塞的场景。

错误检测：第一种是在主节点上，用于

ping

所有的其他集群节点，并验证它们是否存活。下面是错误检测的相关配置，以

`discovery.zen.fdprefix`

为前缀：

`ping_interval`：节点

ping

的频率。默认为

`1`

秒。

`ping_timeout`：等待节点响应的超时时间，默认为

`30`

秒。

`ping_retries`：ping

失败/超时重试次数。默认为

`3`。

外部多播：多播发现也支持用外部多播请求来发现节点。外部客户端可以发送多播

IP/group

和端口请求，格式为：{request:{cluster_name:test_cluster}}。返回的响应信息格式和节点信息的返回格式类似（仅仅是节点级别的信息，也就是包含

transport/***

地址，以及节点属性）。

注意事项

内存设置：Elasticsearch

和

Lucene

都是

J***a

语言编写，这意味着我们必须注意堆内存的设置。Elasticsearch

可用的堆越多，它可用于过滤器(filter)和其他缓存的内存也就越多，更进一步讲可以提高查询性能。但请注意，过多的堆可能会使垃圾回收暂停时间过长。

CPU

设置：运行复杂的缓存查询、密集写入数据都需要大量的

CPU，因此选择正确的查询类型以及渐进的写入策略至关重要。

分片数设置：分片是

Elasticsearch

在集群内分发数据的单位。集***生故障再恢复平衡的速度取决于分片的大小、分片数量、网络以及磁盘性能。

副本数设置：Elasticsearch

通过副本实现集群的高可用性，数据在数据节点之间***，以实现主分片数据的备份，因此即便部分节点因异常下线也不会导致数据丢失。默认情况下，副本数为

1，但可以根据产品高可用要求将其增加。

希望以上信息能帮助您更好地理解

Elasticsearch

集群的

Zen

发现机制及其配置方法。