48 · 集群与分片调优、监控阶段第五阶段 / 运维进阶ESshard 规划、_cat/_cluster监控、熔断器、段合并 | PostgreSQL分区规划、pg_stat_*、VACUUM1. 概念ES 的性能与稳定性很大程度取决于分片规划和资源健康shard分片索引被切成多个分片分布到节点每个分片是一个 Lucene 索引有固定开销。replica副本分片的拷贝提供高可用 读扩展。段合并mergeLucene 后台把小段合并成大段影响写入/查询性能。circuit breaker熔断器内存保护防止单个大请求打爆 JVM 堆。核心经验分片不是越多越好过多小分片over-sharding是最常见的性能杀手。2. PostgreSQL 对照ESPostgreSQL分片数规划分区数量/大小规划_cat/shards、_cluster/healthpg_stat_activity、pg_stat_user_tables段合并VACUUM/ autovacuumcircuit breakerwork_mem/ OOM 保护3. 关键命令Dev ToolsGET _cluster/health # green/yellow/red未分配分片数 GET _cat/nodes?vhname,heap.percent,cpu,load_1m,disk.used_percent GET _cat/indices?vsstore.size:desc # 各索引大小、文档数按大小排序 GET _cat/shards?vsstore:desc # 分片分布与大小 GET _nodes/stats/breaker # 熔断器触发情况 GET _cat/thread_pool/write,search?vhnode_name,name,active,queue,rejectedrejected不为 0 线程池打满被拒说明写/查压力过大或分片不合理。4. 分片规划经验法则单分片目标 10–50GB日志类可到 50GB检索类偏小。用总数据量估算分片数。分片总数受堆内存约束经验上每 GB 堆 ≤ ~20 个分片节点分片过多会拖慢元数据操作。小索引就 1 分片几百 MB 的索引别开 5 分片纯浪费。副本至少 1生产number_of_replicas ≥ 1才有高可用导入期可临时设 0 提速完成后加回。分片数创建后不可改只能 reindex第 33 篇或用shrink/split。规划要留量。5. Spring Boot 实现健康自检ComponentpublicclassDoc48ClusterOps{AutowiredprivateElasticsearchClientelasticsearchClient;/** 集群健康自检非 green 或有未分配分片就告警 */publicvoidhealthCheck()throwsIOException{HealthResponsehelasticsearchClient.cluster().health();if(h.status()!HealthStatus.Green||h.unassignedShards()0){log.warn(ES 集群异常 status{}, unassigned{}, activePercent{},h.status(),h.unassignedShards(),h.activeShardsPercentAsNumber());}}}importco.elastic.clients.elasticsearch.cluster.HealthResponse、co.elastic.clients.elasticsearch._types.HealthStatus。生产建议接入 Prometheus/Elastic 监控。6. 坑与最佳实践别 over-sharding小分片过多会拖垮集群合并小索引、用 rollover 控制分片大小。yellow ≠ 坏单节点开发时副本无处分配health 常年 yellow正常生产 red 才是数据不可用。写入慢先看 merge 和 refresh批量导入临时refresh_interval-1、replicas0第 31 篇。堆内存别超 ~31GB超过会失去指针压缩反而更差剩余内存留给文件系统缓存。熔断data too large报错说明请求/聚合太吃内存缩小范围或加节点别盲目调大 breaker 阈值。热点分片某分片读写远高于其它检查路由/数据倾斜。