總結下自己在嘗試Kafka分割槽遷移過程中對這部分知識的理解，請路過高手指正。

本文主要側重自己對相關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 ，或者微信掃描頭像二維碼新增關注