> ## 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 的共享存储架构实现秒级分区迁移，保障快速扩容与高效运维，提升集群弹性和可靠性。 分区是 Apache Kafka 中的核心资源模型，也是客户端读写流量的承载点，随着集群中分区越来越多，会逐渐发生分区分布不均衡，热点分区等现象。所以，在日常运维 Apache Kafka 中，进行分区迁移是常规的高频运维操作。 但 Shared Nothing 架构下的 Apache Kafka，进行分区迁移依赖复制大量的数据，以一个 100MiB/s 流量的 Kafka 分区为例，运行一天产生的数据量约为 8.2T，如果此时需要将该分区迁移到其他 Broker，则需要对全量数据进行复制，即使对拥有 1 GBps 带宽的节点，也需要小时级的时间来完成迁移，这使得 Apache Kafka 集群几乎不具备实时弹性能力。 而得益于 AutoMQ 的共享存储架构，在实际进行分区迁移时仅需同步少量数据，这使得将分区迁移时间缩短至秒级成为了可能。 ## AutoMQ 如何实现秒级分区迁移 在 AutoMQ 的共享存储架构下，几乎所有的数据存储在对象存储中，极少的数据会短暂地停留在 WAL 存储中，当进行分区迁移时，仅需将未及时上传至对象存储而短暂停留在 WAL 中的数据进行强制上传，然后就可以将分区安全转移至其他节点，基本上能在 1.5 秒左右完成。 具体的迁移流程如上图，以分区 P1 从 Broker-0 迁移至 Broker-1 为例： 1. 当 KRaft Controller 收到分区迁移命令时，会构建出相应的 PartitionChangeRecord 并 Commit 至 KRaft Log 层，将 Broker-0 从 Leader Replica 列表中删除，并将 Broker-1 加入 Follower Replica 列表中。Broker-0 同步 KRaft Log 监听到 P1 分区变更，进入分区关闭流程。 2. 分区关闭时，若 P1 还存在未上传至对象存储的数据，则会触发强制上传，而在一个稳定运行的集群中，这部分数据往往在百 MB左右，结合目前云厂商提供的突发网络带宽能力，这个过程一般仅需秒级即可完成。当 P1 的数据上传完成后，即可安全的关闭并从 Broker-0 删除分区 P1。 3. P1 从 Broker 完成关闭后会主动触发一次选主，此时 Broker-1 作为唯一的 Replica 晋升为 P1 的 Leader，进入分区恢复流程。 4. 分区恢复时，会从对象存储中拉取 P1 对应的元数据，从而恢复出 P1 相应的 Checkpoint，后根据 P1 的关闭状态（是否为 Cleaned Shutdown）进行对应的数据恢复。 5. 至此分区迁移完成。 ## 秒级分区迁移的意义 在生产环境中，一个 Kafka 集群通常会服务多个业务，业务的流量波动和分区分布可能造成集群容量不足或者机器热点，Kafka 运维人员需要通过集群扩容，并且将热点分区迁移到空闲的节点，来保障集群的服务可用性。 分区迁移的时间决定了应急和运维效率： * 分区迁移的时间越短，集群从扩容到容量满足诉求的时间越短，服务受损的时间越短。 * 分区迁移越快，运维人员观测的时间更短，可以更快的得到运维反馈决策后续的动作。 在 AutoMQ 的架构中，秒级的分区迁移是实现很多自动化能力的基础，包括自动扩容、缩容以及持续性流量重平衡等。 ## 快速体验 参考 [示例：验证秒级分区迁移▸](/zh/automq/getting-started/explore-automq/example-partition-reassignment-in-seconds) 体验 AutoMQ 的秒级分区迁移能力。