搜索引擎容量规划与扩容

可视化演示

展示利特尔定律容量估算、垂直与水平扩容策略对比及负载/压力/浸泡容量测试方法，直观理解搜索集群扩容决策过程。

容量规划概念：先想清楚要开几家厨房

开连锁餐厅之前，你不会等客人把店堂挤满了才开始考虑厨房够不够用。你得先回答三个问题：未来会来多少客人（数据量），客人点菜的速度有多快（查询量），万一某个厨房突发故障，其他厨房能不能顶上（冗余）。这三个问题想清楚了，才能决定厨房群该建多大、设备该配多好。

Elasticsearch 集群就是一座“中央厨房群”。容量规划（Capacity Planning），就是在业务上线前和持续运营期，系统性地回答：集群需要多少个节点、每个节点什么规格、索引要建多少个分片、副本设几个、留多少冗余空间。它不是拍脑袋估个数，而是一套可以计算的流程。

规划要覆盖三个维度。数据维度：存量数据、每日增量、索引膨胀系数、副本复制带来的存储放大；查询维度：QPS、平均时延、并发查询数；冗余维度：故障容错空间、滚动升级和扩容期间需要的临时缓冲。规划流程则是闭环：采集现状指标 → 预测增长曲线 → 计算所需规模 → 留出缓冲余量 → 上线后持续校准。

$$C_{total} = D_{data} \times (1 + N_{replica}) \times (1 + r_{buffer})$$

1. D_data 数据本体：全部业务文档经倒排索引等处理后的原始存储量，是后续所有计算的起点。

$$D_{data} = N_{doc} \times S_{avg}$$

2. (1+N_replica) 副本放大：每个分片有 N_replica 个副本，总存储要乘上 (1+副本数) 倍。

$$1 + N_{replica}$$

3. (1+r_buffer) 冗余缓冲：为高峰、数据搬迁、异常故障预留的容量空间，通常 r 取 0.2~0.3。

$$1 + r_{buffer}$$

就像餐厅在预估客流的基础上再多备两成食材、多留一张备用操作台——容量规划的精髓，从来不是精确到个位数的计算，而是在合理估算之上，给不确定性留出呼吸空间。

数据量估算：数一数未来有多少道菜

你不可能凭感觉去批发市场买食材：买少了晚上断供，买多了积压变质。后厨的做法是统计——每天接待多少桌、平均每桌点几道菜、每道菜耗多少原料。搜索引擎的数据量估算，做的就是这件事。

数据量估算有三个关键量。文档总量 N_doc：业务数据条数，等于历史存量加上每日新增乘以规划周期；平均文档大小 S_doc：单条文档在 _source 原文和索引字段上的字节数，可以抽样统计；膨胀系数 r_overhead：倒排索引、分词词典、列存储和段文件带来的额外开销，通常达到原始数据的 1.5 到 3 倍。

增长预测要特别注意“台阶式增长”：接入新业务、开启新日志源、调整留存策略，都会让数据曲线突然抬升。线性外推只适用于平稳期，规划时要给突发增长留出余量。

$$S_{total} = N_{doc} \times S_{doc} \times (1 + r_{overhead})$$

1. N_doc 文档总量：存量文档数加上每日新增量乘以规划天数，是数据规模的基本盘。

$$N_{doc} = N_{base} + G_{day} \times T_{days}$$

2. S_doc 平均文档大小：抽样 k 条文档计算平均字节数，避免用单条极端值代表整体。

$$S_{doc} = \dfrac{1}{k}\sum_{i=1}^{k} s_i$$

3. (1+r_overhead) 膨胀系数：倒排索引与段存储让实际占用放大，1.5 到 3 倍是常见区间。

$$1 + r_{overhead}$$

像后厨按“每桌平均 3.5 道菜、损耗率 20%”进货一样——算得越细，浪费越少；把膨胀系数和台阶增长算进去，才不会在旺季突然发现食材不够。

负载估算：高峰期点单会不会压垮厨房

厨房最怕的不是平时，而是周五晚上七点的爆单时刻。你得知道最高峰每秒进来多少张订单（QPS），一道菜平均做多久（响应时延），才能算出需要几个炒锅师傅（节点）。平时再闲，高峰顶不住就是事故。

查询负载的核心是两个数字：QPS——每秒查询次数，必须取峰值而不是均值；平均响应时延 T——单次搜索从发出到返回的耗时。两者相乘，就是在任意瞬间集群需要同时处理的查询数，也就是并发量。直觉理解：每秒进来 1000 个查询、每个查询要跑 0.2 秒，那么任意瞬间总有 200 个查询同时在飞。

