作者：来自 Elastic Andrei Dan
了解 Elastic Cloud Serverless 如何根据搜索负载自动调整索引副本数量，在无需手动配置的情况下确保最佳查询性能。
通过使用 Elastic Cloud Serverless，让你从运维中解放出来。自动扩展，轻松应对流量高峰，并专注于构建 —— 立即开启 14 天免费试用，亲自测试体验！
你可以按照这些指南构建 AI-Powered 搜索体验，或者在业务系统和软件之间实现搜索。
在 Elastic Cloud Serverless 中，我们会根据搜索负载自动调整索引的副本数量，在无需任何手动配置的情况下确保最佳查询性能。在这篇 blog 中，我们将解释副本是如何扩展的、系统在什么时候增加或删除副本，以及这对你的索引意味着什么。
派对开始变得拥挤
你正在举办一场披萨派对。你有几个朋友帮你分发披萨，每个人都站在房间的不同位置。你给每个朋友一张披萨，他们开始在客人到来时把披萨分发给饥饿的客人。
一开始一切都很顺利。只有少数客人陆续到来，你的朋友在分发披萨，每个人都很开心。但随后关于你的酸面团披萨的消息传开了。门铃不停地响。客人不断涌入。很快，其中一位朋友周围开始聚集人群 —— 那位拿着意大利辣香肠披萨的朋友，因为大家似乎都想要这个。
拿着意大利辣香肠披萨的朋友已经忙不过来了。客人开始等待，变得不耐烦，并且已经排起了长队。与此同时，另一位拿着玛格丽特披萨的朋友却几乎没有人来拿。
你会怎么做？
你会再订几张意大利辣香肠披萨，并把它们分给其他朋友。现在不是只有一个人拿这种披萨，而是三个人。人群被分散开来，你突然可以同时服务三倍的客人。
当你举办更多派对时，会逐渐发现一些规律：
- 并不是所有披萨都一样受欢迎。有些需求很高，有些却很少有人要。你不需要为不受欢迎的披萨准备额外的 “副本”。你需要为排队的那种准备更多。
- 在队伍变得太长之前就订更多披萨。如果你等到朋友已经完全忙不过来，客人开始生气离开，那就已经太晚了。最好是在你看到人群开始聚集时就增加一张披萨。
- 不要太快把披萨收走。仅仅因为拿辣香肠披萨的朋友周围的人群减少了五分钟，并不意味着高峰已经结束。也许他们只是去倒饮料，甚至只是互相聊天（现在还有人这样吗？）。把额外的披萨先保留着。如果这种空档持续一段时间，再收起来也不晚。
- 你能分发多少披萨取决于帮忙的朋友数量。如果只有四个朋友帮忙，就算有十张披萨也不会改变结果。一次只能服务四个人。让披萨数量和可用的人手匹配。
- 当有朋友离开时，记得拿回他们手里的披萨。如果其中一个朋友需要离开，立刻把披萨拿回来。你不能让披萨无人看管。要么交给别人，要么收起来。
从披萨到副本
让我们把这个类比映射回 Elasticsearch。
在这个类比中，披萨就是副本（你的索引分片的副本），帮忙分发的朋友就是 search nodes，饥饿的客人就是 search queries，而那个被人群围住的热门披萨就是一个具有高搜索负载的 hot index。
当某个索引的搜索流量增加时，我们会创建额外的副本，并将它们分布到你的 search nodes 上。任何一个副本都可以处理该索引的任何查询，就像任何一个拿着辣香肠披萨的朋友都可以分发一样。副本越多，吞吐量越高：3 个副本可以处理单个副本每秒查询量的 3 倍。
衡量 “饥饿程度”
在我们决定要订多少披萨之前，我们需要知道人群有多 “饿”。
Elasticsearch 会跟踪每个分片的搜索负载。这是一个衡量分片正在处理多少搜索活动的指标。然后我们会把这些数据在索引层面进行聚合，以了解整体的搜索需求。
最重要的是相对搜索负载：你的项目中每个索引占总搜索流量的比例是多少？如果一个索引接收了 60% 的搜索请求，而另一个只有 5%，我们就知道应该在哪里增加容量。
披萨背后的数学原理
我们使用以下公式来计算最佳副本数量：
`desired_replicas = min(ceil(L × N / (S × X)), N)`AI写代码
其中：
- L = 索引的相对搜索负载（介于 0 到 1 之间）。
- N = 你的项目中期望的 search nodes 数量。
- S = 索引中的分片数量。
- X = 用于避免热点的阈值（默认值：0.5）。
一个示例：4 个 search nodes，一个包含 2 个主分片的索引接收了 80% 的搜索流量：
`
1. desired_replicas = min(ceil(0.8 × 4 / (2 × 0.5)), 4)
2. = min(4, 4)
3. = 4
`AI写代码
这个热点索引会获得 4 个副本，并分布在各个 search nodes 上。
阈值 X（默认值为 0.5）非常重要。我们不会等到某个副本完全过载才扩展；而是在其达到一半容量时就进行扩展。要在看到人群开始聚集时就分发额外的披萨，而不是等到客人已经开始离开。
快速扩展，缓慢收缩
当搜索负载增加时，我们会立即增加副本，没有理由让用户等待。
当搜索负载下降时，我们会先等待一段时间再采取行动。我们需要观察大约 30 分钟的持续低需求，才会减少副本。（这是为了应对突发流量，短暂的低谷并不意味着派对已经结束。）
这很重要，因为增加副本是有成本的。新的副本需要复制数据并预热缓存，之后才能高效处理查询。如果过于频繁地移除副本，就会在流量自然波动时不断重复支付这种启动成本。
遵循拓扑限制
副本数量永远不会超过 search nodes 的数量。副本多于节点不会带来任何收益（就像你拥有的披萨数量再多，也无法超过帮忙分发的朋友数量）。
当你的项目中减少节点时，我们会立即减少副本以匹配，不会等待冷却时间，因为不能存在未分配的副本。一旦有朋友离开，我们就会立刻收回他们的披萨。
更大的 Serverless 全景
用于搜索负载均衡的副本机制与其他自动扩展系统协同工作：
- Search autoscaling 会调整 search nodes 的数量（有多少朋友在帮忙）。
- 用于搜索负载均衡的副本机制会通过调整每个索引的副本数量来分配流量（每种披萨需要多少份）。
- Data stream autosharding 会为写入优化分片数量（如何切分每个披萨，在上一篇文章中已介绍）。
一个重要的设计原则：用于负载均衡的副本不会直接触发 search autoscaling。相反，通过将搜索请求分布到更多副本上，它可以提升 search nodes 的整体资源利用率。这种更高的利用率会触发现有的自动扩展逻辑，从而在需要时增加容量。副本负载均衡使自动扩展能够真正发挥作用，确保所有 search nodes 都被利用，而不是让所有流量都集中在单个副本上，而其他节点处于空闲状态。
这对你意味着什么
你不需要预测哪些索引会变得热门。你不需要在流量模式变化时手动调整副本。你也不需要在凌晨 3 点因为突发流量压垮最繁忙的索引而被叫醒。
系统会自动观察哪里出现排队，并在这些地方增加“披萨”。冷数据索引不会浪费资源去维护不必要的副本。热点索引会获得所需的容量。你的预算会用在真正重要的地方。
总结
在 autosharding 的文章中，我们确保你的披萨被正确切分。现在，通过用于搜索负载均衡的副本机制，我们确保当饥饿的人群到来时，你拥有足够的披萨，并分配在合适的人手中。
试用 Elastic Cloud Serverless，让我们来帮你处理这些 “披萨调度” 的问题。
