一、背景引入

在大数据处理的世界里，Kafka 是一个非常重要的消息队列系统。一开始，Kafka 使用 ZooKeeper 作为注册中心，来管理和协调集群里的各种信息。不过后来，Kafka 推出了自己的注册中心方案 KRaft，它能让 Kafka 运行得更独立，减少对外部系统 ZooKeeper 的依赖。当我们要把 Kafka 的注册中心从 ZooKeeper 迁移到 KRaft 时，就会遇到一个大问题：存量数据该怎么同步，又怎么保证新旧系统兼容呢？下面咱们就好好唠唠这个事儿。

二、应用场景

2.1 系统升级

很多企业随着业务的发展，对 Kafka 的性能和稳定性要求越来越高。ZooKeeper 虽然一直表现不错，但它在大规模集群下可能会有性能瓶颈。这时候，把注册中心迁移到 KRaft 就成了一个好选择。比如说，有一家电商公司，他们的 Kafka 集群规模越来越大，每天要处理海量的订单消息、用户行为数据等。ZooKeeper 处理起来越来越吃力，时不时就会出现响应缓慢的情况。于是，他们决定把注册中心换成 KRaft，以提升系统整体性能。

2.2 技术架构优化

有些公司为了简化技术架构，减少外部依赖，也会选择迁移到 KRaft。像一家互联网金融公司，他们的技术栈里有很多不同的组件，其中 ZooKeeper 不仅给 Kafka 用，还给其他服务用。这就导致管理起来很复杂，出了问题也不好排查。为了让架构更清晰，他们就想把 Kafka 的注册中心独立出来，采用 KRaft 方案，这样管理起来就轻松多了。

三、迁移前的准备工作

3.1 环境评估

在动手迁移之前，得先对现有的 Kafka 环境做个全面评估。看看当前 Kafka 集群的规模，有多少个节点，每个节点的配置是怎样的。还要了解集群里的数据量，包括消息的大小、生产和消费的速率等。比如说，一个拥有 10 个节点的 Kafka 集群，每天要处理 100GB 的消息数据，那在迁移过程中就要考虑数据同步的速度和稳定性。

# 查看 Kafka 集群节点信息
bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe

这段命令可以让我们了解 Kafka 集群里各个节点的详细信息，方便我们评估环境。

3.2 数据备份

数据就是公司的命根子，所以在迁移之前一定要做好数据备份。可以使用 Kafka 的 mirror maker 工具，把集群里的数据备份到一个临时的存储位置。

# 使用 mirror maker 进行数据备份
bin/kafka-mirror-maker.sh --consumer.config consumer.properties --producer.config producer.properties --whitelist=".*"

这里的 consumer.properties 和 producer.properties 是配置文件，分别配置了消费者和生产者的相关参数。通过这个命令，就可以把 Kafka 里的数据备份到另一个地方，以防迁移过程中出现数据丢失的情况。

四、存量数据同步方案

4.1 全量同步

全量同步就是把 ZooKeeper 里的所有存量数据一次性全部复制到 KRaft 中。这种方法简单直接，适合数据量比较小的情况。比如说，一个小团队的 Kafka 集群，数据量只有几百 MB，就可以采用全量同步的方式。

# 全量同步示例（假设使用自定义脚本）
./full_sync_script.sh

这里的 full_sync_script.sh 是一个自定义的脚本，它会把 ZooKeeper 里的数据全部读取出来，然后写入到 KRaft 中。不过全量同步也有缺点，就是如果数据量很大，同步的时间会很长，而且在同步过程中可能会影响 Kafka 的正常使用。

4.2 增量同步

增量同步只同步自某个时间点之后发生变化的数据。这种方法适合数据量比较大的情况。还是拿前面提到的电商公司来说，他们的 Kafka 集群每天有大量的数据更新，如果采用全量同步，可能几天都同步不完。这时候就可以采用增量同步的方式。

# 增量同步示例（使用 Kafka Connect）
bin/connect-standalone.sh config/connect-standalone.properties config/connect-incremental-sync.properties

这里的 connect-standalone.properties 是 Kafka Connect 的基本配置文件，connect-incremental-sync.properties 是增量同步的具体配置文件。通过 Kafka Connect，我们可以实时监测 ZooKeeper 里的数据变化，并把这些变化同步到 KRaft 中。

