派对越来越拥挤了

您要举办一个披萨派对。您有几位朋友协助您招待宾客，他们分别在房间的不同位置。您把披萨分给每位朋友，他们会在饥饿的宾客陆续到来时开始分发披萨。

起初，一切运行顺利。有几位宾客陆续进来，朋友们端上披萨片，大家都很开心。但随后关于您的披萨的消息传开了。门铃一直在响。宾客们蜂拥而至。很快，人群聚集在您的一位朋友周围，就是那个拿着意式辣味香肠披萨的朋友，似乎大家都想要那块披萨。

您那位拿着意式辣味香肠披萨的朋友感到不知所措。宾客们正在等待，变得不耐烦了，还排起了长队。与此同时，您的朋友手持玛格丽特披萨站在那里，几乎没有人要一片。

您需要怎么做？

您又点了几份意式辣味香肠披萨，并把它们分给其他朋友。现在有三位朋友在拿着意式辣味香肠披萨分发，而不再只是一个人。人群散开了，突然间您就能一次性接待三倍数量的宾客。

随着您举办的派对越来越多，有几件事会变得越来越清晰：

• 并非所有披萨都同样受欢迎。有些供不应求，有些则鲜有人问津。您不需要为那些不受欢迎的披萨准备多余的“份数”。您需要为那些排队的披萨准备更多“份数”。

• 在排队人数变多之前多点几份披萨。如果您等到朋友已经忙得不可开交、客人都气得离场时才行动，那就太晚了。最好是在看到人群聚集时，就提前加点一份披萨。

• 别太快把披萨撤走。即使意式辣味香肠披萨周围的人群散开了五分钟，也不代表高峰期已经过去。也许他们只是在加饮料，甚至只是在聊天（现在还是这样吗？）。把多余的披萨准备好。如果冷场确实持续了一段时间，那时再撤走也不迟。

• 您能分发的披萨数量取决于有多少朋友来帮忙。如果您只有四个朋友在帮忙，十张披萨也改变不了结果。一次只能供应四份。将您的披萨数量与可用人手相匹配。

• 当一个朋友离开时，记得接管他的披萨。如果您的朋友需要离开，请立即拿走他们的披萨。披萨不能无人看管地放置。将它交给其他人，或者妥善收好。

我们已经聊完了披萨和副本

现在让我们把这些生动的小故事映射回 Elasticsearch。

在我们的类比中，披萨是副本（索引分片的副本），帮助提供服务的朋友是搜索节点，饥肠辘辘的宾客是搜索查询，而人头攒动的热门披萨则是搜索负载较高的热门索引。

当特定索引的搜索流量增加时，我们会创建额外的副本，并将它们分发到搜索节点上。任何副本都可以为该索引的任何查询提供服务，就像任何拿着意式辣味香肠披萨的朋友都可以分发意式辣味香肠披萨片一样。更多副本意味着更高的吞吐量：三个副本每秒处理的查询量是单个副本的三倍。

衡量饥饿程度

在决定订购多少披萨之前，我们需要了解人群的饥饿程度。

Elasticsearch 会跟踪每个分片的搜索负载。这是一个度量指标，用于衡量分片正在处理的搜索活动的数量。我们将此汇总到索引的所有分片中，以了解总的搜索需求。

最重要的是相对搜索负载：您的项目总搜索流量中，每个索引所占的比例是多少？如果一个索引的搜索量为 60%，而另一个索引的搜索量为 5%，我们就知道应该在哪里增加容量。

披萨背后的数学原理

我们按照以下公式计算最佳副本数量：

其中：

• L = 索引的相对搜索负载（介于 0 和 1 之间）。

• N = 项目中所需搜索节点的数量。

• S = 索引中的分片数量。

• X = 用于避免热点的阈值（默认值：0.5）。

示例：四个搜索节点，具有两个主分片的一个索引，接收 80% 的搜索流量：

这个热索引有四个副本，分布在各个搜索节点上。

阈值 X（默认为 0.5）非常重要。我们不会等到副本完全不堪重负才采取行动；当副本的负载达到一半容量时，我们就会进行扩展。当看到人群聚集时再分发额外的披萨，而不是等到宾客已经开始离开的时候。

快速扩展，缓慢收缩

当搜索负载增加时，我们立即添加副本。没有理由让用户等待。

当搜索负载下降时，我们会等待一段时间再采取行动。在减少副本之前，我们需要看到持续约 30 分钟的低需求。（这是为了应对流量高峰，因为短暂的平静并不意味着派对结束。）

这很重要，因为添加副本是有成本的。在高效提供查询之前，新的副本会复制数据并预热其缓存。过于急切地移除副本意味着在流量自然波动时持续支付这种启动成本。

尊重拓扑边界

副本永远不能超过搜索节点的数量。拥有比节点更多的副本并不会带来任何好处（您能送出的披萨数量取决于帮忙的朋友数量）。

从您的项目中移除节点时，我们会立即减少副本数量以进行匹配。无需等待冷却时间，因为您无法拥有未分配的副本。朋友离开的那一刻，我们就会移除他们的披萨。

无服务器的全貌

用于搜索负载均衡的副本与其他自动缩放系统协同工作：

• 搜索自动缩放可调整搜索节点的数量（有多少朋友在帮忙）。

• 用于搜索负载均衡的副本通过调整每个索引的副本数量来分发流量（我们需要每种披萨的数量）。

• 数据流自动分片优化了写入的分片数量（如何将每个披萨切片，详情见上一篇文章）。

一个重要的设计原则：用于负载均衡的副本不会直接触发搜索自动扩展。相反，通过将搜索请求分发给更多副本，可以提高搜索节点的资源利用率。这种更高的利用率会触发我们现有的自动扩展逻辑，以便在需要时增加容量。用于负载均衡的副本可让自动扩展发挥作用，确保搜索节点真正得到使用，而不是将所有流量都集中在单个副本上造成瓶颈，而其他节点却处于闲置状态。

这对您意味着什么

您无需预测哪些索引会更受欢迎。当流量模式发生变化时，您无需手动调整副本。您无需因为流量激增导致最繁忙的索引不堪重负，而不得不凌晨 3 点起床进行处理。

系统会观察排队的地点，并为这些地点订购更多披萨。冷索引不会在不必要的副本上浪费资源。热门索引会获得所需的容量。您的预算用在了最重要的地方。

结论

在自动分片文章中，我们确保您的披萨切得恰到好处。现在，有了用于搜索负载均衡的副本，我们可以确保在饥饿的人群到来时，有足够的披萨送到他们手中。

试用 Elastic Cloud Serverless，让我们来处理披萨分发事宜。