Elasticsearch 协调节点：何时使用专用协调节点 ？

在 Elasticsearch 集群中，协调节点（Coordinating Node）是一个重要的角色，尤其在处理大规模数据和复杂查询时。

本文将以通俗易懂的方式，介绍什么是协调节点、专用协调节点（Coordinating Only Node, CO）的优势与成本、何时需要使用它们，以及如何正确配置和使用，避免潜在问题。

1、什么是协调节点？

协调节点是 Elasticsearch 集群中负责处理 HTTP(S) 请求的节点，主要包括索引请求（如新增、更新文档）和搜索请求（如查询数据）。

图片来自网络

在 Elasticsearch 中，每个节点默认都能充当协调节点，因为它们都可以接收和处理外部请求。

然而，专用协调节点是指那些不存储数据（非数据节点）、不参与主节点选举（非主节点）的节点。它们的唯一职责是处理 HTTP 请求，并将这些请求分发到集群中的其他节点（比如数据节点）来完成实际的工作。

简单来说，专用协调节点就像一个“前台接待员”，负责接收客户（HTTP 请求）的需求，分派任务给后端（数据节点或主节点），并整理返回的结果。如下图所示。

2、专用协调节点的优势

为什么需要专门设置协调节点，而不是让数据节点直接处理请求？

以下是协调节点的主要优势：

2.1 减轻数据节点和主节点的负担

索引和搜索请求会消耗大量的内存（Heap）、CPU 和网络资源。

例如，搜索请求需要合并多个分片的结果，索引请求需要协调主分片和副本分片的写入。

如果数据节点同时处理这些请求，可能会导致性能瓶颈甚至节点不稳定。

协调节点将这些任务“剥离”出来，让数据节点专注于存储和查询分片级数据。

2.2 降低请求延迟

在高并发场景下，协调节点可以有效分担请求处理压力，减少数据节点的资源竞争，从而降低请求的最大和平均延迟。

2.3 简化客户端配置

当集群规模扩大（比如新增数据节点）时，客户端只需与协调节点通信，无需频繁更新目标节点的配置。如果使用负载均衡器，协调节点也能简化其配置，始终指向固定的节点集合。

3、搜索和索引请求的处理流程

为了更好地理解协调节点的作用，我们先来看看 Elasticsearch 如何处理搜索和索引请求。

3.1 搜索请求的流程

1.查询阶段（Query Phase）

协调节点收到搜索请求后，会确定需要查询哪些索引，并将请求分发到相关索引的每个分片（可以是主分片或副本分片）。

每个分片返回符合条件的文档 ID 和相关性得分（最多返回请求中指定的“size”数量）。

2.获取阶段（Fetch Phase）

协调节点对所有分片的返回结果进行合并、排序，选出排名靠前的文档（按相关性得分），然后从相关分片中获取完整的文档内容。

最后，协调节点将整理好的结果返回给客户端。

这个过程需要协调节点消耗大量内存来合并和排序结果，尤其在查询复杂或返回文档数量多时，资源占用会显著增加。

3.2 索引请求（特指写入、更新）的流程

• 1.协调节点收到索引请求（比如新增一个文档）后，会根据文档的 ID 或路由规则，确定目标主分片。

• 2.协调节点将请求转发给主分片，主分片完成写入后，再将数据同步到所有副本分片。

• 3.如果是批量索引请求（Bulk Request），协调节点需要为每个文档重复上述过程，并跟踪每个操作的结果，生成最终的批量响应。

索引请求同样会占用协调节点的内存和 CPU，尤其是批量操作时，协调节点的负担会显著增加。

4、使用专用协调节点的成本

虽然协调节点能带来显著的好处，但引入它们也有一定的成本：

4.1.集群状态同步的开销

每个 Elasticsearch 节点（包括协调节点）都需要维护一份最新的集群状态副本。

主节点每次更新集群状态时，都需要通知所有节点并等待确认。协调节点的加入会增加状态同步的延迟，尤其在集群规模较大时。

4.2.硬件资源投入

协调节点需要独立的硬件资源，包括 CPU、内存和网络带宽。确定这些节点的配置（比如 CPU 核心数、堆内存大小）需要仔细规划，以确保性能匹配需求。