每个节点能稳定承载的并发是有限的，这个能力来自压测而不是估计。于是节点数 ≈ 峰值并发 ÷ 单节点并发能力。峰值系数 k 通常取 2 到 5：用 p99 时延或大促预期流量放大均值，给系统留出呼吸空间。

$$N_{node} = \left\lceil \dfrac{QPS_{peak} \times T_{latency}}{C_{node}} \right\rceil$$

1. QPS_peak 峰值查询量：取高峰时段的每秒查询数，乘以峰值系数放大，而不是用全天均值。

$$QPS_{peak} = \mu_{qps} \times k_{peak}$$

2. T_latency 平均时延：单次搜索从发出到返回的平均耗时，单位是秒。

$$T_{latency}$$

3. C_node 单节点并发能力：通过压测得到的每个节点能稳定并行处理的查询数。

$$C_{node}$$

4. 向上取整：节点数必须是整数，任何小数都意味着容量不足。

$$\lceil \cdot \rceil$$

就像餐厅按“高峰 20 分钟翻一台、同时 40 桌”来排服务员——宁可多备一个传菜员，也不能让客人催单。负载估算的本质，是用峰值而非均值来对抗不确定性。

分片副本策略：菜谱怎么分册、要不要复本

一本上千页的厚菜谱，不可能让每个厨师都捧着全文。聪明的后厨会把它拆成几册，每个分区灶台负责一册——这就是分片；再把每册复写几份放到别的厨房——这就是副本。主厨房忙不过来或突然停电，副厨房的复本立刻顶上。

分片（shard）是 Elasticsearch 存储和并行检索的最小单位。主分片数在创建索引时确定，之后不能直接修改，只能通过重建索引调整。副本（replica）是主分片的完整拷贝，既可以故障切换，也可以分摊读流量——这就是读写分离：写请求只打主分片，读请求可以在主副本之间分发。

分片数量由数据量决定：主分片数 = 向上取整（总数据量 ÷ 单分片目标容量）。单分片容量建议控制在 20 到 50GB：太小则分片数量爆炸、查询广播和段合并开销大；太大则单分片故障恢复和段合并时间过长。

$$N_{shard} = \left\lceil \dfrac{S_{total}}{S_{target}} \right\rceil$$

$$S_{storage} = S_{total} \times (1 + N_{replica})$$

1. S_target 单分片目标容量：生产经验值，一般取 20~50GB，保证段合并与恢复速度可控。

$$S_{target} \in [20\text{GB},\ 50\text{GB}]$$

2. N_shard 主分片数：总数据量除以单分片容量，向上取整得到主分片总数，创建索引后不可直接修改。

$$N_{shard} = \left\lceil \dfrac{S_{total}}{S_{target}} \right\rceil$$

3. S_storage 实际存储量：副本让每份数据保存 (1+副本数) 份，总存储随之放大。

$$S_{storage} = S_{total} \times (1 + N_{replica})$$

分册太薄，管理琐碎；分册太厚，一册损坏要修半天。20 到 50GB 是无数生产事故换来的“黄金厚度”，而副本数则是在存储成本与高可用之间做选择题。

节点规格设计：厨房配几口灶、多大冰箱

厨房不是面积越大越好。灶台太多没人用是浪费，冰箱塞得太满食材容易坏。节点规格设计讲的是匹配：数据量、查询量与硬件资源之间的配比关系，而不是一味堆配置。

Elasticsearch 的 JVM 堆内存有一条黄金法则：不超过物理内存的 50%，且不超过 31GB。超过 31GB 后 JVM 会失去“压缩指针”优化，对象引用多占约 10% 内存；堆设得过大，反而挤压操作系统留给 Lucene 文件缓存的堆外空间。

Lucene 的段文件缓存（堆外内存）对查询加速贡献极大——热数据段如果能被文件缓存命中，查询可以快一个数量级。所以内存规划不是“全给堆”，而是堆内装索引结构、堆外缓存文件段，各司其职。CPU 与磁盘同样要匹配：写入密集场景优先 SSD；CPU 核数要与分片数和查询并发规划对应。

$$M_{heap} = \min\left(31\text{GB},\ 0.5 \times M_{ram}\right)$$

1. 0.5 × M_ram 堆上限：JVM 堆不要超过物理内存一半，留一半给操作系统与 Lucene 文件缓存。

$$0.5 \times M_{ram}$$

