KafkaController 分区Rebalance平衡机制

private def checkAndTriggerPartitionRebalance(): Unit = {
  if (isActive()) {
    trace("checking need to trigger partition rebalance")
    // 获取(存活的broker,AR副本集) => (2,Map([message,0]-> List(2, 0), [hadoop,0] -> List(2, 1)))
   
var preferredReplicasForTopicsByBrokers: Map[Int, Map[TopicAndPartition, Seq[Int]]] = null
   
inLock(controllerContext.controllerLock) {
      preferredReplicasForTopicsByBrokers=
        controllerContext.partitionReplicaAssignment.filterNot(p => deleteTopicManager.isTopicQueuedUpForDeletion(p._1.topic)).groupBy {
          case(topicAndPartition, assignedReplicas) => assignedReplicas.head
       
}
    }
    debug("preferred replicas by broker " + preferredReplicasForTopicsByBrokers)
    // 过滤每一个存活的broker,检查是否需要一个preferredreplica 选举被触发
   
preferredReplicasForTopicsByBrokers.foreach {
      case(leaderBroker, topicAndPartitionsForBroker) => {
        var imbalanceRatio: Double = 0
       
var topicsNotInPreferredReplica: Map[TopicAndPartition, Seq[Int]] = null
       
inLock(controllerContext.controllerLock) {
          // 我们知道,正常情况下,brokerAR副本集第一个副本(preferred replica )就是leader
          //
如果leader不是preferred replica,比如 Leader : 0 ISR[2,0]
          //
我们需要过滤出这种topicPartition,然后我们好进行在平衡
         
topicsNotInPreferredReplica=
            topicAndPartitionsForBroker.filter {
              case(topicPartition, replicas) => {
                controllerContext.partitionLeadershipInfo.contains(topicPartition) &&
                controllerContext.partitionLeadershipInfo(topicPartition).leaderAndIsr.leader != leaderBroker
             
}
            }
          debug("topics not in preferred replica " + topicsNotInPreferredReplica)
          // broker AR副本数量
         
val totalTopicPartitionsForBroker = topicAndPartitionsForBroker.size
         
// 过滤出的leader不是AR副本集的preferred replica的数量
         
val totalTopicPartitionsNotLedByBroker = topicsNotInPreferredReplica.size
         
// 计算(过滤出的leader不是AR副本集的preferred replica的数量)/(broker AR副本数量)不平衡比例
         
imbalanceRatio= totalTopicPartitionsNotLedByBroker.toDouble / totalTopicPartitionsForBroker
         
trace("leader imbalance ratio for broker %d is %f".format(leaderBroker, imbalanceRatio))
        }
        // 如果比例大于我们配置的leader.imbalance.per.broker.percentage参数,比如50%,就触发这个topic partitions的再平衡操作
       
if (imbalanceRatio > (config.leaderImbalancePerBrokerPercentage.toDouble / 100)) {
          topicsNotInPreferredReplica.foreach {
            case(topicPartition, replicas) => {
              inLock(controllerContext.controllerLock) {
                // 首先确保broker存活,而且没有分区正在重新分配或者没有进行preferredreplica 选举,且没有分区将被删除
               
if (controllerContext.liveBrokerIds.contains(leaderBroker) &&
                    controllerContext.partitionsBeingReassigned.isEmpty &&
                    controllerContext.partitionsUndergoingPreferredReplicaElection.isEmpty &&
                    !deleteTopicManager.isTopicQueuedUpForDeletion(topicPartition.topic) &&
                    controllerContext.allTopics.contains(topicPartition.topic)) {
                  // 然后真正触发Prederred Replica选举操作
                 
onPreferredReplicaElection(Set(topicPartition), true)
                }
              }
            }
          }
        }
      }
    }
  }
}


### 回答1: Kafka使用Rebalance机制来确保消费者群组中的消费者消费相同数量的分区,并确保消费者在分区分配发生更改时能够正确地处理它们。 当消费者加入或离开群组时,Kafka会触发Rebalance过程。在Rebalance过程中,Kafka会重新分配分区以确保每个消费者都消费相同数量的分区。Rebalance的过程可以分为两个阶段: 1. Revoke阶段:在此阶段,Kafka会将消费者正在消费的所有分区的控制权从消费者手中收回。这样可以确保在Rebalance期间不会有任何数据丢失。 2. Assign阶段:在此阶段,Kafka会重新分配分区以确保每个消费者都消费相同数量的分区Kafka会确保在分配分区时考虑消费者的偏移量,以确保不会重复消费数据。 总的来说,Kafka的Rebalance机制是一种非常强大和可靠的机制,可以确保消费者群组中的消费者消费相同数量的分区,并确保在分区分配发生更改时能够正确地处理它们。 ### 回答2: Kafka的rebalance机制是指在消费者组中添加或移除一个消费者时,Kafka如何重新分配分区给消费者。 当有新的消费者加入消费者组时,Kafka会根据分区的数量和消费者组的消费者数量来重新分配分区Kafka首先计算出每个消费者应该处理的分区数量,然后将剩余的分区平均分配给所有的消费者。这样可以使得每个消费者处理大致相等的负载。 当有消费者离开消费者组时,Kafka会将该消费者所处理的分区重新分配给其他消费者。重新分配分区的策略有两种:Range策略和Round-robin策略。Range策略会将离开的消费者处理的分区范围平均分配给其他消费者。Round-robin策略会将离开的消费者处理的分区轮流分配给其他消费者。 在进行rebalance时,Kafka会暂停消费者读取消息,待分配完成后再继续消费。这样可以确保在分配过程中不会丢失消息。而在消费者组中,每个消费者都会维护一个偏移量,用于记录自己已消费的消息的位置。因此,消费者在重新分配分区后,可以继续从之前的偏移量处开始消费消息,避免重复消费。 总之,Kafka的rebalance机制可以保证消费者组中的消费者具有相对均衡的负载,并能够在分区重新分配时保证消息的连续性与一致性。这个机制Kafka集群中起到了重要的作用,保证了高可用性和负载均衡的特性。 ### 回答3: Kafka的Rebalance机制是指在消费者组中加入或退出一个消费者时,Kafka自动重新分配消费者与消费者之间的Topic分区。这个机制的目的是保证消费者组内的负载均衡,确保每个消费者处理大致相同数量的消息。 当一个消费者加入或退出消费者组时,Rebalance机制会触发一个重新分配分区的过程。这个过程包括以下几个步骤: 1. 消费者加入或退出:当有一个消费者加入消费者组时,或者有一个消费者退出消费者组时,Kafka会进行重新分区。加入消费者组的消费者将被分配新的分区,而退出消费者组的消费者的分区将被重新分配给其它消费者。 2. 再均衡协调者:Kafka集群中会有一个特殊的角色,称为再均衡协调者。这个角色负责协调消费者组的再均衡过程。它会与消费者组中的每个消费者进行通信,以决定每个消费者应该被分配哪些分区。 3. 再均衡算法:再均衡协调者使用一种算法来决定分配给每个消费者的分区。这个算法要考虑分区的负载均衡,保证每个消费者处理大致相同数量的消息。具体的算法可以是Round Robin轮询、Range Range、Sticky等。 4. 分区指派:再均衡协调者完成分区的指派后,将结果通知给每个消费者。消费者根据指派结果来分配并处理属于它们的分区。 总之,Kafka的Rebalance机制在消费者组中加入或退出一个消费者时,自动进行分区的重新分配,以保证负载均衡和消费者的高可用性。这个机制可以确保每个消费者处理大致相同数量的消息,提高整个消费者组的吞吐量和效率。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

莫言静好、

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值