企业官网建设流程全解析

前言

Elasticsearch 集群的性能，80% 取决于架构设计与集群级调优。
很多人遇到查询慢、写入低、节点宕机、集群不稳定，只会盲目加机器，却不知道问题出在分片设计、节点角色、JVM、GC、磁盘、写入策略、查询优化等架构层面。

本文从集群规划 → 节点角色 → 分片 → 写入 → 查询 → JVM/GC → 系统层 → 高可用，提供一套完整、可落地、生产级的 ES 集群架构调优策略，让你的集群性能提升5～20 倍，稳定支撑高并发、大数据量场景。

一、ES 集群架构调优总览（核心流程图）

二、第一层：集群规划与节点架构调优

2.1 生产标准集群拓扑（最优）

• 3 个专用 Master 节点（不存数据、不查询）
• N 个数据节点（存储+计算）
• 协调节点（高并发查询专用，可选）
• Ingest 节点（数据预处理，可选）

2.2 节点配置调优

# 专用 Master 节点node.master:truenode.data:falsenode.ingest:false# 数据节点node.master:falsenode.data:truenode.ingest:true

2.3 集群规模调优

• 节点总数保持奇数
• 至少3 个主节点资格节点
• 不推荐2 节点集群（极易脑裂）

三、第二层：分片（Shard）架构调优（最关键）

3.1 分片设计黄金原则

1. 单个分片大小推荐 30GB～50GB
2. 分片总数 ≈数据节点数 × 1～3
3. 索引主分片数一旦创建不能修改，必须提前规划
4. 副本数：生产 1 个即可，写入时可临时设为 0

3.2 分片问题与调优

• 分片过多：元数据压力大、段合并爆炸、查询慢
• 分片过少：无法充分利用集群并发能力
• 分片不均：热点节点、性能倾斜、负载不均

3.3 调优命令

# 写入前关闭副本，提升写入性能PUT/_all/_settings{"number_of_replicas":0}# 均衡分片POST/_cluster/reroute?retry_failed=true

四、第三层：写入性能架构调优

4.1 写入瓶颈点

• 单条写入、bulk 过大/过小
• 副本同步阻塞
• refresh 过于频繁
• translog 刷盘频繁
• segment merge 压力大

4.2 写入调优策略

1. 必须使用 bulk 批量写入（500～5000 条/批）
2. 写入时关闭副本，写完再开启
3. 延长 refresh_interval：1s → 30s/60s
4. translog 改为异步
5. 降低段合并线程数
6. 使用 SSD 磁盘

4.3 写入最优配置

{"number_of_replicas":0,"refresh_interval":"30s","translog.durability":"async","translog.sync_interval":"30s"}

五、第四层：查询性能架构调优

5.1 查询慢的根源

• 深度分页、全表遍历
• 大聚合、无 routing、无索引
• 字段过多、通配符开头查询
• 结果集过大、过滤条件不合理

5.2 查询调优策略

1. 禁止使用 from + size 深度分页→ 使用 search_after
2. 使用 filter 代替 query（不计算评分）
3. 使用 routing 路由查询，只查目标分片
4. 关闭不必要的字段聚合
5. keyword 精准匹配，text 分词匹配
6. *避免 “关键词” 左模糊查询

六、第五层：JVM 与 GC 架构调优（稳定性核心）

6.1 JVM 内存调优

1. Xms = Xmx
2. 堆内存 ≤ 32GB（防止指针压缩失效）
3. 堆 ≤ 物理内存 50%（留给 Lucene 堆外）

-Xms16g -Xmx16g

6.2 GC 调优（必须用 G1）

-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=70

6.3 核心目标

• Full GC = 0
• Young GC < 50ms
• 禁止 Swap

七、第六层：磁盘与操作系统底层调优

7.1 磁盘（性能天花板）

• 必须使用 SSD（HDD 无法支撑高并发）
• RAID 0（提高 IOPS）
• 单独磁盘存放 ES 数据

7.2 系统内核调优（必须配置）

vm.max_map_count=262144 fs.file-max=655350 ulimit -n 655350 bootstrap.memory_lock: true

7.3 禁止内存交换

swapoff -a

八、第七层：高可用与稳定性调优

8.1 防止脑裂（双 Master）

• ES 6.x：minimum_master_nodes: (master数/2)+1
• ES 7.x+：自动防脑裂
• 3 个专用主节点

8.2 线程池与队列调优

thread_pool.write.queue_size:2048thread_pool.search.queue_size:2048

8.3 熔断机制，避免 OOM

indices.breaker.fielddata.limit:40%indices.breaker.request.limit:60%

九、第八层：监控与预警（生产必备）

9.1 必须监控指标

• 节点状态
• 分片分布
• GC 次数（尤其 FullGC）
• 磁盘使用率
• CPU/负载
• 查询/写入耗时
• 队列等待

9.2 推荐监控方案

• Prometheus + Grafana
• Elasticsearch-exporter
• Kibana 自带监控

十、ES 集群架构调优完整步骤（生产标准）

十一、生产环境常见错误（90% 人中招）

1. ❌ 分片数量随意设置
2. ❌ 堆内存超过 32GB
3. ❌ 未关闭 Swap
4. ❌ 写入不使用 bulk
5. ❌ 查询使用深度分页
6. ❌ 磁盘使用 HDD
7. ❌ 主节点兼任数据节点
8. ❌ 2 节点集群上线

十二、总结（架构调优 10 条黄金定律）

1. 3 个专用主节点，奇数部署，防止脑裂
2. 分片大小 30～50GB，提前规划
3. 写入用 bulk，关闭副本，延长 refresh
4. 查询用 routing、filter、search_after
5. JVM 堆 ≤32GB，Xms=Xmx
6. 必须使用 G1GC，杜绝 FullGC
7. 磁盘必须 SSD
8. 关闭 Swap，开启内存锁定
9. 系统内核优化必不可少
10. 监控全覆盖，提前发现问题

按照这套架构调优策略，你的 Elasticsearch 集群将实现：
✅写入 TPS 提升 5～20 倍
✅查询速度提升 3～10 倍
✅无宕机、无卡顿、无OOM、无FullGC
✅支撑大数据量、高并发场景