Elasticsearch 分片设计实战封面配图，展示数据被切分为均衡分片

Elasticsearch 分片设计实战：副本、路由与热点排查

作者

Elasticsearch 分片设计实战封面

如果你的 Elasticsearch 集群在高峰期出现单节点 CPU 打满、查询延迟忽高忽低，或者明明加了节点却不见性能提升，问题往往出在分片设计上。本文将用真实命令与配置，带你走完分片数量规划、副本策略、路由算法与热点排查的完整流程，帮助你在一台 VPS（虚拟专用服务器）或独立服务器上把 Elasticsearch 集群调稳。

分片与副本：先理解数据如何被切分

Elasticsearch 把索引（index，逻辑上的数据集合）切分成若干分片（shard，物理存储单元），每个分片本质上是 Lucene 的一个独立索引。分片又分为主分片（primary shard）与副本分片（replica shard，主分片的冗余拷贝）。主分片数量在创建索引时固定，之后无法修改；副本数量则可以随时调整。

主分片数量为什么不能随意改

主分片数量决定了数据如何被哈希分布到各节点。一旦创建，文档的归属分片就由路由公式确定，改动主分片数量意味着必须重建索引。因此规划主分片数量时，要同时考虑数据总量、单分片容量与节点数。

副本的作用不只是备份

副本分片既提供故障冗余，也承担读请求。当主分片所在节点宕机，副本会自动提升为主分片。副本越多，读吞吐越高，但写入时每个副本都要同步，写入延迟与磁盘占用也会上升。副本数量建议在 1 到 2 之间，除非读压力极大，否则不必堆太多。

分片数量规划：一个可落地的估算方法

分片数量没有绝对公式，但业界有一个常用经验：单个分片的数据量控制在 30GB 到 50GB 之间，分片总数控制在节点数的 1.5 到 3 倍。下面用一个具体例子说明。

按数据量与节点数反推

假设你有 3 个数据节点，预计一年数据量 300GB，保留 30 天热数据约 30GB。按单分片 30GB 估算，主分片数量取 3 到 5 个即可。若每个节点 2 个主分片加 1 个副本，总分片数为 3 节点 × 2 主分片 × 2（含副本）= 12 个，分布均匀且留有扩容余量。

用 API 查看当前分片分布

创建索引后，可以用下面的命令查看分片在节点上的分布情况：

 # 查看所有索引的分片分布
curl -s "http://localhost:9200/_cat/shards?v"

 # 查看某个索引的分片与副本状态
curl -s "http://localhost:9200/_cat/shards/my-index?v&s=prirep"

Elasticsearch 分片分布示意图

如果发现某个节点上的分片明显多于其他节点，说明分片分布不均，需要检查路由或节点角色配置。

副本策略：读写平衡与故障冗余

副本数量通过索引设置控制，可以在创建索引时指定，也可以随时动态调整。调整副本不会触发数据重分布，因此是应对读压力最轻量的手段。

动态调整副本数量

当读请求激增时，可以临时增加副本数量来分摊读压力：

 # 把 my-index 的副本数调整为 2
curl -X PUT "http://localhost:9200/my-index/_settings" -H 'Content-Type: application/json' -d '{
  "index.number_of_replicas": 2
}'

副本增加后，Elasticsearch 会自动把副本分片复制到其他节点。需要注意的是，副本分片必须与主分片位于不同节点，否则无法提供真正的故障冗余。如果集群只有 1 个数据节点，副本数设为 1 反而会因无法分配而进入 yellow 状态。

副本与写入性能的取舍

每增加一个副本，写入时就要多同步一份数据。对于日志类高写入场景，副本数保持 1 即可；对于读多写少的搜索场景，可以适当增加到 2。如果磁盘空间紧张，优先保证主分片与 1 个副本，而不是盲目堆副本。

路由算法：数据如何落到分片

Elasticsearch 默认使用文档 ID 的哈希值对主分片数量取模，决定文档落在哪个分片。默认路由下，数据分布相对均匀，但无法控制同一类数据落在同一分片。

自定义路由提升查询效率

对于按用户或按租户隔离的数据，可以指定路由字段（routing），让同一路由值的文档落在同一分片，从而在查询时只访问一个分片，显著降低查询开销：

 # 写入时指定路由字段