4.3 何时使用专用协调节点？

是否需要协调节点取决于收益是否大于成本。

以下是一些常见的场景，提示你可能需要引入协调节点：

但，切记：不是协调节点越多越好。

文章特殊原因发布一上午就删除了，原文内容：https://t.zsxq.com/cq9mx

如果你的查询涉及大量分片、复杂聚合，或者有频繁的批量索引操作，协调节点能有效提升性能。

4.4 影响决策的因素

• 数据节点数量和规模

节点越多，协调任务的复杂度越高。

• 文档和查询的复杂度

复杂查询（如聚合）或大文档会增加协调节点的负担。

• 请求的突发性

如果请求量在某些时段突然激增，协调节点可以缓解压力。

• 分片数量

索引分片过多会导致协调节点需要合并更多结果，增加资源消耗。

• 测试与监控

没有通用的标准来决定是否需要协调节点以及需要多少个。

最佳实践是在测试环境中模拟负载，使用工具如 ES Rally 来评估不同配置下的查询和索引吞吐量，找到最优解。

5、如何使用专用协调节点？

如果你决定引入协调节点，以下是配置和使用的步骤：

5.1 确定协调节点的数量和规模

至少部署 2 个协调节点以确保冗余，防止单点故障。

根据请求的规模和频率，分配足够的 内存（用于合并搜索结果或处理批量请求）和 CPU（用于计算和网络通信）。

5.2.配置节点角色

在协调节点的配置文件中，设置 node.roles: [ ]，表示该节点不承担数据节点或主节点的职责，仅作为协调节点。

示例配置：

node.roles: [ ]

5.3.部署并加入集群

使用与现有节点相同的方式部署协调节点，确保它们成功加入集群并能接收请求。

5.4 调整客户端配置

将 HTTP 客户端的请求目标设置为协调节点的地址，建议通过负载均衡器以轮询（Round-Robin）方式分发请求，确保负载均衡。

5.4 监控性能

部署后，密切监控协调节点的性能指标（如 CPU 使用率、内存使用量、请求延迟），确保它们能有效处理请求。

6、注意事项：避免新的瓶颈

引入协调节点时，需要特别注意以下问题：

6.1 协调节点数量不足

如果协调节点数量太少或配置不足，可能成为新的性能瓶颈，导致数据节点资源未被充分利用。

建议根据负载测试结果，合理规划协调节点的规模和数量。

6.2.分片路由优化

如果希望利用节点级缓存提升性能，可以在搜索请求中添加 preference 参数，指定相同的客户端请求始终路由到相同的分片。例如：

GET /_search?preference=my-session-id

这对协调节点和数据节点都有效。

7、总结

专用协调节点是 Elasticsearch 集群优化的重要工具，特别适合大规模集群或高并发场景。

它们通过将 HTTP 请求处理从数据节点中分离出来，降低资源竞争，提升性能和稳定性。

然而，协调节点的引入需要权衡成本（如硬件投入和集群状态同步开销），并通过测试和监控找到最优配置。

如果你发现集群中的节点因处理复杂查询或批量索引而变得不稳定，或者请求延迟较高，不妨考虑引入协调节点。

通过合理规划和配置，它们将成为你的 Elasticsearch 集群性能提升的得力助手！

8、相关阅读

[1] https://medium.com/trendyol-tech/optimizing-elasticsearch-with-custom-routing-and-handling-routing-value-changes-25e5b0202c0c

[2] https://viblo.asia/p/setup-boilerplate-cho-du-an-nestjs-phan-13-tim-hieu-ve-elasticsearch-va-he-thong-cluster-7ymJXenaLkq

[3] https://opster.com/guides/elasticsearch/high-availability/coordinating-only-dedicated-coordinating-node/

[4] https://www.elastic.co/docs/reference/elasticsearch/configuration-reference/node-settings

[5]探究 | Elasticsearch集群规模和容量规划的底层逻辑

[6]干货 | Elasticsearch 8.X 节点角色划分深入详解

[7]牛逼！Elasticsearch 集群更换节点角色有了更快的方式