25、Elasticsearch 集群深入解析

Elasticsearch 集群深入解析

1. 术语查找缓存设置

Elasticsearch 允许我们配置术语查找机制使用的缓存。要控制该缓存，可以在 elasticsearch.yml 文件中设置以下属性：
- indices.cache.filter.terms.size ：默认值为 10MB，指定 Elasticsearch 可用于术语查找缓存的最大内存量。对于大多数情况，默认值应该足够；但如果要加载大量数据，可以增加该值。
- indices.cache.filter.terms.expire_after_access ：指定条目最后一次访问后应过期的最长时间，默认禁用。
- indices.cache.filter.terms.expire_after_write ：指定条目放入缓存后应过期的最长时间，默认禁用。

2. 节点发现

当启动 Elasticsearch 节点时，节点首先会寻找具有相同集群名称且可见的主节点。如果找到主节点，该节点将加入已形成的集群；如果未找到，在配置允许的情况下，该节点将被选为新的主节点。这个形成集群和查找节点的过程称为发现。负责发现的模块有两个主要目的：选举主节点和发现集群内的新节点。

2.1 发现类型

默认情况下，不安装额外插件时，Elasticsearch 支持 zen 发现，提供组播（Multicast）和单播（Unicast）发现。
- 组播 ：在一次传输中将消息发送给一组计算机。使用组播发现时，Elasticsearch 会尝试查找所有能够接收并响应组播消息的节点。
- 单播 ：通过网络将单个消息一次发送到单个主机。使用单播方法时，需要提供集群中的至少一些主机，节点将尝试连接这些主机。

选择组播还是单播时，需要考虑网络是否支持组播消息。如果支持，使用组播会更方便；如果不支持，则应使用单播发现。此外，出于安全考虑，若要运行多个集群或开发机器在同一网络中，单播发现也是不错的选择。在 Linux 系统中，可以使用 ifconfig 命令检查网络接口（通常为 eth0 ）是否支持组播，如果支持，命令响应中会显示 MULTICAST 属性。

2.2 主节点

发现的主要目的之一是选择一个主节点来管理集群。主节点会检查其他节点是否响应（其他节点也会向主节点发送心跳），并接受新节点加入集群。如果主节点与集群断开连接，剩余节点会自动从自身中选举出新的主节点。

2.3 配置主节点和数据节点

默认情况下，Elasticsearch 允许每个节点既是主节点又是数据节点。但在处理大量数据时，可能需要将节点分为仅存储数据的工作节点和仅处理请求、管理集群的主节点。
- 仅存储数据的节点 ：在 elasticsearch.yml 配置文件中添加以下属性：

node.master: false
node.data: true

• 仅作为主节点的节点 ：在 elasticsearch.yml 配置文件中添加以下属性：

node.master: true
node.data: false

2.4 主节点选举配置

为避免出现脑裂（split - brain）情况，即集群因网络故障等原因分裂成多个具有相同名称和主节点的子集群，Elasticsearch 提供了 discovery.zen.minimum_master_nodes 属性。该属性定义了形成集群所需连接的符合主节点条件的最小节点数。例如，一个由 10 个节点组成的集群，将 discovery.zen.minimum_master_nodes 设置为 6（总节点数的 50% + 1），即使 3 个节点断开连接，也能确保只有一个集群正常运行，因为断开的 3 个节点数量小于 6，无法选举新的主节点。

2.5 设置集群名称

如果不在 elasticsearch.yml 文件中设置 cluster.name 属性，Elasticsearch 将使用默认值 elasticsearch 。建议设置不同的集群名称，特别是在同一网络中运行多个集群时，否则不同集群的节点可能会错误地加入同一个集群。

2.6 配置组播

组播是默认的 zen 发现方法，除了通用设置外，还可以控制以下四个属性：
- discovery.zen.ping.multicast.group ：组播请求使用的组地址，默认值为 224.2.2.4 。
- discovery.zen.ping.multicast.port ：组播通信使用的端口，默认值为 54328 。
- discovery.zen.ping.multicast.ttl ：组播请求的有效时间，默认值为 3 秒。
- discovery.zen.ping.multicast.address ：Elasticsearch 应绑定的地址，默认值为 null ，表示尝试绑定操作系统可见的所有网络接口。

若要禁用组播，需在 elasticsearch.yml 文件中添加 discovery.zen.ping.multicast.enabled 属性并将其值设置为 false 。

2.7 配置单播

使用单播时，需要在 elasticsearch.yml 配置文件中添加 discovery.zen.ping.unicast.hosts 属性，指定集群中的主机。例如：