2. 31GB 压缩指针上限：超过 31GB 后 JVM 不再启用压缩指针优化，内存浪费 10% 以上。

$$31\text{GB}$$

3. min 取最小值：两条规则同时生效，取更严格者作为最终堆大小。

$$\min(\cdot)$$

一半内存做冷藏（堆内索引）、一半做冷冻（堆外缓存），冰箱设计得均衡，出餐速度才快——节点规格的真谛是“留白”，给操作系统留空间，就是给查询性能留空间。

扩容实施路径：新厨房怎么开、菜品怎么搬

客流涨了，就要开新厨房。但新厨房不是开业当天就能接单的——你得把一部分菜品从老厨房搬过去，而搬家期间老厨房还得正常出餐。这就是扩容的常态：一边搬迁数据，一边继续服务。

扩容主要有四条路径。水平扩容：新节点加入集群后，分片会自动再平衡，这是最常用的方式；垂直扩容：替换更大规格的机器，不改分片结构，但单机存在上限；索引重建（reindex）：当需要调整主分片数时，把数据从旧索引迁移到新索引；滚动升级：逐节点重启升级版本，避免集群整体停机。

再平衡不是瞬时的：分片要序列化传输、落盘、建索引，还要参与段合并。再平衡时间约等于搬迁数据量除以实际带宽，一个 10TB 的索引扩容，可能耗时数小时甚至更久。因此扩容要提前规划窗口，而不是等磁盘写满才动手。

$$T_{rebalance} \approx \dfrac{S_{move}}{V_{net}}$$

1. S_move 搬迁数据量：再平衡时分片实际移动的字节数，副本越多、数据越大，搬得越多。

$$S_{move}$$

2. V_net 网络传输速度：节点间实际可用带宽，需要扣除业务查询占用的部分。

$$V_{net}$$

3. 约等号：实际耗时还受磁盘 IO、分片数、段合并影响，这个值只能用于粗估。

$$\approx$$

新厨房开业的前一晚，后厨通宵搬运半成品，第二天才能正常接待。扩容同理——数据搬家需要时间窗口，提前规划，才能让“开新店”变成惊喜而不是惊吓。

风险与回滚：搬家路上别把灶台挤爆

搬家最怕什么？怕搬家车辆把老厨房的通道堵死，客人进不来、菜出不去。扩容的风险正是如此：分片再平衡要占用大量 IO 和带宽，可能让正在服务的查询明显变慢。

三大风险要提前防范。再平衡开销：海量分片同时搬迁会拖垮业务流量，可以限制集群并发再平衡数、错峰执行；热点分片：某个分片被大量请求集中访问，单个节点成为瓶颈——热点通常来自不合理的路由规则或分片粒度过大；回滚预案：新节点配置错误或版本不兼容时，要能快速下线新节点、让集群回到扩容前状态。

副本是容错的核心。可用性公式 A = 1 - p^(N+1)：p 是单节点故障概率，N 是副本数。副本为 0 时，任何单节点故障都会丢数据；副本为 1 时，需要两个节点同时故障才会丢数据，可用性大幅提升。这也是为什么生产环境至少保留 1 个副本。

$$A = 1 - p^{N_{replica} + 1}$$

1. p 单节点故障概率：一个节点在考察周期内出故障的概率，由硬件可靠性决定。

$$p$$

2. N_replica+1 副本总份数：主分片加上副本的总拷贝数量。

$$N_{replica} + 1$$

3. p^(N+1) 全挂概率：所有拷贝同时故障才会导致数据丢失。

$$p^{N_{replica} + 1}$$

4. 1 减：用 1 减去全挂概率，得到集群整体可用性。

$$1 - p^{N_{replica} + 1}$$

备用厨房越多，所有厨房同时停摆的概率越低；但搬家时同样要设“限行时段”，别让扩容的搬迁流量堵死正在营业的老厨房——风险意识，是扩容操作的最后一道保险。

监控与预警：大堂经理盯着水位表

餐厅大堂经理的眼睛永远盯着两样东西：等位人数和出餐速度。搜索引擎集群同样需要一双“眼睛”——容量监控，盯着磁盘水位、内存水位和查询水位，而不是等磁盘写满报警了才手忙脚乱。

核心监控指标有四类：磁盘水位——已用磁盘与总磁盘的比值，Elasticsearch 默认低水位 85%、高水位 90%，超过 85% 就不再向该节点分配新分片；JVM 堆内存与 Full GC 频率——堆使用率持续高位或 GC 频繁，说明容量或查询有问题；QPS、平均时延与拒绝率——反映查询负载；分片健康状态——green/yellow/red 分别代表全好、有副本缺失、有主分片丢失。

