总结下自己在尝试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之类 )；