ElasticSearch分片分配异常导致查询延迟暴涨的系统级优化思路

Elasticsearch 分片分配异常导致查询延迟暴涨的系统级优化思路

大家好，今天我们来探讨一个常见的 Elasticsearch 性能问题：分片分配异常导致查询延迟暴涨。这个问题往往会给业务带来严重的影响，因此我们需要深入理解其原因，并掌握有效的优化思路。

一、问题根源：分片分配的本质与常见异常

Elasticsearch 的核心在于分布式架构，而分片是其数据管理的最小单元。每个索引会被拆分成多个分片，这些分片可以分布在集群中的不同节点上。这种设计提高了数据的存储能力和查询吞吐量。

1.1 分片分配机制

Elasticsearch 的分片分配由 Master 节点负责。Master 节点根据集群状态、节点资源、分配策略等因素，决定将哪些分片分配到哪个节点。

主要涉及几个关键概念：

• 分片（Shard）: 索引数据的逻辑划分，分为主分片（Primary Shard）和副本分片（Replica Shard）。
• 节点（Node）: Elasticsearch 集群中的一个服务器实例。
• 集群状态（Cluster State）: 集群中所有节点和索引的元数据信息。
• 分配器（Allocator）: 负责决定将分片分配到哪个节点。

1.2 常见分片分配异常

以下是一些常见的导致查询延迟的分片分配异常：

• 未分配分片（Unassigned Shards）: 由于节点故障、资源不足、配置错误等原因，部分分片未能成功分配到节点。这会导致查询无法访问完整的数据，从而降低查询效率。
• 过度分配（Over-allocated Shards）: 某个节点上的分片过多，导致节点负载过高，影响查询性能。
• 不均衡分配（Uneven Shard Distribution）: 分片在节点间的分布不均衡，部分节点压力过大，而其他节点资源闲置。
• 分片初始化延迟（Delayed Shard Initialization）: 新节点加入集群或节点重启后，分片的初始化过程耗时过长。
• 频繁的分片迁移（Shard Relocation Storm）: 集群状态不稳定，导致分片频繁地在节点间迁移，消耗大量资源。

1.3 异常导致查询延迟的原因

• 数据不完整: 未分配分片意味着查询无法访问全部数据，必须等待分片恢复才能返回完整结果。
• 节点过载: 过度分配和不均衡分配导致部分节点成为瓶颈，查询请求的处理速度受到限制。
• 资源竞争: 分片初始化和迁移会消耗大量的 CPU、IO、网络资源，与查询请求形成竞争，导致查询延迟增加。

二、诊断与排查：快速定位问题根源

在优化之前，我们需要准确地诊断问题，找出导致分片分配异常的根本原因。

2.1 利用 Elasticsearch API 监控集群状态

Elasticsearch 提供了丰富的 API 接口，用于监控集群状态和性能。以下是一些常用的 API：

• _cluster/health: 查看集群的整体健康状况，包括状态（green, yellow, red）、未分配分片数量等。

  GET _cluster/health

  返回结果示例：

  {
    "cluster_name" : "my-cluster",
    "status" : "yellow",  // 如果是red或者yellow，就需要关注了
    "timed_out" : false,
    "number_of_nodes" : 3,
    "number_of_data_nodes" : 3,
    "active_primary_shards" : 5,
    "active_shards" : 10,
    "relocating_shards" : 0,
    "initializing_shards" : 0,
    "unassigned_shards" : 1, // 关键指标：未分配分片数量
    "delayed_unassigned_shards" : 0,
    "number_of_pending_tasks" : 0,
    "number_of_in_flight_fetch" : 0,
    "task_max_waiting_in_queue_millis" : 0,
    "active_shards_percent_as_number" : 100.0
  }

• _cat/shards: 查看每个分片的详细信息，包括所在节点、状态、大小等。

  GET _cat/shards?v

  返回结果示例：

  index        shard prirep state   docs  store ip           node
  my-index-000001 0     p      STARTED   1000 500b 192.168.1.1 node-1
  my-index-000001 0     r      STARTED   1000 500b 192.168.1.2 node-2
  my-index-000001 1     p      STARTED   1200 600b 192.168.1.2 node-2
  my-index-000001 1     r      STARTED   1200 600b 192.168.1.3 node-3
  my-index-000001 2     p      STARTED   1500 700b 192.168.1.3 node-3
  my-index-000001 2     r      UNASSIGNED

