（六）kafka负载均衡机制
A. 服务端broker负载均衡机制
- 概述：生产者、消费者真实对应的实体是partition的leader副本，因此broker的负载均衡取决于leader副本分布是否均匀。
1. leader副本的均衡分布实现
-
初始分布
- 若共有5台brokers，创建一个分区数partition为5且副本数replicas数为3的topicA。
- 具体的partition下0 - 4的leader副本分布顺序对应broker0 - 4，并将follower副本依次放在后两位broker。比如：partition0的follower副本放在broker1 & 2上。
-
分布结果AR：AR = ISR +OSR
分区名 副本所在的broker列表 备注 topicA-partition0 0，1，2 leader副本在broker0 topicA-partition1 1，2，3 leader副本在broker1 topicA-partition2 2，3，4 leader副本在broker2 topicA-partition3 3，4，0 leader副本在broker3 topicA-partition4 4，0，1 leader副本在broker4 优先副本：broker列表中，第一个即为优先副本，优先选择其为leader副本。
2. 分区自动重平衡
- 场景概述：随着时间推移、集群状态变化，leader副本或多或少会有迁移或切换，导致部分broker上的leader副本偏多。
-
auto.leader.rebalance.enable：该参数默认开启，使集群中的controller启动定时任务，默认每隔5min轮询所有brokers，计算每一个节点的分区不平衡率，默认阈值为10%，高于该值会触发分区迁移。 - 分区不平衡率
- 计算公式：分区不平衡率 = 当前broker的非优先副本leader个数 / 当前broker分区总数。
- 案例场景：broker0上原本仅有topicA-partition0，3 & 4三个副本，其中0是优先副本也是leader副本。后来broker4宕机了，所以topicA-partition4此时将leader副本从broker4转移到broker0上，此时broker0依然拥有3个副本，但是topicA-partition4变成leader副本（非优先副本），此时分区不平衡率为1/3，若broker4后续恢复后，触发分区自动迁移机制。
- 自动迁移可能会影响性能，可手动脚本kafka-preferred-replica-election.sh执行该操作。
3. broker负载不均衡常见场景
- 集群状态变化导致leader切换，但默认开启分区自动重平衡，无须过分担心。
- kafka当前负载最大痛点即新增broker后，若没有新建topic或者是将老的topic迁移分区，则该broker不会有任何流量。需手动完成分区重新分配 & 数据迁移。
- kafka设置了
broker.rack，分区算法从本来顺延方法调整为尽量避免副本在同一个机架上，可能导致分配不均。
B. 生产者producer负载均衡机制
- 概述：生产端的负载均衡就是保障生产消息发往哪个partition（leader副本）。
- 手段
- 无key：基于轮训算法，计算发往的具体partition。
- 有key：hash计算目标partition，不论partition是否活跃。
- Producer负载不均衡常见场景
- 生产者指定了key，创建topic时分区器选择指定key的模式，会将消息定向发给具体的broker上导致leader不平均。
- 业务使用上，个别topic的流量远大于其他topic。
C. 消费者consumer负载均衡机制
- 概述：若topic共有100w数据，消费组共有4个消费者，消费者端的负载均衡就是想办法保障让每个消费者拉取25w条数据。
- 手段：消费端的实体是partition（leader副本），需要把partition均匀分配给消费组内的consumer。
-
partition.assignment.strategy：重平衡时在所有consumer都发送完join_group后broker响应后，消费组中leader发出sync_group时采用的分区分配策略参数。 - 策略类型
- 默认类型为rangeAssignor
- 轮询分配roundRobinAssignor
- 当前最优解stickyAssignor
-
- Consumer负载不均衡常见场景
- 分区分配策略不佳，导致负载不均。
- 业务使用问题，个别topic流量远大于其他topic。
