​本文已参与「新人创造礼」活动，一同开启创造之路。 ​

1.概述

Kafka的运用场景十分广泛，一些实时流数据业务场景，均依赖Kafka来做数据分流。而在散布式运用场景中，数据搬迁是一个比较常见的问题。关于Kafka集群数据如何搬迁，今天叶秋学长将为咱们详细介绍。

2.内容

本篇博客为咱们介绍两种搬迁场景，分别是同集群数据搬迁、跨集群数据搬迁。如下图所示：

​修改

2.1 同集群搬迁

同集群之间数据搬迁，比如在已有的集群中新增了一个Broker节点，此时需求将原来集群中已有的Topic的数据搬迁部分到新的集群中，缓解集群压力。

将新的节点增加到Kafka集群很简单，只需为它们分配一个唯一的Broker ID，并在新服务器上发动Kafka。可是，这些新服务器节点不会主动分配任何数据分区，因而除非将分区移动到新增的节点，否则在创建新Topic之前新节点不会履行任何操作。因而，一般在将新服务器节点增加到Kafka集群时，需求将一些现有数据搬迁到这些新的节点。

搬迁数据的进程是手动发动的，履行进程是彻底主动化的。在Kafka后台服务中，Kafka将增加新服务器作为其正在搬迁的分区的Follower，并答应新增节点彻底仿制该分区中的现有数据。当新服务器节点彻底仿制此分区的内容并加入同步副本（ISR）时，其间一个现有副本将删除其分区的数据。

Kafka体系供给了一个分区从头分配东西（kafka-reassign-partitions.sh），该东西可用于在Broker之间搬迁分区。理想情况下，将确保一切Broker的数据和分区均匀分配。分区从头分配东西无法主动剖析Kafka群集中的数据散布并搬迁分区以完结均匀的负载均衡。因而，管理员在操作的时分，有必要弄清楚应该搬迁哪些Topic或分区。

分区从头分配东西能够在3种互斥形式下运转：

• –generate：在此形式下，给定Topic列表和Broker列表，该东西会生成候选从头​​分配，以将指定Topic的一切分区搬迁到新Broker中。此选项仅供给了一种便利的办法，可在给定Topic和方针Broker列表的情况下生成分区从头分配方案。
• –execute：在此形式下，该东西将根据用户供给的从头分配方案发动分区的从头分配。 （运用–reassignment-json-file选项）。由管理员手动拟定自定义从头分配方案，也能够运用–generate选项供给。
• –verify：在此形式下，该东西将验证最后一次–execute期间列出的一切分区的从头分配状态。状态能够有成功、失利或正在进行等状态。

2.1.1 搬迁进程完结

分区从头分配东西可用于将一些Topic从当时的Broker节点中搬迁到新增加的Broker中。这在扩展现有集群时一般很有用，由于将整个Topic移动到新的Broker变得更简单，而不是一次移动一个分区。当履行此操作时，用户需求供给已有的Broker节点的Topic列表，以及到新节点的Broker列表（源Broker到新Broker的映射联系）。然后，该东西在新的Broker中均匀分配给指定Topic列表的一切分区。在搬迁进程中，Topic的仿制因子保持不变。

现有如下实例，将Topic为ke01，ke02的一切分区从Broker1中移动到新增的Broker2和Broker3中。由于该东西承受Topic的输入列表作为JSON文件，因而需求清晰搬迁的Topic并创建json文件，如下所示：

> cat topic-to-move.json
{"topics": [{"topic": "ke01"},
            {"topic": "ke02"}],
"version":1
}

准备好JSON文件，然后运用分区从头分配东西生成候选分配，指令如下：

> bin/kafka-reassign-partitions.sh --zookeeper dn1:2181 --topics-to-move-json-file topics-to-move.json --broker-list "1,2" --generate

履行命名之前，Topic（ke01、ke02）的分区如下图所示：

​

修改

​

修改

履行完结指令之后，控制台出现如下信息：

​

修改

该东西生成一个候选分配，将一切分区从Topic ke01，ke02移动到Broker1和Broker2。需求留意的是，此时分区移动没有开端，它只是告知你当时的分配和建议。保存当时分配，以防你想要回滚它。新的赋值应保存在JSON文件（例如expand-cluster-reassignment.json）中，以运用–execute选项履行。JSON文件如下：

{"version":1,"partitions":[{"topic":"ke02","partition":0,"replicas":[2]},{"topic":"ke02","partition":1,"replicas":[1]},{"topic":"ke02","partition":2,"replicas":[2]},{"topic":"ke01","partition":0,"replicas":[2]},{"topic":"ke01","partition":1,"replicas":[1]},{"topic":"ke01","partition":2,"replicas":[2]}]}

履行指令如下所示：

> ./kafka-reassign-partitions.sh --zookeeper dn1:2181 --reassignment-json-file expand-cluster-reassignment.json --execute

最后，–verify选项可与该东西一同运用，以检查分区从头分配的状态。需求留意的是，相同的expand-cluster-reassignment.json（与–execute选项一同运用）应与–verify选项一同运用，履行指令如下：

> ./kafka-reassign-partitions.sh --zookeeper dn1:2181 --reassignment-json-file expand-cluster-reassignment.json --verify

履行成果如下图所示：

​

修改

一同，咱们能够经过Kafka Eagle东西来检查Topic的分区情况。

​

修改

​

修改

2.2 跨集群搬迁

这儿跨集群搬迁，咱们指的是在Kafka多个集群之间仿制数据“镜像”的进程，以避免与单个集群中的节点之间发生的仿制混淆。 Kafka附带了一个用于在Kafka集群之间镜像数据的东西。该东西从源集群运用并生成到方针集群。这种镜像的一个常见用例是在另一个数据中心供给副本。

另外，你能够运转许多此类镜像进程以提高吞吐量和容错（假如一个进程终止，其他进程将占用额外负载）。将从源集群中的Topic读取数据，并将其写入方针集群中具有相同名称的主题。事实上，“镜像”数据只不过是一个Kafka将顾客和生产者联系在了一同。

源集群和方针集群是彻底独立的实体，它们能够具有不同数量的分区，并且偏移量将不相同。出于这个原因，镜像集群并不是真实意图作为容错机制（由于顾客的位置会有所不同）;为此，建议运用正常的集群内仿制。可是，镜像进程将保存并运用音讯Key进行分区，因而能够按Key保存次序。

下面是一个跨集群的单Topic实例，指令如下：

> ./kafka-mirror-maker.sh --consumer.config consumer.properties --producer.config producer.properties --whitelist ke03

需求留意的是，consumer.properties文件装备源Kafka集群Broker地址，producer.properties文件装备方针Kafka集群地址。假如需求搬迁多个Topic，能够运用 –whitelist ‘A|B’，假如需求搬迁一切的Topic，能够运用 –whitelist ‘*’。

3.成果预览

履行跨集群搬迁指令后，方针集群中运用Kafka Eagle中检查Topic Size巨细看是否与源集群的Topic Size巨细相等，或许运用SQL语句，验证是否有数据搬迁过来，成果如下图所示：

​

修改

4.总结

跨集群搬迁数据的本质是，Kafka发动了顾客读取源集群数据，并将消费后的数据写入到方针集群，在搬迁的进程中，能够发动多个实例，供给迁出的吞吐量。

本期共享到此为止，重视博主不迷路，叶秋学长带你上高速

​