Elasticsearch搜索优化-自定义路由规划(routing)

一、背景与问题

在分布式系统中，Elasticsearch的分片机制是实现水平扩展的核心。默认情况下，Elasticsearch通过文档ID的哈希值计算分片位置，但这种机制存在两个关键问题：

1. 数据分布不均：当数据写入量不均衡时，部分分片可能负载过高
2. 查询性能瓶颈：未正确规划路由时，可能需要跨分片搜索，导致性能下降

在电商系统中，比如订单索引的场景，若按用户ID进行分片，可以实现：

• 用户相关查询的快速定位
• 按用户维度的聚合统计
• 避免跨分片的聚合操作

而默认的哈希路由可能导致热点分片，特别是在高频写入场景下。自定义路由规划正是为了解决这些核心问题而设计的机制。

二、基本原理

Elasticsearch的路由规划分为两个核心阶段：

1. 分片分配阶段

当创建索引时，通过number_of_shards参数定义分片数量。每个分片会分配到不同的节点，Elasticsearch通过以下公式计算分片ID：

shard_id = (hash(routing_value) + index_id) % number_of_shards

其中：

• hash(routing_value) 是通过_id或自定义路由值计算的哈希值
• index_id 是索引的唯一标识
• number_of_shards 是分片总数

2. 查询阶段

在搜索时，通过routing参数指定路由值，Elasticsearch会：

• 根据路由值计算目标分片
• 仅在该分片上执行查询
• 如果存在副本，则在所有副本分片上执行查询

这种机制可以有效减少跨分片的查询开销，特别是对于需要精确匹配的场景。

三、环境准备

1. 环境搭建

使用Docker快速搭建Elasticsearch集群：

docker run -d --name elasticsearch \
  -p 9200:9200 \
  -p 9300:9300 \
  -e "discovery.type=single-node" \
  -e "ES_JAVA_OPTS=-Xms512m -Xmx512m" \
  elasticsearch:8.6.2

2. 索引配置

创建带自定义路由字段的索引：

PUT /orders
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "order_id": { "type": "keyword" },
      "user_id": { "type": "keyword" },
      "status": { "type": "keyword" }
    }
  }
}

注意：自定义路由字段需要在mappings中定义，但不需要显式声明为routing字段。

四、核心实现

1. 基础路由使用

插入文档时指定路由值：

POST /orders/_doc
{
  "order_id": "20231001001",
  "user_id": "user_1001",
  "status": "completed"
}

默认情况下，Elasticsearch会使用文档的_id计算分片。若需要自定义路由值，可以使用_routing参数：

POST /orders/_doc?routing=user_1001
{
  "order_id": "20231001001",
  "user_id": "user_1001",
  "status": "completed"
}

这个路由值将影响分片分配，但不会改变文档的_id。

2. 多字段路由策略

当需要复合路由时，可以使用_routing字段：

POST /orders/_doc
{
  "order_id": "20231001001",
  "user_id": "user_1001",
  "status": "completed",
  "_routing": "user_1001"
}

注意：字段名必须为_routing，且不能包含特殊字符。

3. 查询时的路由参数

在查询时指定路由值可以精确控制搜索范围：

GET /orders/_search
{
  "query": {
    "match": {
      "user_id": "user_1001"
    }
  },
  "routing": "user_1001"
}

这种模式特别适合按业务维度过滤的场景。

五、完整案例

1. 电商订单系统场景

假设我们有如下业务需求：

• 按用户ID分片
• 支持按用户ID查询订单
• 支持按用户ID聚合订单状态
• 避免跨分片的聚合操作

1. 索引创建

PUT /orders
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "order_id": { "type": "keyword" },
      "user_id": { "type": "keyword" },
      "status": { "type": "keyword" }
    }
  }
}

2. 数据插入

POST /orders/_doc?routing=user_1001
{
  "order_id": "20231001001",
  "user_id": "user_1001",
  "status": "completed"
}

