总结下自己在尝试Kafka分区迁移过程中对这部分知识的理解,请路过高手指正。
关于Kafka数据迁移的具体步骤指导,请参考如下链接: http://www.cnblogs.com/dycg/p/3922352.html 原文作者写的非常清晰。
本文主要侧重自己对相关Kafka源代码的理解:
generateAssignment()函数 (对应上述链接原文中的 --generate 参数)产生新的迁移计划,输出格式为Json字符串;
executeAssignment ()函数(对应上述链接原文中的 --execute 参数)并不是真正执行分区数据迁移,他只是将上面生成的迁移计划保存到ZK中,路径为 /admin/reassign_partitions
Broker controller在启动或者重新选举时,会初始化一个ZK Watch --- 针对/admin/reassign_partition的监听(PartitionsReassignedListener);
我们通过命令行启动一次新的Topic数据迁移,会触发这个Listener,,从而使得Broker Controller开始迁移操作。
在处理Topic迁移事件之前,Controller会做一下预检,以下两种情况将不被迁移:
a. 某个Partition正在被迁移;
b. 该Topic已经列入被删除(Delete)之列;
关于Kafka数据迁移的步骤,具体实现在 kafka controller中的onPartitionReassignment()函数:
在详细介绍迁移步骤之前,先解释三个术语:
RAR: 新的replica位置映射(replica[Topic+Partition] <--> Broker, 以下同。)
OAR: 原来的replica位置映射
AR: 目前的replica位置映射
Kafka (Topic)Partition迁移步骤:
<1> Kafka Controller首先会将存储在ZK中的AR信息更新为 RAR+OAR, 然后为每个partition更新leaderEpoch和ISR;
<2> 接下来Controller会等待RAR中所有的replica都完成与各自leader的同步,并将RAR中所有的replica设为在线状态;
<3> 两种条件下需要重新进行Replica Leader选举:
a. 如果RAR中不包含一个Partition的Replica Leader;
b. 或者RAR中包含这个Partition的Replica Leader, 但是Leader所在的Broker挂掉了。
<4> 将OAR-RAR得到的差集中所有Replica(被迁移到其他Broker节点上的源replica)设为Offline,ZK中的ISR信息也会自动剔除Offline Replica;
<5> 将第四步中处于(OAR-RAR)的Replica设为不存在状态(NonExistentReplica),最终触发相关replica的物理删除;
<6> ZK中的AR信息被更新为 RAR;
<7> 从ZK中/admin/reassign_partitions路径删除这个Partition;
<8> 告知Brokers更新Metadata ( leaderEpoch之类 );
多谢各位网友关注,如果需要引用本文时,请注明本文链接。感谢您的合作 :-)
IT人的微信自媒体--- 杰天空, 走在寻找创意的路上
发掘创意,点缀生活,品味人生。
请搜索微信订阅号: jksy_studio ,或者微信扫描头像二维码添加关注