> ## Documentation Index
> Fetch the complete documentation index at: https://docs.automq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 秒级平滑扩缩容

> AutoMQ具备秒级平滑扩缩容能力，实现云原生弹性，无需手动干预，降低成本，提升稳定性，确保资源高效利用并支持多租户环境。

在云原生时代，借助云厂商提供的节点弹性能力，我们已经能够很好的对一个线上集群完成节点级别的扩缩容，如 AWS 的 Auto Scaling Groups\[1]、阿里云的 ESS 弹性伸缩组\[2]，但是由于涉及到业务流量的迁移，Apache Kafka 集群往往无法直接应用云厂商提供的弹性能力，而需要运维人员介入手动进行流量的腾挪，耗时通常在小时级别，这对于流量频繁变化的线上集群来说，几乎不可能做到按需扩缩容，为了保障集群的稳定性，运维人员只能选择提前按照最大容量部署，避免流量峰值来临时临时扩容不及时产生的风险，而这也导致了大量的资源浪费。

## AutoMQ 如何实现秒级的平滑扩缩容

<img src="https://mintcdn.com/automq/C1RFhd9pcTVZzYyW/zh/automq/architecture/technical-advantage/scale-outin-in-seconds/1.webp?fit=max&auto=format&n=C1RFhd9pcTVZzYyW&q=85&s=224b0b3b3930d4389b8fcb9d7e2af7ec" width="2560" height="1112" data-path="zh/automq/architecture/technical-advantage/scale-outin-in-seconds/1.webp" />

AutoMQ 秒级扩缩容的特性依赖一个原子能力，即秒级分区迁移（参考[秒级分区迁移▸](/zh/automq/architecture/technical-advantage/partition-reassignment-in-seconds)）。

当借助弹性伸缩组 ASG 或者 Kubernetes 的 HPA\[3] 完成了节点的扩容后，这时仅需要将集群中的部分分区批量地迁移至新节点，即可完成流量的重平衡（参考[持续数据自平衡▸](/zh/automq/architecture/technical-advantage/continuous-self-balancing)），这往往能在十秒级完成。

### 触发扩容

以 AWS Auto Scaling Groups (ASG) 为例，通过配置流量阈值监控，当集群流量触及扩容阈值时，自动拉起新的 Broker 节点，此时 Controller 检测到流量存在不均衡，自动将分区移动至新创建的 Broker，完成流量的重新负载。

下图展示了一个 AutoMQ Kafka 集群的 Broker 数量随流量上涨发生的变化，可以看到随着流量的线性上升，Broker 被动态创建并加入集群平衡负载。

<img src="https://mintcdn.com/automq/C1RFhd9pcTVZzYyW/zh/automq/architecture/technical-advantage/scale-outin-in-seconds/2.webp?fit=max&auto=format&n=C1RFhd9pcTVZzYyW&q=85&s=5ca9ca725c39fa12d2aad8f110911a73" width="2560" height="904" data-path="zh/automq/architecture/technical-advantage/scale-outin-in-seconds/2.webp" />

下图展示了流量上涨过程中，各 Broker 节点的流量变化，可以看到新创建的 Broker 均在十秒级完成了流量的重新负载。

<img src="https://mintcdn.com/automq/C1RFhd9pcTVZzYyW/zh/automq/architecture/technical-advantage/scale-outin-in-seconds/3.webp?fit=max&auto=format&n=C1RFhd9pcTVZzYyW&q=85&s=46fa73970e538a11b473f9fdefe190a2" width="2560" height="880" data-path="zh/automq/architecture/technical-advantage/scale-outin-in-seconds/3.webp" />

### 触发缩容

仍以 AWS Auto Scaling Groups 为例，当集群流量触及缩容阈值时，对即将缩容的 Broker 节点进行下线操作，此时该 Broker 上的分区将以 Round-Robin 方式在秒级内迁移至剩余 Broker 上，完成 Broker 的优雅下线及流量转移。

下图展示了一个 AutoMQ Kafka 集群的 Broker 数量随流量下降发生的变化，可以看到随着流量的线性下降，Broker 被动态下线节约资源。

<img src="https://mintcdn.com/automq/C1RFhd9pcTVZzYyW/zh/automq/architecture/technical-advantage/scale-outin-in-seconds/4.webp?fit=max&auto=format&n=C1RFhd9pcTVZzYyW&q=85&s=6d93e4b20eafc7c3c1d15189759ff88c" width="2560" height="840" data-path="zh/automq/architecture/technical-advantage/scale-outin-in-seconds/4.webp" />

下图展示了流量下降过程中，各 Broker 节点的流量变化，可以看到下线中的 Broker 的负载被转移到其余 Broker 上（每当 Broker 下线时，可观察到其余 Broker 流量有显著上升）。

<img src="https://mintcdn.com/automq/C1RFhd9pcTVZzYyW/zh/automq/architecture/technical-advantage/scale-outin-in-seconds/5.webp?fit=max&auto=format&n=C1RFhd9pcTVZzYyW&q=85&s=b0104fed052577517b577e876a12c3de" width="2560" height="786" data-path="zh/automq/architecture/technical-advantage/scale-outin-in-seconds/5.webp" />

<Note>
  在上述示例中，为便于观察，人为增加了 ASG 的节点扩缩容冷却时间，并增加了进程启动和销毁延迟
</Note>

## 自动扩缩容的优势

AutoMQ 的共享存储架构，天然支持快速自动扩缩容，也是实现 Serverless 的基础。AutoMQ 支持自动扩缩容后至少带来以下几个优势：

* 成本优势，无需按峰值准备资源，根据业务流量自动伸缩，有效应对潮汐型和突发型业务，按使用面积付费，无闲置资源浪费。

* 稳定性优势，扩容无损，不会对集群产生额外的流量压力，可以在高水位的状态下进行无损扩容。相反，Apache Kafka 的扩容是一个高风险操作，只能在低水位的情况下进行扩容。

* 多租户优势，具备自动扩缩容能力的集群，不在需要通过将业务混部来提高资源的利用率，完全可以为每个业务配置一个独立的集群。每个独立的集群根据自身的流量模型独立扩展即可。既保障了成本优势，又避免了某个业务出问题时带来全局的影响。

## 引用

\[1]. AWS Auto Scaling Groups: [https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)

\[2]. 阿里云 ESS 弹性伸缩组：[https://www.aliyun.com/product/ecs/ess](https://www.aliyun.com/product/ecs/ess)

\[3]. Kubernetes 用于扩容的 HPA 组件：[https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)