場景描述

分區平衡是指將分區的副本重新分配到不同的節點上，解決Kafka節點負載不均衡問題。
需要進行分區平衡的場景如下：

• 實例擴容節點個數后，新節點沒有任何負載，需要將原有Topic分區的副本遷移到新節點上。
• 將高負載節點上的Leader分區切換為Follower分區。
• 增加/減少副本數量。

分布式消息服務Kafka版控制臺提供兩種分區平衡的方法：自動平衡和手動平衡，建議選擇自動平衡，確保分區Leader的均勻分布。

操作影響

• 對數據量大的Topic進行分區平衡，會占用大量的網絡和存儲帶寬，業務可能會出現請求超時或者時延增大，建議在業務低峰期時操作。對Topic進行分區平衡前，根據Kafka實例規格對比當前實例負載情況，評估是否可以進行分區平衡，建議預留足夠的帶寬進行分區平衡，CPU使用率在90%以上時，不建議進行分區平衡。
• 帶寬限制是指設定Topic進行副本同步的帶寬上限，確保不會對該實例上的其他Topic造成流量沖擊。但需要注意，帶寬限制不會區分是正常的生產消息造成的副本同步還是分區平衡造成的副本同步，如果帶寬限制設定過小，可能會影響正常的生產消息，且可能會造成分區平衡一直無法結束。
• 分區平衡任務啟動后，不能刪除正在進行分區平衡的Topic，否則會導致分區平衡任務無法結束。
• 分區平衡任務啟動后，無法修改Topic的分區數。
• 分區平衡任務啟動后，無法手動停止任務，需要等到任務完成。
• 分區平衡后Topic的metadata會改變，如果生產者不支持重試機制，會有少量的請求失敗，導致部分消息生產失敗。
• 數據量大的Topic進行分區平衡的時間會比較長，建議根據Topic的消費情況，適當調小Topic老化時間，使得Topic的部分歷史數據被及時清理，加快遷移速度。

分區平衡前的準備工作

• 在不影響業務的前提下，適當調小Topic老化時間并等待消息老化，減少遷移數據，加快遷移速度，分區平衡任務結束后可重新調整為初始值。
• 確保分區平衡的目標Broker磁盤容量充足。如果目標Broker磁盤剩余容量接近分區平衡遷移到該Broker上的數據量，為了給目標Broker上的消息生產預留存儲空間，應先進行磁盤擴容，再進行分區平衡。

自動平衡

1. 進入Kafka實例管理控制臺。

2. 點擊左側菜單欄中的Topic管理，進入主題列表頁面。

3. 選擇需要平衡的主題，點擊其右側操作欄的更多選項。

4. 設置自動平衡參數。

   

   ● 勾選目標的Broker，Topic分區的副本即將遷移至目標Broker上。
   ● 輸入帶寬大小，默認值為“-1”，表示不限制帶寬。如果實例負載較低，建議不設置帶寬限制。如果需要設置帶寬限制，建議該參數值不小于待分區平衡Topic的總生產帶寬 * 待分區平衡Topic的最大副本數。
    ● 執行時間，支持立即執行和自定義時間，選擇自定義時間時，自定義時間需要大于當前時間。通過定時任務去掃描任務，所以執行時間和自定義時間最多會有幾分鐘的偏差。

5. 單擊“確認”，自動跳轉到Topic列表頁面。

6. 在Topic列表頁面左上方單擊“分區平衡任務”，查看分區平衡任務的狀態。

手動平衡

1. 進入Kafka實例管理控制臺。

2. 點擊左側菜單欄中的Topic管理，進入主題列表頁面。

3. 選擇需要平衡的主題，點擊其右側操作欄的更多選項。

4. 選擇手動平衡，設置手動平衡參數。

   

   ● 在“手動平衡”對話框右上角，單擊“減少副本”/“添加副本”，為Topic的每個分區減少/增加副本數。
   ● 在待修改分區平衡的副本名稱下，單擊Broker名稱或，選擇目標Broker的名稱，副本即將遷移至目標Broker上。同一分區下的不同副本需要分配在不同的Broker上。
   ● 在“帶寬限制”中，輸入帶寬大小，默認值為“-1”，表示不限制帶寬。如果實例負載較低，建議不設置帶寬限制。如果需要設置帶寬限制，建議該參數值不小于待分區平衡Topic的總生產帶寬 * 待分區平衡Topic的最大副本數。
    ● 執行時間，支持立即執行和自定義時間，選擇自定義時間時，自定義時間需要大于當前時間。通過定時任務去掃描任務，所以執行時間和自定義時間最多會有幾分鐘的偏差。