discovery.zen.ping.unicast.hosts: 192.168.2.1:9300, 192.168.2.2:9300, 192.168.2.3:9300

也可以定义 Elasticsearch 可使用的端口范围，例如：

discovery.zen.ping.unicast.hosts: 192.168.2.1:[9300 - 9399], 192.168.2.2:[9300 - 9399], 192.168.2.3:[9300 - 9399]

使用单播时，务必将 discovery.zen.ping.multicast.enabled 属性设置为 false 。

2.8 节点的 ping 设置

除了上述设置，还可以控制或更改默认的 ping 配置。ping 是节点之间发送的信号，用于检查节点是否运行和响应。主节点会向集群中的所有其他节点发送 ping 信号，其他节点也会向主节点发送 ping 信号。可以设置以下属性：
- discovery.zen.fd.ping_interval ：默认值为 1 秒，指定节点之间 ping 的频率。
- discovery.zen.fd.ping_timeout ：默认值为 30 秒，定义节点在将另一个节点视为无响应之前等待 ping 消息响应的时间。
- discovery.zen.fd.ping_retries ：默认值为 3，指定在将节点视为不工作之前应进行的重试次数。

如果网络存在问题或节点需要更多时间来响应 ping 消息，可以根据实际情况调整这些值。

3. 网关和恢复模块

除了索引和其中的数据，Elasticsearch 还需要保存元数据，如类型映射和索引级设置。这些信息需要持久化存储，以便在集群恢复时读取，因此引入了网关模块，可以将其视为集群数据和元数据的安全存储库。每次启动集群时，会从网关读取所需数据；对集群进行更改时，也会使用网关模块进行持久化。

3.1 网关

要设置使用的网关类型，需要在 elasticsearch.yml 配置文件中添加 gateway.type 属性并将其设置为 local 。目前，Elasticsearch 建议使用本地网关类型（默认值），过去的其他网关类型（如 fs 、 hdfs 和 s3 ）已被弃用，未来版本将移除。本地网关类型将索引及其元数据存储在本地文件系统中，与其他网关相比，写入操作不是异步执行的，写入成功后可以确保数据已写入网关。

3.2 恢复控制

除了选择网关类型，Elasticsearch 还允许配置初始恢复过程的启动时间。恢复是初始化所有分片和副本、从事务日志中读取所有数据并将数据应用到分片的过程，是启动 Elasticsearch 所需的过程。

例如，对于一个由 10 个节点组成的集群，可以在 elasticsearch.yml 文件中设置以下属性：

gateway.recover_after_nodes: 8
gateway.recover_after_time: 10m
gateway.expected_nodes: 10

• gateway.recover_after_nodes ：指定在集群中达到该节点数时开始恢复过程。
• gateway.recover_after_time ：指定在达到 gateway.recover_after_nodes 指定的节点数后，等待多长时间开始恢复过程。
• gateway.expected_nodes ：告知 Elasticsearch 预期的节点数量。

3.3 额外的网关恢复选项

Elasticsearch 还提供了一些额外的控制选项：
- gateway.recover_after_master_nodes ：与 gateway_recover_after_nodes 类似，但只考虑符合主节点条件的节点数量。
- gateway.recover_after_data_nodes ：与 gateway_recover_after_nodes 类似，但指定在恢复开始前集群中应存在的数据节点数量。
- gateway.expected_master_nodes ：与 gateway.expected_nodes 类似，但指定预期的符合主节点条件的节点数量。
- gateway.expected_data_nodes ：与 gateway.expected_nodes 类似，但指定预期的数据节点数量。

4. 为高查询和索引吞吐量准备 Elasticsearch 集群

为了实现 Elasticsearch 的高查询和索引吞吐量，需要关注以下两个重要的缓存机制。

4.1 过滤器缓存

过滤器缓存负责缓存查询中使用的过滤器，能够快速检索信息。配置得当的话，它可以显著提高查询效率，特别是对于包含已执行过的过滤器的查询。Elasticsearch 包含两种类型的过滤器缓存：
- 节点过滤器缓存 ：默认类型，在单个节点上的所有索引之间共享，可以配置使用特定数量的内存或 Elasticsearch 总内存的百分比。通过在 elasticsearch.yml 文件中设置 indices.cache.filter.size 属性来指定。
- 索引过滤器缓存 ：一般建议使用节点级过滤器缓存，因为很难预测每个索引的过滤器缓存的最终大小，通常不知道给定节点上会有多少个索引。

4.2 字段数据缓存和断路器

