Kafka Linking：揭秘 AutoMQ 如何实现全球首个Zero-Downtime Kafka 迁移方案

最新推荐文章于 2025-12-09 10:39:30 发布

原创

最新推荐文章于 2025-12-09 10:39:30 发布 · 941 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#kafka #分布式

前言

AutoMQ 是一款基于云存储全新设计的 Kafka 发行版，相较传统的 Apache Kafka 拥有 10 倍的成本优势和秒级的弹性能力。为帮助用户从原有的 Kafka 集群无损切换至 AutoMQ，我们在 5.0 版本中发布了 Kafka Linking —— 一种无停机时间（Zero Downtime）的全托管跨集群数据同步功能。当前业界现有的多种 Kafka 集群数据同步工具，如 MirrorMaker 2 [1]， Confluent Cluster Linking [2]， WarpStream Orbit [3] 等，在实现集群迁移时均要求发送端和消费端进行“停机”、“等待”、“重启”的三步过程，该操作过程不仅冗长，且由于等待时间不可控，导致迁移过程风险难以评估，从而进一步降低用户的使用体验。而使用 AutoMQ Kafka Linking 进行集群迁移，客户端仅需完成一次滚动升级，将客户端从原有的 Kafka 集群指向 AutoMQ 集群即可完成迁移，相较现有方案极大减少了人为操作成本。本文将介绍如何使用 AutoMQ Kafka Linking 从 Kafka 集群无损迁移至 AutoMQ，以及 Kafka Linking 背后的技术原理。

现有技术方案的痛点

以 Confluent 为例，下图是使用 Confluent Cluster Linking 进行集群迁移的过程 [4]：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

ref:https://docs.confluent.io/cloud/current/_images/cluster-link-migrate-cc.png
可以看到，在迁移过程中，需要先停止源集群生产者，等待集群同步延迟为零后，对 Mirror Topic 进行 Promote（即停止同步），然后再将生产者重启并指向目标集群，在此过程可能导致分钟级的不可用时间。而业界其余方案（MM2， Orbit 等）的迁移过程也基本类似，原因在于这类方案均采用了单向同步链路，为避免消息分叉，在进行客户端迁移时需保证源集群与目标集群的数据已完全对齐且无新增。而 AutoMQ 在单向同步的基础上额外实现了反向转发，支持源集群和目标集群同时写入并保证写入一致性，从而实现一次滚动升级即可完成迁移。

使用 Kafka Linking 进行集群迁移

本节将介绍如何从任意一个支持 Kafka 协议的集群迁移至 AutoMQ 集群，下图为迁移步骤概览：使用 AutoMQ Console UI 进行迁移的具体步骤可参考 AutoMQ 官方文档：https://www.automq.com/docs/automq-cloud/migrate-to-a