POST /orders/_doc?routing=user_1002
{
  "order_id": "20231001002",
  "user_id": "user_1002",
  "status": "processing"
}

3. 查询操作

GET /orders/_search
{
  "query": {
    "match": {
      "user_id": "user_1001"
    }
  },
  "routing": "user_1001"
}

4. 聚合查询

GET /orders/_search
{
  "size": 0,
  "aggs": {
    "status_distribution": {
      "terms": {
        "field": "status"
      }
    }
  },
  "routing": "user_1001"
}

这个案例展示了自定义路由在业务场景中的典型应用，通过路由值确保所有相关数据集中在一个分片，避免了跨分片聚合的性能损耗。

六、源码解析

在Elasticsearch源码中，路由计算主要在IndexingOperation类中实现。关键代码如下：

public class IndexingOperation {
    private final int shardCount;
    private final int indexId;
    
    public int calculateShardId(String routingValue) {
        int hash = Hashing.murmur3_128().hashUnencodedUtf8(routingValue).asInt();
        return (hash + indexId) % shardCount;
    }
}

这个算法保证了：

• 相同路由值的文档始终分配到相同分片
• 分片分配与分片数量相关
• 可以通过改变indexId实现索引级别的分片控制

七、进阶使用

1. 动态路由策略

在Kibana中可以创建路由策略：

PUT /_cluster/settings
{
  "persistent" : {
    "indices" : {
      "routing" : {
        "allocation" : {
          "exclude" : {
            "node" : "master"
          }
        }
      }
    }
  }
}

2. 分片分配过滤

通过设置index.routing.allocation.include控制分片分配：

PUT /orders
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "index.routing.allocation.include": "node_1"
  }
}

3. 多字段路由

在插入文档时指定多个路由字段：

POST /orders/_doc
{
  "order_id": "20231001001",
  "user_id": "user_1001",
  "status": "completed",
  "_routing": "user_1001"
}

八、性能与工程实践

1. 性能优化

• 分片数量选择：建议保持分片数量在10-50个之间
• 路由值设计：避免使用随机值，应选择具有业务意义的字段

• 监控分片分布：

  GET /_cat/shards?v

2. 安全风险

• 路由字段敏感性：避免使用包含敏感信息的字段作为路由值
• 分片隔离：通过index.routing.allocation控制分片分配

3. 一致性保障

在更新文档时，必须使用相同的路由值：

POST /orders/_doc?routing=user_1001
{
  "order_id": "20231001001",
  "user_id": "user_1001",
  "status": "cancelled"
}

九、常见问题与踩坑

1. 错误示例

POST /orders/_doc
{
  "order_id": "20231001001",
  "user_id": "user_1001"
}

问题：未指定路由值导致分片分配不均

2. 常见错误

• 路由值未正确设置：导致文档分散在多个分片
• 未指定routing参数：查询时可能需要跨分片搜索
• 分片数量设置不当：影响集群性能

3. 解决方案

• 使用_routing参数显式指定路由值
• 监控分片分布情况
• 根据业务需求调整分片数量

十、最佳实践

1. 应该使用自定义路由的场景

• 需要按业务维度进行数据隔离
• 需要支持精确查询和聚合
• 需要控制数据分布
• 需要避免跨分片的性能损耗

2. 不应该使用的场景

• 数据分布不均无法解决
• 路由字段频繁变化
• 需要跨分片的全局聚合
• 路由策略导致分片数量过多

十一、总结

自定义路由规划是Elasticsearch实现搜索优化的重要手段，通过合理规划路由策略可以显著提升查询性能和数据分布质量。在实际应用中需要结合业务需求选择合适的路由字段，避免常见的配置错误。对于需要精确控制数据分布的场景，自定义路由是必须的工具，但也要注意避免过度设计带来的复杂性。在实施过程中需要重点关注分片分布、查询性能和数据一致性，通过监控和调优确保系统稳定运行。