5. 單擊“確認”，自動跳轉到Topic列表頁面。

6. 在Topic列表頁面左上方單擊“分區平衡任務”，查看分區平衡任務的狀態。

說明
同一個topic不支持同時創建多個分區平衡任務，重復創建時會覆蓋前一個任務

分區平衡帶寬限制值估算方法

帶寬限制值受分區平衡任務執行時間、分區副本Leader/Follower分布情況以及消息生產速率等因素影響，具體分析如下。

• 帶寬限制值作用范圍為整個Broker，對該Broker內所有副本同步的分區進行帶寬限流。
• 帶寬限制會將分區平衡后新增的副本視為Follower副本限流，分區平衡前的Leader副本視為Leader副本限流，Leader副本的限流和Follower副本限流分開計算。
• 帶寬限制不會區分是正常的生產消息造成的副本同步還是分區平衡造成的副本同步，因此兩者的流量都會被限流統計。
• 假設分區平衡任務需要在100s內完成，每個副本的數據量為100MB，在以下幾種場景中，估算帶寬限制值。

場景一

Topic1有2分區2副本，Topic2有1分區1副本，所有Leader副本在同一個Broker上，Topic1和Topic2分別需要新增1個副本。

表1 分區平衡前Topic分區的副本分布

表2 分區平衡后Topic分區的副本分布

由表可知，有3個副本需要從Broker 0拉取數據，Broker 0中每個副本的數據量為100MB，Broker 0中只有Leader副本，Broker 1和Broker 2中只有Follower副本，由此得出以下數據：

• Broker 0在100s內完成分區平衡所需的帶寬限制值=（100+100+100）/100=3MB/s
• Broker 1在100s內完成分區平衡所需的帶寬限制值=100/100=1MB/s
• Broker 2在100s內完成分區平衡所需的帶寬限制值=（100+100）/100=2MB/s

綜上所述，若想要在100s內完成分區平衡任務，帶寬限制值應設為大于等于3MB/s。

場景二

Topic1有2分區1副本，Topic2有2分區1副本，Leader副本分布在不同Broker上，Topic1和Topic2分別需要新增1個副本。

表3 分區平衡前Topic分區的副本分布

表4 分區平衡后Topic分區的副本分布

由表可知，Broker 1中只有Leader副本，Broker 0和Broker 2中存在Leader副本和Follower副本，由于Leader副本的限流和Follower副本限流分開計算，Broker 0和Broker 2需要分別計算Leader副本的限流和Follower副本限流。由此得出以下數據：

• Broker 0作為Leader副本在100s內完成分區平衡所需的帶寬限制值=100/100=1MB/s
• Broker 0作為Follower副本在100s內完成分區平衡所需的帶寬限制值=100/100=1MB/s
• Broker 1在100s內完成分區平衡所需的帶寬限制值=（100+100）/100=2MB/s
• Broker 2作為Leader副本在100s內完成分區平衡所需的帶寬限制值=100/100=1MB/s
• Broker 2作為Follower副本在100s內完成分區平衡所需的帶寬限制值=（100+100+100）/100=3MB/s

綜上所述，若想要在100s內完成分區平衡任務，帶寬限制值應設為大于等于3MB/s。

場景三

Topic1有1分區2副本，Topic2有1分區2副本，所有Leader副本在同一個Broker上，Topic1需要新增1個副本，Topic1上有生產消息造成的副本同步（700KB/s）。

表5 分區平衡前Topic分區的副本分布

表6 分區平衡后Topic分區的副本分布

由表可知，有1個副本由于分區平衡需要從Broker 0拉取數據，另1個副本由于生產消息需要從Broker 0拉取數據，帶寬限制不會區分是正常的生產消息造成的副本同步還是分區平衡造成的副本同步，因此兩者的流量都會被限流統計。由此得出以下數據：

• Broker 0在100s內完成分區平衡所需的帶寬限制值=（100MB+700KB/s*100s）/100s+700KB/s=2.4MB/s
• Broker 2在100s內完成分區平衡所需的帶寬限制值=100/100=1MB/s

綜上所述，若想要在100s內完成分區平衡任務，帶寬限制值應設為大于等于2.4MB/s。