附註：

• 此教學課程需要存取 Oracle Cloud。若要註冊免費帳戶，請參閱開始使用 Oracle Cloud Infrastructure Free Tier 。
• 它使用 Oracle Cloud Infrastructure 憑證、租用戶及區間的範例值。完成實驗室時，請將這些值取代為您雲端環境特有的值。

零停機地移轉 Kafka 和 Zookeeper 叢集

簡介

許多服務 (雲端原生或內部部署) 都使用 Kafka 叢集滿足其非同步訊息傳遞需求，因為它是可擴展的訊息傳遞技術。您可能因為業務需求而必須取代一組節點或整個叢集。本教學課程主要討論將 Kafka 和 Zookeeper 叢集移轉至一組新的節點，但不會發生停止工作的情形。

問題說明

為何要以另一個節點取代叢集中的節點會是一項挑戰？從負載平衡器背後的一組節點新增或移除節點是無所不在的：新增節點、清空要移除的現有節點、終止所有進行中的連線之後、將其關閉、將其自負載平衡器組態移除等等。

實際的挑戰在於使用應用程式進行狀態管理。通常，應用程式是無狀態的，並將狀態持續性委派給資料管理系統，例如關聯式資料庫管理系統 (RDBMS)。相對於這類應用程式，Kafka 和 Zookeeper 都會管理本機狀態，亦即使用本機磁碟進行狀態持續性。這表示，我們無法只將節點取代為另一個節點，而不需要處理現有節點的本機狀態。

此外，如果是 Kafka，只要新增節點，就不會自動開始任何工作負載重新平衡，也就是將主題分割區重新分配給中介。新節點只會參與從此時間點開始建立之新主題的工作負載共用。

仲裁型系統有一個作業問題 (在此情況下為 Zookeeper) 是需要事先知道叢集大小，這表示每個節點都必須具備叢集中所有其他節點的知識。此外，若要進一步複雜，如果您要一次新增一個以上的節點 (確實數目取決於現有的叢集大小)，則必須確保其中一個新增的節點不會成為領導者，否則我們將會遺失資料。

目標

• 將 Kafka 和 Zookeeper 叢集以零停機方式移轉至另一組節點。

必要條件

• 瞭解 Kafka 和 Zookeeper 架構。

移轉 Kafka 叢集

取代 Kafka 叢集中的節點相對簡單。新增中介並呼叫主題分割區移轉，一旦完成移轉，我們就可以將舊的中介淘汰。Kafka 提供 admin API 來執行分割區移轉。alterPartitionReassignments 的運作方式是將其他分割區複本新增至主題，等待複本成為 ISR 的成員，然後交換分割區引線。

您必須對舊的中介停用新的主題分割區指派 (如果應用程式邏輯在程式實際執行時建立主題)，否則這會變成無止盡的移轉迴圈。為達到此目的，使用者可以使用不同主題建立 API 來指定分割區指派。下面列出可遵循的範例演算法。

• 針對要建立的主題和一組中介 ID，不應指派任何分割區或複本：主題分割區及其複本會以循環方式指派給其餘的中介。我們假設經紀人 ID 是以 AD 的循序方式建立，然後以 FD 建立。例如，假設有 3 個 AD (AD-1，AD-2，AD-3)，且每個 AD 有 2 個 FD (FD-1，FD-2)，且有 6 個 ID 為 (1-6) 的中介，則它們會依下列順序放置。

  broker ID 1 -> AD-1, FD-1
  broker ID 2 -> AD-2, FD-1
  broker ID 3 -> AD-3, FD-1
  broker ID 4 -> AD-1, FD-2
  broker ID 5 -> AD-2, FD-2
  broker ID 6 -> AD-3, FD-2
  

• 這有助於將分割區及其複本放在不同的失敗網域中。演算法如下：我們排序經紀人 ID，並以隨機選取的 ID 開始，以循序放置。例如，如果主題包含 3 個分割區和複製因子 3，而隨機選取的中介 ID 為 3，以下是分割區或複本的位置順序。

  partition-0, replica-0 -> 3
  partition-0, replica-1 -> 4
  partition-0, replica-2 -> 5
  partition-1, replica-0 -> 4
  partition-1, replica-1 -> 5
  partition-1, replica-2 -> 6
  partition-2, replica-0 -> 5
  partition-2, replica-1 -> 6
  partition-2, replica-2 -> 1
  

後面可跟著簿記的移轉高階步驟 (當移轉程序在中間停止或失敗時重新啟動)。

1. 已指定舊到新經紀人 ID 對應並完成宣告。

2. 使用 AdminClient 檢查是否有可用的新中介。如果無法使用全部，請發出錯誤並終止。

3. 使用 AdminClient 檢查主題 <kafka_topic_migration> 是否存在於叢集中。

   • 如果主題 <kafka_topic_migration> 不存在，請在新代理程式上手動指派複本來建立複本。此主題用於保留已重新指派的主題表示已移轉。

4. 從一開始使用用戶閱讀主題 <kafka_topic_migration>。每個訊息都是已重新指派給新仲介的主題名稱。

5. 使用 AdminClient 列出叢集中所有可用的主題。從這個清單中移除主題 <kafka_topic_migration>。

6. 從上述兩個步驟中，尋找要重新指派給新仲介的主題。

