关注我的公众号：【Fox爱分享】，可获取首发内容。
写在开头
大家好，我是 Fox。
最近帮一位工作 5 年的兄弟复盘美团一面，聊到 Elasticsearch（ES）架构时，现场可谓是“惨烈”。
面试官问了一个非常经典的问题：
“说说你们生产环境 ES 的集群架构？数据量多大？分片怎么分的？依据是什么？”
这位兄弟张口就来：
“额，我们大概有 13 台机器，日增 200G 日志，分了 10 个片……”
面试官当场反问：
“日增才 200G，你要用 13 台物理机？你的分片数是怎么算出来的？JVM 内存给了多少？针对聚合查询有做计算分离吗？”
全场沉默。
兄弟们，这道题考的根本不是你的“记忆力”，而是考你的“计算能力”和“架构规划能力”。
如果你只会被动地报数字，面试官会认为你根本没参与过核心架构建设，充其量就是个“CRUD 熟练工”。
今天 Fox 就带大家把这笔账算清楚，教你给出一份P7 架构师级别的满分答案。
一、 第一步：学会“算账”（拒绝资源浪费）
很多人的通病是：数据量说太小，机器说太多。 这在懂运维的面试官眼里，就是典型的“败家”。
既然要聊架构，我们就要聊TB 级的场景。以一个标准的ELK 日志分析平台为例：
1. 场景设定
- 业务场景： 核心业务链路日志。
- 数据增量： 每天新增 1TB（这才配得上分布式集群）。
- 保留策略： 热数据保留 7 天，冷数据归档到 S3。
- 副本策略： 1 主 1 从（1 Replica），保证数据高可用。
2. 容量计算
你的存储需求不是 1TB，而是：
这就结束了吗？错！ ES 在运行过程中需要进行 Segment Merge（段合并），还需要预留磁盘 Watermark（水位线） 防止只读。
💡Fox 小词典：
- Segment Merge： ES 底层 Lucene 会不断把小文件合并成大文件，极其消耗磁盘 I/O。
- Watermark： 当磁盘使用率达到 85%-90% 时，ES 会拒绝写入。所以你不能把磁盘塞满。
经验公式：实际磁盘需求原始数据
架构推导：
我们需要一个能提供 24TB 有效存储的集群。
如果你申请 10 台 Data 节点，每台挂载一块 4TB 的 NVMe SSD，总容量 40TB。
水位线：。这是一个非常健康、且具备扩容缓冲的生产配置。
二、 第二步：分片数怎么定？（黄金法则）
算完了机器，最关键的来了：1TB 的索引，分几个片？
很多兄弟随口说“5个”、“10个”，问他为什么，支支吾吾说不出话。
请记住业内公认的分片黄金法则：
单个主分片（Primary Shard）的大小，建议控制在 30GB - 50GB 之间。
为什么卡在这个范围？
- < 30GB（太小）： 分片过多会导致文件句柄爆炸，Master 节点维护元数据压力剧增。
- > 50GB（太大）：
- 故障恢复慢： 节点宕机后，50G+ 的分片在网络间传输极慢。
- 查询卡顿： 尤其在段合并时，大分片会长时间占用 I/O，拖垮查询性能。
回到我们的案例
日增 1TB 数据，按照黄金法则计算：
高薪回答：
“针对日增 1TB 的日志索引，我经过测算，将主分片数设置为 24。这样单分片大小约 42GB，完美落在 30-50G 的最佳区间。”
三、 第三步：物理与逻辑架构（百万年薪的细节）
有了机器和分片，怎么部署？这里有四个关键点：角色分离、跨区容灾、协调节点演进、RAID 配置。
1. 物理拓扑（13 节点基础版）
- 3 台 Dedicated Master（专有主节点）：
- 配置： 低配（4核 8G）。
- 作用： 只负责集群管理，绝对不存数据！
- 关键点：跨可用区（Zone）部署。Zone A、Zone B、Zone C 各一台。即使某个机房光纤被挖断，集群依然存活，这叫机房级容灾。
- 10 台 Data Node（数据节点）：
- 配置： 高配（16核 64G + NVMe SSD）。
- 作用： 负责海量数据的写入和聚合查询。
2. 协调节点的演进（Coordinating Node）
面试官可能会追问：“你们有单独部署协调节点吗？”
千万别死板地说“有”或者“没有”，你要讲出**“架构演进”**的味道。
P7 回答话术：
“在业务初期，为了节省成本，我们让 Client 直连 Data 节点。
但随着业务发展，我们发现部分**重度聚合查询（Deep Aggregation）**非常消耗内存，甚至导致 Data 节点 OOM。
所以，我们目前规划了 2 台独立的协调节点。
为什么要加它？ 它的作用是 Scatter-Gather（分发与汇聚）。它不存数据，只负责把 Data 节点查回来的结果在内存中做排序和归并。
架构收益： 把‘计算风险’从‘存储节点’剥离出来。即使聚合查询把内存撑爆了，也只是挂掉协调节点，不影响核心写入。这就叫风险隔离！”
3. 31GB 内存陷阱
面试官继续追问：“Data 节点有 64G 内存，JVM 堆内存你给多少？”
如果你回答“32G”或者“48G”，恭喜你，挂了。
标准答案是：31GB！
底层原理：
在 Java 中，当堆内存小于 32GB 时，JVM 会开启指针压缩（Compressed Oops）。一旦超过这个阈值，指针膨胀为 64 位，性能不升反降！
剩下的 33G 去哪了？ 全部留给操作系统的 Page Cache！ES 的底层是 Lucene，只有 Page Cache 足够大，查询才能像“走内存”一样快。
4. 磁盘 RAID 的“反直觉”配置
还有一个隐蔽的坑：磁盘做 RAID 几？
很多小白为了“安全”去做 RAID 10 或 RAID 5。
错！我们直接上 RAID 0！
理由： ES 应用层本身就有 Replica 副本机制，数据安全已经由软件层保证了。底层硬件我们要的是极致的 I/O 速度和 100% 的磁盘利用率。
坏盘了怎么办？ES 集群会自动 Rebalance，毫秒级切换，这才是分布式系统的自信！
当然，如果你的运维能力够强，配置 JBOD (Just a Bunch of Disks) 多路径挂载是更优解。坏一块盘只丢部分分片，恢复压力比 RAID 0 坏整个节点要小得多。但为了面试回答的条理性，强调 RAID 0 的极致性能和利用率通常就够了。
四、 第四步：场景化调优（没有银弹）
如果面试官继续追问：“日志场景写入压力这么大，你怎么优化的？”
这里一定要注意场景区分！
1. 针对“日志场景”（我们当前的案例）
日志的特点是：写多读少，容忍短暂延迟。
- 优化 A：加大 refresh_interval。
- 默认 1s 改为 30s。虽然数据晚 30s 才能搜到，但减少了 Merge 开销，写入性能提升一倍。
- 优化 B：Translog 异步化。
- 将
index.translog.durability改为async。虽然有丢几秒数据的风险，但能极大提升吞吐量。
- 将
2. 针对“电商搜索场景”（面试官可能的追问）
如果面试官问：“那如果是商品搜索呢？”
千万别照搬！ 商品搜索是读多写少，要求低延迟。
- 分片策略： 单分片建议压缩到 20GB-30GB，提高查询并发度。
- 刷新策略：
refresh_interval调回 1s - 5s，保证商家改价后用户立马能看到。
五、 总结：拿来即用的面试模板
架构全景图
以后再被问到 ES 架构，别再干巴巴报数字了，把下面这段话背下来：
“关于 ES 架构，我是根据业务增量和架构演进来规划的。
- 容量与分片： 针对日增 1TB 的日志业务，我申请了 10 台 Data 节点（每台 4TB NVMe SSD，组 RAID 0）。依据单分片 30-50GB 的原则，将主分片设为 24，单片约 42GB。
- 物理架构： 采用 13+2 节点角色分离 模式。
- 3 台 Master 跨可用区部署防脑裂；
- 10 台 Data 节点内存锁定在 31GB 利用指针压缩，剩余内存留给 Page Cache。
- 针对重度聚合业务，我还预留了 2 台独立的协调节点，做计算与存储的分离，防止 OOM。
- 场景调优： 鉴于日志场景对实时性要求不高，我将
refresh_interval调整为 30s 并开启 Translog 异步，用极小的可见性延迟换取了写入性能的翻倍。”
把这套逻辑讲清楚，谁敢说你不懂架构？
写在最后
架构设计没有标准答案，只有最适合业务的答案。
P6 关注“怎么搭建”，P7 关注“为什么这么搭”。从计算容量，到分片规划，再到协调节点和 RAID 0 的取舍，这每一步的决策过程，才是你薪资翻倍的筹码。
**你的 ES 集群踩过哪些坑？有没有被面试官追问过分片计算逻辑？评论区聊聊～ **
我是Fox，更多干货，关注公众号【Fox爱分享】，只讲书上不写的实战坑。