• _cat/nodes: 查看每个节点的资源使用情况，包括 CPU、内存、磁盘等。

  GET _cat/nodes?v

  返回结果示例：

  node.role master cpu load_1m load_5m load_15m heap.percent ram.percent disk.indices disk.total disk.used ip           node.name
  mdi      *      22  0.10    0.15    0.12    30         60        102gb        250gb     148gb    192.168.1.1 node-1
  mdi      -      18  0.05    0.08    0.07    25         55        95gb         250gb     155gb    192.168.1.2 node-2
  mdi      -      20  0.08    0.12    0.10    28         58        100gb        250gb     150gb    192.168.1.3 node-3

• _cluster/allocation/explain: 解释分片未分配的原因。

  GET _cluster/allocation/explain
  {
    "index": "my-index-000001",
    "shard": 2,
    "primary": false
  }

  返回结果会详细说明为什么该分片没有被分配，例如：

  {
    "index" : "my-index-000001",
    "shard" : 2,
    "primary" : false,
    "current_state" : "unassigned",
    "unassigned_info" : {
      "reason" : "NODE_LEFT",
      "at" : "2023-10-27T10:00:00.000Z",
      "details" : "node_left[node-id]",
      "last_allocation_status" : "no_attempt"
    },
    "can_allocate" : "no",
    "allocate_explanation" : "cannot allocate because allocation is not permitted on stale nodes",
    "node_allocation_decisions" : [
      {
        "node_id" : "node-id",
        "node_name" : "node-name",
        "transport_address" : "192.168.1.1:9300",
        "node_attributes" : {
          "ml.machine_memory" : "16777216000",
          "xpack.installed" : "true",
          "transform.node" : "true"
        },
        "can_allocate" : "no",
        "node_version" : "7.17.6",
        "decisions" : [
          {
            "decision" : "NO",
            "explanation" : "the node is stale"
          }
        ]
      }
    ]
  }

2.2 分析 Elasticsearch 日志

Elasticsearch 的日志记录了集群的各种事件，包括节点状态变化、分片分配情况、错误信息等。通过分析日志，可以深入了解问题的细节。

• GC 日志: 排查由于 JVM 垃圾回收导致的长时间停顿。
• Slow Log: 记录执行时间超过阈值的查询和索引操作。
• Elasticsearch 集群日志: 记录集群状态变化，分片分配情况，节点加入离开等重要事件。

2.3 借助监控工具

除了 Elasticsearch 提供的 API 和日志，还可以使用专门的监控工具，例如：

• Elasticsearch Head: 一个 Web 界面，可以方便地查看集群状态、管理索引和分片。
• Kibana: Elastic Stack 的可视化工具，可以创建仪表盘，监控集群的各项指标。
• Prometheus + Grafana: 一套流行的监控解决方案，可以收集 Elasticsearch 的指标，并进行可视化展示。

2.4 诊断示例

假设通过 _cluster/health API 发现集群状态为 "yellow"，并且存在未分配分片。 接下来，可以使用 _cat/shards API 找到未分配的分片，然后使用 _cluster/allocation/explain API 解释未分配的原因。 如果 _cluster/allocation/explain 显示 "NODE_LEFT"，则说明可能是由于节点故障导致分片未分配。 同时，查看 Elasticsearch 的日志，可能会发现节点崩溃的异常信息。

三、优化策略：多维度提升系统性能

根据诊断结果，我们可以采取一系列优化策略，解决分片分配异常，提升系统性能。

3.1 解决未分配分片问题

• 节点故障恢复: 如果节点故障导致分片未分配，首先要尽快恢复故障节点。如果无法恢复，则需要从集群中移除该节点。

• 增加节点资源: 如果集群资源不足，导致无法分配分片，可以考虑增加节点数量，或者升级现有节点的硬件配置。

• 调整分配策略: Elasticsearch 提供了多种分片分配策略，可以根据实际情况进行调整。 例如，可以使用 cluster.routing.allocation.awareness.attributes 设置感知属性，将分片分配到具有特定属性的节点上。

  # elasticsearch.yml
  cluster.routing.allocation.awareness.attributes: rack_id

  然后，在节点上设置 rack_id 属性：

  # elasticsearch.yml
  node.attr.rack_id: rack-1

• 手动分配分片: 在紧急情况下，可以使用 _cluster/reroute API 手动分配分片。 但需要谨慎操作，避免造成数据丢失或损坏。

  POST _cluster/reroute
  {
    "commands": [
      {
        "allocate": {
          "index": "my-index-000001",
          "shard": 2,
          "node": "node-id",
          "allow_primary": true // 如果是主分片，需要设置为true
        }
      }
    ]
  }

3.2 平衡分片分布

• 调整分片数量: 过多的分片会增加集群的管理负担，过少的分片则可能导致节点负载不均衡。 需要根据数据量和集群规模，合理设置分片数量。 通常，建议每个节点的分片大小控制在 20-40GB 之间。