7. 針對每個主題：

   1. 建立對應 Map<TopicPartition,Optional<NewPartitionReassignment>> reassignment = new HashMap<>();。

   2. 使用 AdminClient，描述尋找其分割區的主題。

   3. 對於每個分割區：

      1. 將每個舊的複本 ID (舊的中介 ID) 取代為對應的新中介 ID，以準備 NewPartitionReassignment 物件。如果中介 ID 對應未包含與複本 ID 對應的索引鍵，請記錄警告並使用目前的 ID (最有可能的原因是此主題已經移轉，而我們錯過了簿記)。

      2. 新增此項目至對應。

   4. 使用 AdminClient 呼叫 alterPartitionReassignments 方法來起始重新指派。

   5. 執行迴圈來檢查此重新指派是否已完成，方法是列出進行重新指派 (listPartitionReassignments) 並檢查其大小為零。在每個迴圈之間睡眠 N 秒 。

   6. 驗證每個分割區的新複本是否與想要的複本相符。

   7. 將此主題名稱作為訊息推送至 <kafka_topic_migration> 主題。

8. 重複步驟 4 到 6 (如果沒有其他主題可供重新指派及終止)。

移轉完成後，我們可以將舊的中介淘汰，並停用建立主題的自訂邏輯。

注意：停用舊代理程式之前，請確定此叢集的所有從屬端都已使用新代理程式更新 bootstrap.servers 組態。

移轉 Zookeeper 叢集

作為以仲裁為基礎的系統 (為了確認任何作業，我們至少需要投票數)，且指定的領導者重選導致停止寫入作業，Zookeeper 移轉是最困難的部分。取代節點的方法有幾種。其中一個簡單的方法是執行整個叢集的多個輪流重新啟動，並在每一回合中新增節點。可能無法接受此方法，因為多回合的排行榜節點重新啟動，以及執行整體移轉的延遲。

注意：由於新節點在未同步所有資料 (導致資料遺失) 的風險下，無法一次新增所有新節點 (作為參與者)。

請勿在與參與者相同的初始組態中，指定多個聯結伺服器。目前，結合伺服器不知道它們正在加入現有的組譯器，如果多個結合器列為參與者，則它們可能會形成獨立的法定量子，建立分割單元 (例如獨立於主要組譯的處理作業)。您可以在初始組態中將多個結合器列為觀察者。

在 3.5.0 以上的 Zookeeper 版本中，我們支援 Zookeeper 的動態重新組態設定。reconfigEnabled 旗標應設為 true，動態重新配置才能運作。如需詳細資訊，請參閱ZooKeeper Ensemble 的動態重新配置。

您可以新增節點，以角色 Observer 組合成上一個確認組態中伺服器之結合器的初始組態。例如，如果同時新增伺服器 4 和伺服器 5 至 (1、2、3)，則初始組態 4 將會是 (1、2、3、4、5)，其中 4 和 5 會列為觀察者。同樣地，5 的組態也會是 (1、2、3、4、5)，其中 4 和 5 會列為觀察者。

備註：以觀察者身分列出加入者不會真正讓他們觀察者 - 它只會防止他們不小心與其他加入者建立法定。他們會改為聯絡目前組態中的伺服器，並採用沒有結合者的最後確認組態 (1、2、3)。連線至目前的領導者之後，加入者會成為無投票權的追隨者，直到系統重新設定並加入至組譯 (視需要加入參與者或觀察者)。

所有節點都已啟動並在執行中之後，系統會呼叫重新設定 API ，以動態方式將新節點新增為參與者，並從組譯中移除舊節點。例如，使用 CLI。

reconfig -remove 1,2,3 -add
server.5=hostA:2111:2112;2113,6=hostB:2111:2112:participant;2113,7=
hostC:2111:2112:participant;2113*

在此步驟之後，舊節點便可停用。

注意：

• 停用舊節點之前，請先確定此 Zookeeper 叢集的所有從屬端都已更新新節點的連線字串。

• Zookeeper 應先移轉 (假設使用的 Kafka 版本取決於 Zookeeper)。藉由在新的 Kafka 中介組態中新增 Zookeeper 節點，我們將事先準備好移除舊的 Zookeeper 節點。

• Zookeeper 新節點的 myID 應為單調遞增，否則無法啟動節點。

• 請勿重新啟動新增的 Zookeeper 節點，直到呼叫 reconfig 為止，否則將不會啟動，因為在動態組態檔中遺漏本身的組態。節點的初始組態會覆寫為具有上次確認組態的動態組態。

• 選取要整合至您生態系統的開放原始碼元件時，必須考量其管理性與作業層面。

• 移轉主題分割區時，必須注意透過網路傳輸的資料量。

相關連結

• 管理 API

• 重新設定 API

• ZooKeeper Ensemble 的動態重新配置

認可

• 作者 - Shailesh Mishra

其他學習資源

瀏覽 docs.oracle.com/learn 的其他實驗室，或前往 Oracle Learning YouTube 頻道存取更多免費學習內容。此外，請造訪 education.oracle.com/learning-explorer 以成為 Oracle Learning Explorer。

如需產品文件，請造訪 Oracle Help Center 。

---

標題與著作權資訊

Migrate Kafka and Zookeeper Cluster in Zero Downtime

F96325-01

April 2024

Copyright ©2024,

Oracle 和 (或) 其關係企業。