容量管理的核心动作是“水位触发”：连续多日磁盘水位超过 85%，就要启动扩容流程；水位回落到 70% 以下，可以评估缩容。监控不是看看仪表盘，而是每个指标背后都挂着明确的动作。

$$W_{disk} = \dfrac{U_{used}}{U_{total}} > 0.85 \Rightarrow \text{scaling out}$$

1. U_used 已用磁盘：节点上数据实际占用的字节数，包含分片、段文件和日志。

$$U_{used}$$

2. U_total 总磁盘：节点挂载的磁盘总容量。

$$U_{total}$$

3. 0.85 水位阈值：超过 85% 后 Elasticsearch 默认停止向该节点分配新分片，并触发再平衡。

$$0.85$$

4. 触发扩容：水位连续告警时，应启动水平扩容流程并等待再平衡完成。

$$\Rightarrow \text{scaling out}$$

水位线就是后厨门口的“已满”标牌——不是在客人排到门外才加座位，而是看到 85% 满座就开始准备翻台。容量规划是持续的动作，监控预警就是它的节奏器。

AI 应用场景

Python 演示

"""搜索引擎容量规划模拟: 估算数据量, 分片数, 节点数并模拟扩容时机"""import math  def estimate_data_size(num_docs, avg_doc_size, overhead_ratio):    """估算总存储字节数: 文档总量 x 平均大小 x (1 + 膨胀系数)"""    return num_docs * avg_doc_size * (1 + overhead_ratio)  def calc_shard_count(total_bytes, target_shard_gb=30):    """按单分片目标容量计算主分片数, 向上取整"""    target_bytes = target_shard_gb * 1024 ** 3    return math.ceil(total_bytes / target_bytes)  def calc_node_count_for_qps(qps_peak, latency_s, node_capacity=100):    """按峰值 QPS 与平均时延估算所需节点数"""    concurrency = qps_peak * latency_s    return math.ceil(concurrency / node_capacity)  def calc_node_count_for_storage(total_bytes, node_disk_gb=2000, replica=1, margin=0.25):    """按存储估算节点数: 副本复制 + 预留 25% 缓冲"""    usable_gb = node_disk_gb * (1 - margin)    total_gb = total_bytes / 1024 ** 3 * (1 + replica)    return math.ceil(total_gb / usable_gb)  def main():    docs_per_day = 2000000            # 每日新增文档数    avg_doc_size = 2 * 1024           # 单文档约 2KB    days = 365                        # 规划周期一年    total_bytes = estimate_data_size(docs_per_day * days, avg_doc_size, 1.5)    shard_count = calc_shard_count(total_bytes)    storage_nodes = calc_node_count_for_storage(total_bytes)    qps_nodes = calc_node_count_for_qps(500, 0.2)    nodes = max(storage_nodes, qps_nodes)    print("一年数据量: %.1f TB" % (total_bytes / 1024 ** 4))    print("建议主分片数: %d" % shard_count)    print("存储所需节点: %d, QPS 所需节点: %d" % (storage_nodes, qps_nodes))    print("初始规划节点数: %d" % nodes)    node_usable = 2000 * 1024 ** 3 * 0.75   # 每节点可用磁盘    capacity = nodes * node_usable    used = 0.0    for month in range(1, 13):        used += total_bytes / 12        if used > capacity * 0.75:          # 磁盘水位超过 75% 触发扩容            nodes += 1            capacity = nodes * node_usable            print("第 %d 个月: 数据量 %.0f GB, 触发扩容 -> %d 节点" % (month, used / 1024 ** 3, nodes))    print("最终节点数: %d" % nodes)  if __name__ == "__main__":    main()

1. total_bytes = estimate_data_size(docs_per_day * days, avg_doc_size, 1.5)把“文档总量 × 平均大小 × (1 + 膨胀系数)”封装成函数，1.5 表示倒排索引带来的 150% 额外开销。
2. shard_count = calc_shard_count(total_bytes)按单分片 30GB 的经验上限，向上取整算出主分片数。
3. nodes = max(storage_nodes, qps_nodes)存储和查询两个维度分别算出节点数，取较大者，保证两边都不缺。
4. node_usable = 2000 * 1024 ** 3 * 0.75每节点 2TB 磁盘再扣掉 25% 缓冲，得到真实可用容量。
5. if used > capacity * 0.75:模拟监控预警：月度数据累计后若超过总容量 75%，就触发扩容并更新总容量。

常见误区

面试题