• 使用 Shard Filtering: 通过 index.routing.allocation.include, index.routing.allocation.exclude, index.routing.allocation.require 等设置，可以控制分片在哪些节点上分配。

  PUT my-index-000001/_settings
  {
    "index.routing.allocation.require.rack_id": "rack-1"
  }

• 使用 Forced Awareness: 强制 Elasticsearch 在分配分片时考虑特定的属性。

  # elasticsearch.yml
  cluster.routing.allocation.awareness.force.rack_id.values: rack-1,rack-2

3.3 优化索引设置

• 合理设置副本数量: 副本可以提高查询性能和可用性，但也会增加存储空间和索引开销。 需要根据实际需求，合理设置副本数量。 通常，建议至少设置一个副本。

• 使用合适的分析器（Analyzer）: 分析器决定了如何将文本分解成词项。 选择合适的分析器可以提高搜索精度和效率。 例如，对于中文文本，可以使用 ik_max_word 或 ik_smart 分析器。

  PUT my-index-000001
  {
    "settings": {
      "analysis": {
        "analyzer": {
          "my_analyzer": {
            "type": "custom",
            "tokenizer": "ik_max_word"
          }
        }
      }
    },
    "mappings": {
      "properties": {
        "title": {
          "type": "text",
          "analyzer": "my_analyzer"
        }
      }
    }
  }

• 优化 Mapping 设置: 合理设置字段类型，避免使用过于宽泛的类型。 例如，如果字段只需要存储数字，则应该使用 integer 或 long 类型，而不是 text 类型。 禁用不需要索引的字段，可以减少索引开销。

  PUT my-index-000001/_mapping
  {
    "properties": {
      "content": {
        "type": "text",
        "index": false  // 禁用索引
      }
    }
  }

3.4 优化查询语句

• 避免使用 script 查询: script 查询的性能较差，应尽量避免使用。

• 使用 filter 上下文: 对于不需要计算相关性的查询，应该使用 filter 上下文，而不是 query 上下文。 filter 上下文可以提高查询性能。

  GET my-index-000001/_search
  {
    "query": {
      "bool": {
        "filter": [
          {
            "term": {
              "status": "active"
            }
          }
        ]
      }
    }
  }

• 避免使用通配符查询（Wildcard Query）: 通配符查询的性能较差，应尽量避免使用。 如果必须使用，则应该尽量缩小通配符的范围。

• 使用缓存: Elasticsearch 提供了多种缓存机制，可以提高查询性能。 例如，可以使用 query_cache 缓存查询结果。

3.5 硬件优化

• 增加内存: 足够的内存可以减少 JVM 垃圾回收的频率，提高查询性能。
• 使用 SSD: SSD 的读写速度比机械硬盘快得多，可以显著提高查询性能。
• 优化网络: 确保节点之间的网络连接稳定可靠，避免网络延迟影响查询性能。

3.6 配置优化

• cluster.routing.allocation.disk.threshold_enabled: 默认情况下，Elasticsearch 会检查磁盘使用情况，如果磁盘使用率超过阈值，则会停止分配分片。 可以根据实际情况调整磁盘使用率阈值。
• cluster.routing.allocation.node_concurrent_recoveries: 控制每个节点可以同时进行的分片恢复操作的数量。 适当增加该值可以加快分片恢复速度。
• indices.recovery.max_bytes_per_sec: 控制分片恢复的带宽限制。 可以根据网络带宽情况调整该值。
• discovery.seed_hosts 和 cluster.initial_master_nodes: 正确配置这些参数可以确保节点能够正确发现彼此，并选举出 Master 节点。

四、代码示例：利用 Bulk API 提高索引效率

除了上述优化策略，还可以通过批量操作来提高索引效率。 Elasticsearch 提供了 Bulk API，可以将多个索引、更新或删除操作合并成一个请求，减少网络开销。

import org.elasticsearch.action.bulk.BulkRequest;
import org.elasticsearch.action.bulk.BulkResponse;
import org.elasticsearch.action.index.IndexRequest;
import org.elasticsearch.client.RequestOptions;
import org.elasticsearch.client.RestHighLevelClient;
import org.elasticsearch.common.xcontent.XContentType;

import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;

public class BulkIndexer {

    private final RestHighLevelClient client;

    public BulkIndexer(RestHighLevelClient client) {
        this.client = client;
    }

    public void indexDocuments(String indexName, List<Map<String, Object>> documents) throws IOException {
        BulkRequest bulkRequest = new BulkRequest();

        for (Map<String, Object> document : documents) {
            IndexRequest indexRequest = new IndexRequest(indexName)
                    .source(document, XContentType.JSON);
            bulkRequest.add(indexRequest);
        }

        BulkResponse bulkResponse = client.bulk(bulkRequest, RequestOptions.DEFAULT);

        if (bulkResponse.hasFailures()) {
            System.err.println("Bulk index failed: " + bulkResponse.buildFailureMessage());
        } else {
            System.out.println("Bulk index completed in " + bulkResponse.getTook());
        }
    }

