场景描述

分区平衡是指将分区的副本重新分配到不同的节点上，解决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. 点击左侧菜单栏中的主题管理，进入主题列表页面。

3. 选择需要平衡的主题，点击其右侧操作栏的更多选项。

   

4. 设置自动平衡参数。

   ● 勾选目标的Broker，Topic分区的副本即将迁移至目标Broker上。
   ● 输入带宽大小，默认值为“-1”，表示不限制带宽。如果实例负载较低，建议不设置带宽限制。如果需要设置带宽限制，建议该参数值不小于待分区平衡Topic的总生产带宽 * 待分区平衡Topic的最大副本数。

   

5. 单击“确认”，自动跳转到Topic列表页面。

6. 在Topic列表页面左上方单击“分区平衡任务”，查看分区平衡任务的状态。

   

手动平衡

1. 进入Kafka实例管理控制台。

2. 点击左侧菜单栏中的主题管理，进入主题列表页面。

3. 选择需要平衡的主题，点击其右侧操作栏的更多选项。

4. 选择手动平衡，设置手动平衡参数。
   ● 在“手动平衡”对话框右上角，单击“减少副本”/“添加副本”，为Topic的每个分区减少/增加副本数。
   ● 在待修改分区平衡的副本名称下，单击Broker名称或，选择目标Broker的名称，副本即将迁移至目标Broker上。同一分区下的不同副本需要分配在不同的Broker上。
   ● 在“带宽限制”中，输入带宽大小，默认值为“-1”，表示不限制带宽。如果实例负载较低，建议不设置带宽限制。如果需要设置带宽限制，建议该参数值不小于待分区平衡Topic的总生产带宽 * 待分区平衡Topic的最大副本数。

   

5. 单击“确认”，自动跳转到Topic列表页面。

6. 在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。