五、兼容方案选择

5.1 双注册中心模式

在迁移过程中，可以让 Kafka 同时使用 ZooKeeper 和 KRaft 作为注册中心。这样，旧的应用程序可以继续使用 ZooKeeper 来获取 Kafka 集群的信息，新的应用程序则可以使用 KRaft。比如说，一家公司有很多旧的业务系统，这些系统已经和 ZooKeeper 深度集成，短时间内很难修改。这时候就可以采用双注册中心模式，让新旧系统都能正常运行。

# Kafka 配置文件中开启双注册中心
zookeeper.connect=localhost:2181
kraft.controller.quorum.voters=1@localhost:9093

在 Kafka 的配置文件里，同时配置 ZooKeeper 和 KRaft 的连接信息，就可以实现双注册中心模式。不过这种模式也有缺点，就是管理起来比较复杂，需要同时维护两个注册中心。

5.2 逐步迁移模式

逐步迁移模式就是先把一部分 Kafka 节点迁移到 KRaft 上，等这部分节点稳定运行后，再逐步迁移其他节点。比如说，一个有 20 个节点的 Kafka 集群，可以先把其中的 5 个节点迁移到 KRaft 上，观察一段时间，看看有没有问题。如果一切正常，再继续迁移其他节点。这种模式可以降低迁移的风险，但是迁移的时间会比较长。

六、技术优缺点分析

6.1 全量同步优缺点

优点：操作简单，一次性把数据全部同步过去，不需要考虑数据的增量变化。对于数据量小的情况，能快速完成同步。 缺点：同步时间长，尤其是数据量大的时候，可能会导致 Kafka 服务长时间不可用。而且在同步过程中，如果有新的数据产生，可能会导致数据不一致。

6.2 增量同步优缺点

优点：只同步变化的数据，同步速度快，对 Kafka 服务的影响小。适合数据量大、更新频繁的场景。 缺点：实现起来比较复杂，需要实时监测数据的变化，并且要保证数据的一致性。

6.3 双注册中心模式优缺点

优点：可以让新旧系统同时兼容，减少迁移对业务的影响。旧的应用程序不需要做任何修改就可以继续使用。 缺点：管理复杂，需要同时维护两个注册中心。而且可能会出现数据不一致的问题，因为两个注册中心的数据可能会有延迟。

6.4 逐步迁移模式优缺点

优点：风险低，通过逐步迁移，可以及时发现和解决问题，保证迁移过程的稳定性。 缺点：迁移时间长，会影响整个迁移的进度。而且在迁移过程中，需要对集群进行多次调整，增加了操作的复杂性。

七、注意事项

7.1 数据一致性

在数据同步过程中，一定要保证数据的一致性。无论是全量同步还是增量同步，都要确保 KRaft 里的数据和 ZooKeeper 里的数据是一样的。比如说，在增量同步过程中，如果出现网络故障，导致部分数据没有及时同步，就要有相应的机制来进行数据修复。

7.2 性能影响

迁移过程中可能会对 Kafka 的性能产生影响。比如说，全量同步时，大量的数据复制会占用很多系统资源，导致 Kafka 的响应速度变慢。所以在迁移之前，要做好性能测试，评估迁移对系统的影响，并制定相应的应对措施。

7.3 版本兼容性

要确保 Kafka、ZooKeeper 和 KRaft 的版本是兼容的。不同版本之间可能会有一些差异，如果版本不兼容，可能会导致迁移失败或者出现其他问题。比如说，某些版本的 Kafka 对 KRaft 的支持可能不太完善，这时候就需要升级到合适的版本。

八、文章总结

把 Kafka 的注册中心从 ZooKeeper 迁移到 KRaft 是一个复杂的过程，需要我们在存量数据同步和兼容方案选择上做好充分的准备。我们可以根据实际的应用场景，选择合适的数据同步和兼容方案。全量同步适合数据量小的情况，增量同步适合数据量大、更新频繁的情况。双注册中心模式可以让新旧系统同时兼容，逐步迁移模式可以降低迁移风险。在迁移过程中，要注意数据一致性、性能影响和版本兼容性等问题。通过合理的规划和实施，我们可以顺利完成迁移，让 Kafka 系统更加稳定和高效。