在云原生时代，借助云厂商提供的节点弹性能力，我们已经能够很好的对一个线上集群完成节点级别的扩缩容，如 AWS 的 Auto Scaling Groups[1]、阿里云的 ESS 弹性伸缩组[2]，但是由于涉及到业务流量的迁移，Apache Kafka 集群往往无法直接应用云厂商提供的弹性能力，而需要运维人员介入手动进行流量的腾挪，耗时通常在小时级别，这对于流量频繁变化的线上集群来说，几乎不可能做到按需扩缩容，为了保障集群的稳定性，运维人员只能选择提前按照最大容量部署，避免流量峰值来临时临时扩容不及时产生的风险，而这也导致了大量的资源浪费。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 (ASG) 为例，通过配置流量阈值监控，当集群流量触及扩容阈值时，自动拉起新的 Broker 节点，此时 Controller 检测到流量存在不均衡，自动将分区移动至新创建的 Broker，完成流量的重新负载。 下图展示了一个 AutoMQ Kafka 集群的 Broker 数量随流量上涨发生的变化，可以看到随着流量的线性上升，Broker 被动态创建并加入集群平衡负载。
触发缩容
仍以 AWS Auto Scaling Groups 为例，当集群流量触及缩容阈值时，对即将缩容的 Broker 节点进行下线操作，此时该 Broker 上的分区将以 Round-Robin 方式在秒级内迁移至剩余 Broker 上，完成 Broker 的优雅下线及流量转移。 下图展示了一个 AutoMQ Kafka 集群的 Broker 数量随流量下降发生的变化，可以看到随着流量的线性下降，Broker 被动态下线节约资源。
在上述示例中，为便于观察，人为增加了 ASG 的节点扩缩容冷却时间，并增加了进程启动和销毁延迟
自动扩缩容的优势
AutoMQ 的共享存储架构，天然支持快速自动扩缩容，也是实现 Serverless 的基础。AutoMQ 支持自动扩缩容后至少带来以下几个优势：- 成本优势，无需按峰值准备资源，根据业务流量自动伸缩，有效应对潮汐型和突发型业务，按使用面积付费，无闲置资源浪费。
- 稳定性优势，扩容无损，不会对集群产生额外的流量压力，可以在高水位的状态下进行无损扩容。相反，Apache Kafka 的扩容是一个高风险操作，只能在低水位的情况下进行扩容。
- 多租户优势，具备自动扩缩容能力的集群，不在需要通过将业务混部来提高资源的利用率，完全可以为每个业务配置一个独立的集群。每个独立的集群根据自身的流量模型独立扩展即可。既保障了成本优势，又避免了某个业务出问题时带来全局的影响。