企业官网建设流程全解析

一、前言

在 ElasticSearch（ES）生产环境使用中，分片（Shard）是决定集群性能、稳定性、数据容量的核心组件。ES 作为分布式搜索引擎，通过分片实现数据水平拆分，通过副本实现高可用，合理的分片策略和数量配置，直接影响集群的查询速度、写入性能、故障恢复能力。

本文将系统梳理 ES 所有分片策略，手把手教你如何配置分片数、副本数，结合生产实践给出最优配置建议，帮助你避开 ES 分片配置的常见坑。

二、基础概念：ES 分片与副本

2.1 核心定义

1. 主分片（Primary Shard）
   索引的数据拆分单元，一个索引的数据会均匀分散到多个主分片中，每个主分片是一个独立的 Lucene 索引，支持单独的读写操作。

   • 作用：实现数据水平扩展，突破单节点存储/性能瓶颈
   • 特性：索引创建后，主分片数量无法修改（核心限制）

2. 副本分片（Replica Shard）
   主分片的备份数据，是主分片的完整拷贝。

   • 作用：提高查询并发能力、保障数据高可用（主分片故障时，副本会自动提升为主分片）
   • 特性：索引创建后，副本数量可动态修改

3. 分片总数公式
   单索引总分片数 = 主分片数 × (1 + 副本数)
   例：3主分片，1副本 → 总分片数=3×2=6

2.2 分片工作流程图

三、ElasticSearch 分片策略全解析

ES 分片策略的核心是：决定一条数据应该存储到哪个主分片中，官方提供了 4 种核心分片策略，适用于不同业务场景。

3.1 策略1：默认哈希路由策略（最常用）

3.1.1 原理

ES 默认使用文档ID哈希取模算法计算分片位置：
目标分片号 = hash(文档ID) % 主分片总数

3.1.2 特点

1. 数据分布绝对均匀，无数据倾斜
2. 无需手动配置，开箱即用
3. 适用于绝大多数通用场景（日志、普通业务数据）

3.1.3 适用场景

日志检索、用户数据存储、订单数据存储等无关联关系的通用数据。

3.2 策略2：自定义路由键策略（业务优化首选）

3.2.1 原理

手动指定业务字段作为路由键（如用户ID、店铺ID、地区码），通过哈希算法将同一业务主体的数据存储在同一个分片中。
目标分片号 = hash(自定义路由键) % 主分片总数

3.2.2 特点

1. 大幅提升关联查询性能（无需跨分片查询）
2. 可能产生数据倾斜（需合理选择路由键）
3. 写入/查询时必须携带路由参数

3.2.3 配置方式

# 写入数据指定路由键 POST /order_index/_doc/1?routing=user_1001 { "order_id": "123456", "user_id": "user_1001", "amount": 99.9 } # 查询数据指定路由键（仅查询目标分片，性能提升10倍+） GET /order_index/_search?routing=user_1001 { "query": { "match": { "order_id": "123456" }} }

3.2.4 适用场景

电商订单（按用户ID路由）、多租户系统（按租户ID路由）、地域数据（按城市码路由）。

3.3 策略3：显式分片ID策略（极少用）

3.3.1 原理

直接指定数据写入固定分片号，完全由开发者控制数据分布。

3.3.2 特点

1. 灵活性极高，但极易产生数据倾斜
2. 生产环境几乎不使用
3. 仅适用于特殊定制化场景

3.3.3 适用场景

内部定制化系统、特殊数据分发场景。

3.4 策略4：索引级分片分配策略（集群级控制）

3.4.1 原理

通过 ES 集群设置，控制分片在节点间的分配规则（不是数据路由规则，是分片物理分布规则），属于集群级分片策略。

3.4.2 核心子策略

1. 节点感知分配：根据节点属性（机架、区域）分配分片，避免单机/机架故障导致数据丢失
2. 分片均衡策略：集群自动将分片均匀分配到所有节点，避免单节点负载过高
3. 冷热分离策略：热数据（高频读写）分配到高性能节点，冷数据（低频查询）分配到低性能节点

3.4.3 配置示例（冷热分离）

# 标记节点属性 # 热节点：node.attr.data_type=hot # 冷节点：node.attr.data_type=cold # 索引设置冷热分配 PUT /log_index/_settings { "index.routing.allocation.require.data_type": "hot" }

3.4.4 适用场景

大型集群、多机架部署、冷热数据分离、高可用集群架构。

3.5 四种分片策略对比表

四、ElasticSearch 分片/副本数量配置方法

4.1 核心配置参数

1. number_of_shards：主分片数量（索引创建后不可修改）
2. number_of_replicas：副本数量（可动态修改）

4.2 配置方式1：创建索引时指定（推荐）

这是生产环境最标准的配置方式，必须在创建索引时定义主分片数。

# 创建索引，配置3个主分片，1个副本 PUT /my_index { "settings": { "number_of_shards": 3, // 主分片数：核心配置，创建后无法修改 "number_of_replicas": 1 // 副本数：可动态修改 }, "mappings": { "properties": { "id": { "type": "keyword" }, "name": { "type": "text" } } } }

4.3 配置方式2：动态修改副本数量

副本数支持在线动态修改，无需重启集群，不影响业务。

# 修改索引副本数为 2 PUT /my_index/_settings { "number_of_replicas": 2 } # 修改所有索引副本数 PUT /*/_settings { "number_of_replicas": 1 }

4.4 配置方式3：通过模板批量配置（生产必备）

针对日志、时序数据，使用索引模板统一配置分片规则，避免手动创建索引出错。

# 创建索引模板，所有匹配 log-* 的索引自动使用3主1副本 PUT _template/log_template { "index_patterns": ["log-*"], "settings": { "number_of_shards": 3, "number_of_replicas": 1 } }

五、生产环境：分片/副本数最优配置建议

5.1 主分片数配置核心原则

1. 单个分片大小控制在 30GB~50GB（ES 官方最优标准）
   • 过小：分片数量过多，查询性能下降
   • 过大：集群恢复慢，节点负载过高
2. 主分片数 ≤ 集群数据节点数
   • 例：3个数据节点 → 主分片数建议 3/6/9（倍数关系）
3. 预估未来1~2年数据量，提前规划主分片数（无法修改）

主分片数计算公式

主分片数 = 预估总数据量(GB) / 单分片推荐大小(40GB)
例：总数据 200GB → 200/40=5 → 配置 5 个主分片

5.2 副本数配置核心原则

1. 高可用必备：生产环境至少配置 1 个副本（无副本会导致单点故障）
2. 查询并发优化：查询压力大时，可增加副本数（副本可分担查询压力）
3. 集群节点数约束：
   • 单节点集群：副本数=0（无高可用，仅测试环境）
   • 2~3节点集群：副本数=1（标准高可用）
   • 大型集群：副本数=2（极致高可用）

5.3 不同场景配置方案

六、常见坑点预警（必看）

1. 主分片数设置过大：100GB数据设置50个分片 → 跨分片查询极慢
2. 主分片数设置过小：单分片200GB → 集群故障恢复耗时数小时
3. 生产环境无副本：节点宕机直接导致数据丢失、服务不可用
4. 随意修改主分片数：ES 不支持，只能重建索引（reindex）

七、总结

1. ES 提供4种分片策略，默认哈希路由适合通用场景，自定义路由键适合业务优化场景；
2. 主分片数创建后无法修改，必须提前规划，单分片大小控制在30~50GB；
3. 副本数可动态修改，生产环境至少配置1个副本保障高可用；
4. 分片配置核心：数据均匀、节点负载均衡、高可用、性能最优。