字段数据缓存主要在查询对字段进行排序或分面时使用。Elasticsearch 会将这些字段的数据加载到内存中，以便按文档快速访问值。构建字段数据缓存的成本较高，因此建议分配足够的内存，确保数据加载后能一直保留在内存中。

Elasticsearch 集群深入解析（续）

5. 缓存与性能优化

在前面我们已经了解了过滤器缓存和字段数据缓存，下面我们通过一个表格来更清晰地对比它们的特点和配置方式：
| 缓存类型 | 特点 | 配置方式 |
| — | — | — |
| 过滤器缓存 | 负责缓存查询中使用的过滤器，可快速检索信息，提高查询效率 | 节点过滤器缓存：在 elasticsearch.yml 中设置 indices.cache.filter.size ；索引过滤器缓存：不建议使用，难以预测最终大小 |
| 字段数据缓存 | 用于查询排序或分面时加载字段数据到内存，按文档快速访问值 | 需分配足够内存确保数据加载后保留在内存中 |

为了更直观地理解节点间的交互和缓存的作用，我们可以用 mermaid 流程图来展示：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(查询请求):::process --> B{是否有缓存}:::process
    B -->|是| C(从缓存获取数据):::process
    B -->|否| D(执行查询):::process
    D --> E(更新缓存):::process
    E --> F(返回结果):::process
    C --> F

这个流程图展示了查询请求到达后，先检查是否有缓存，如果有则直接从缓存获取数据，没有则执行查询并更新缓存，最后返回结果。

6. 集群配置总结与最佳实践

在前面的内容中，我们详细介绍了 Elasticsearch 集群的各个方面的配置，下面我们总结一些最佳实践：
- 术语查找缓存 ：根据实际数据量调整 indices.cache.filter.terms.size ，如果数据量小，使用默认 10MB 即可；数据量大则适当增加。
- 节点发现 ：
- 网络支持组播时，可使用组播发现，但要注意安全问题；不支持则使用单播。
- 设置合适的 discovery.zen.minimum_master_nodes 避免脑裂，建议设置为总节点数的 50% + 1。
- 明确设置 cluster.name ，避免不同集群节点误加入。
- 网关和恢复模块 ：使用本地网关类型 gateway.type: local ，合理配置恢复相关属性，如 gateway.recover_after_nodes 、 gateway.recover_after_time 和 gateway.expected_nodes 。
- 缓存配置 ：优先使用节点过滤器缓存，合理分配内存；为字段数据缓存分配足够内存。

7. 常见问题及解决方法

在使用 Elasticsearch 集群过程中，可能会遇到一些常见问题，下面我们列出并给出解决方法：
| 问题 | 现象 | 解决方法 |
| — | — | — |
| 脑裂问题 | 集群分裂成多个具有相同名称和主节点的子集群 | 设置合适的 discovery.zen.minimum_master_nodes 属性 |
| 缓存性能不佳 | 查询速度慢，频繁执行相同查询仍无明显提升 | 检查缓存配置，调整 indices.cache.filter.size 等参数 |
| 网络连接问题 | 节点无法加入集群或频繁断开连接 | 检查网络设置，调整节点的 ping 配置，如 discovery.zen.fd.ping_interval 、 discovery.zen.fd.ping_timeout 和 discovery.zen.fd.ping_retries |

8. 性能监控与调优

为了确保 Elasticsearch 集群的高性能运行，需要进行性能监控和调优。可以使用 Elasticsearch 自带的监控工具，如 Elasticsearch Monitoring，它可以监控集群的各项指标，如节点状态、索引大小、查询响应时间等。

根据监控结果进行调优的步骤如下：
1. 收集性能数据：通过监控工具收集集群的各项性能指标。
2. 分析数据：找出性能瓶颈，如某个节点负载过高、缓存命中率低等。
3. 调整配置：根据分析结果调整相关配置，如增加缓存大小、调整节点角色等。
4. 验证效果：再次监控性能指标，验证调整是否有效。

通过以上步骤，可以不断优化 Elasticsearch 集群的性能，使其更好地满足业务需求。

9. 未来趋势与展望

随着数据量的不断增长和业务需求的不断变化，Elasticsearch 也在不断发展。未来，我们可以期待以下趋势：
- 更强大的分布式性能 ：进一步优化集群的分布式架构，提高数据处理和查询的性能。
- 更好的安全机制 ：加强集群的安全防护，保障数据的安全性和隐私性。
- 与其他技术的集成 ：更好地与大数据、人工智能等技术集成，提供更丰富的功能。

总之，Elasticsearch 作为一款强大的开源搜索引擎和分布式数据存储系统，在未来将继续发挥重要作用，为企业和开发者提供更高效、更稳定的数据处理解决方案。