curl -X POST "http://localhost:9200/my-index/_doc?routing=user_1001" -H 'Content-Type: application/json' -d '{
  "user_id": "user_1001",
  "message": "hello"
}'

 # 查询时带上相同路由，只访问一个分片
curl -s "http://localhost:9200/my-index/_search?routing=user_1001" -H 'Content-Type: application/json' -d '{
  "query": { "match": { "message": "hello" } }
}'

使用自定义路由后，查询必须带上相同的 routing 值，否则会退化为全分片扫描。如果路由字段分布不均，比如某个大租户数据量远超其他租户，反而会制造热点分片，需要谨慎评估。

热点排查：定位单分片瓶颈

热点分片（hot shard）指某个分片承载了远超平均水平的读写压力，导致所在节点 CPU 或磁盘 I/O 打满。排查热点需要从分片分布、节点负载与慢查询三个角度入手。

查看节点与分片负载

先用节点统计接口定位高负载节点，再结合分片分布判断是否由某个分片引起：

 # 查看各节点 CPU、内存与磁盘使用情况
curl -s "http://localhost:9200/_cat/nodes?v&h=name,cpu,heap.percent,disk.used_percent"

 # 查看每个分片的大小与文档数
curl -s "http://localhost:9200/_cat/shards?v&h=index,shard,prirep,state,docs,store"

Elasticsearch 热点分片排查示意图

如果某个分片的 store 大小或 docs 数明显高于同索引其他分片，说明数据分布不均，可能是路由字段选择不当或主分片数量过少。

用慢查询日志定位热点请求

开启慢查询日志，可以捕获执行时间过长的搜索与索引请求，从而定位是哪个分片、哪类查询在拖慢集群：

 # 开启搜索慢日志，超过 2 秒的查询记录到日志
curl -X PUT "http://localhost:9200/my-index/_settings" -H 'Content-Type: application/json' -d '{
  "index.search.slowlog.threshold.query.warn": "2s",
  "index.search.slowlog.threshold.fetch.warn": "1s"
}'

慢日志会记录查询语句、耗时与命中的分片，是定位热点查询最直接的依据。结合分片分布，就能判断热点是数据分布问题还是查询本身的问题。

分片设计常见误区与调整建议

分片设计一旦上线，调整成本较高，因此规划阶段就要避开几个常见误区。

误区一：分片越多越好

分片过多会导致每个分片过小，查询需要跨大量分片聚合，反而增加开销。分片过少则单分片过大，恢复与合并耗时变长。建议单分片数据量控制在 30GB 到 50GB，分片总数不超过节点数的 3 倍。

误区二：主分片数量拍脑袋定

主分片数量创建后不可修改，只能通过重建索引调整。如果初期数据量预估不足，后期扩容需要新建索引并 reindex（重新索引，把旧索引数据迁移到新索引），期间会占用大量资源。建议按峰值数据量上浮 30% 规划。

误区三：忽略节点角色

在较大集群中，建议把数据节点（data node，负责存储与检索）与主节点（master node，负责集群管理）分离，避免管理任务与数据读写争抢资源。小规模集群可以合并，但要注意主节点负载。

总结与行动建议

分片设计是 Elasticsearch 性能的根基。规划阶段先按数据量与节点数估算主分片数量，副本数按读写比例在 1 到 2 之间调整，路由字段只在数据天然可分租时使用，热点排查则从分片分布、节点负载与慢查询三个角度入手。如果你需要为日志或搜索业务搭建稳定的 Elasticsearch 集群，建议先评估当前数据量与增长趋势，再结合 MySQL 慢查询分析 与 PostgreSQL 膨胀调优 等数据库运维经验，统一规划存储与检索架构。若集群规模较大，也可以参考 Redis 持久化与恢复 的备份思路，为分片数据建立可靠的恢复方案。更多服务器运维实践，可以查看 SSH 访问控制审计 与 Restic 备份实战，从安全与备份两个维度完善你的基础设施。总结来说，如果你正在 Hostease 的 VPS 或独立服务器上运行 Elasticsearch，可以考虑先按本文步骤做一次分片健康检查，再结合工单咨询节点规格与磁盘规划，让集群在扩容前就处于合理状态。

发表评论