    public static void main(String[] args) throws IOException {
        // 假设您已经创建了 RestHighLevelClient 实例
        RestHighLevelClient client = ElasticsearchClientFactory.createClient(); // 替换为您的客户端创建逻辑

        String indexName = "my-index-000001";

        // 创建一些示例文档
        List<Map<String, Object>> documents = new ArrayList<>();
        for (int i = 0; i < 1000; i++) {
            documents.add(Map.of("id", i, "title", "Document " + i, "content", "This is the content of document " + i));
        }

        BulkIndexer bulkIndexer = new BulkIndexer(client);
        bulkIndexer.indexDocuments(indexName, documents);

        client.close();
    }
}

在这个示例中，我们首先创建了一个 BulkRequest 对象，然后将多个 IndexRequest 对象添加到该请求中。 最后，我们使用 client.bulk() 方法执行批量索引操作。

五、预防措施：避免问题重演

除了解决现有问题，我们还应该采取预防措施，避免类似问题再次发生。

• 容量规划: 提前预估数据量和集群规模，合理规划集群容量。
• 监控告警: 建立完善的监控告警机制，及时发现和处理潜在问题。
• 定期维护: 定期检查集群状态，清理无用数据，优化索引设置。
• 升级版本: 及时升级到最新版本的 Elasticsearch，可以获得更好的性能和安全性。
• 备份策略: 建立完善的备份策略，防止数据丢失。

不同场景下的优化方案表格

场景	问题描述	优化方案
节点故障导致分片未分配	节点宕机，导致其上的分片无法访问。	1. 尽快恢复故障节点。 2. 如果无法恢复，从集群移除故障节点。 3. 检查是否配置了足够的副本。
磁盘空间不足导致分片无法分配	磁盘使用率超过阈值， Elasticsearch 停止分配分片。	1. 增加磁盘空间。 2. 清理无用数据。 3. 调整 cluster.routing.allocation.disk.threshold_enabled 参数。
分片数量过多导致节点负载过高	每个节点上的分片数量过多，导致节点 CPU、内存、IO 压力过大。	1. 增加节点数量。 2. 减少每个索引的分片数量。 3. 调整 cluster.max_shards_per_node 参数（谨慎使用）。
查询语句性能差导致查询延迟	查询语句过于复杂，或者使用了不合适的查询方式，导致查询性能下降。	1. 优化查询语句，避免使用 script 查询、通配符查询等。 2. 使用 filter 上下文代替 query 上下文。 3. 使用缓存。
JVM 垃圾回收导致长时间停顿	JVM 垃圾回收频繁发生，导致 Elasticsearch 进程长时间停顿。	1. 增加 JVM 堆大小。 2. 优化代码，减少对象创建。 3. 选择合适的垃圾回收器。 4. 分析 GC 日志，找出性能瓶颈。
索引设置不合理导致索引和查询性能下降	索引 Mapping 设置不合理，或者使用了不合适的分析器，导致索引和查询性能下降。	1. 合理设置字段类型。 2. 禁用不需要索引的字段。 3. 选择合适的分析器。 4. 优化索引模板。
网络延迟导致节点间通信缓慢	节点之间的网络连接不稳定，或者网络延迟过高，导致节点间通信缓慢。	1. 检查网络连接，确保稳定可靠。 2. 优化网络配置，减少网络延迟。 3. 使用更快的网络设备。
分片恢复速度慢导致集群恢复时间过长	节点重启或新节点加入后，分片恢复过程耗时过长。	1. 增加 cluster.routing.allocation.node_concurrent_recoveries 参数。 2. 增加 indices.recovery.max_bytes_per_sec 参数。 3. 使用更快的磁盘。
集群状态不稳定导致分片频繁迁移	集群状态频繁变化，导致分片在节点间频繁迁移。	1. 检查集群配置，确保正确。 2. 调整 cluster.routing.allocation.cluster_concurrent_rebalance 参数。 3. 检查节点资源使用情况，避免节点过载。

分片分配异常解决的关键

总而言之，解决 Elasticsearch 分片分配异常导致查询延迟暴涨的问题，需要我们深入理解分片分配机制，准确诊断问题根源，并采取多维度的优化策略。 此外，预防措施也至关重要，可以避免类似问题再次发生。只有这样，才能确保 Elasticsearch 集群的稳定性和性能。 持续的监控、分析和优化是维护 Elasticsearch 集群健康的关键。