Kafka（13）Kafka集群中Controller、Rebalance和HW、LEO说明

一：Controller

Controller推选：

• Kafka集群中的broker在zk中创建临时序号节点，序号最小的节点（最先创建的节点)将作为集群的controller（ 也就是说：在集群中的所有的broker启动的时候，都会去向zookeeper创建一个临时序号结点，谁最小谁就是controller）

Controller的作用：负责管理整个集群中的所有分区和副本的状态:

1. 当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。(当集群中有一个副本的leader挂掉，需要在集群中选举出一个新的leader，选举的规则是从isr集合中最左边获得。)

2. 当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。（即通知其他broker，broker的变化（增删等））当集群中有broker新增或减少，controller会同步信息给其他broker

   Isr集合里面存放的是Leader可以和Leader进行同步和已同步的结点

3. 当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责让新分区被其他节点感知到。当集群中有分区新增或减少，controller会同步信息给其他broker

二：Rebalance机制

触发触发Rebalance机制的两种情况：

1. 如果消费者两次poll的时间间隔超出30s会被认为这个消费者的能力不太好，或者是消费者维持心跳已经10秒没有续约了，这两种情况下那么这个消费者就被被踢掉。
   当消费者被踢掉之后，这个消费者之前消费的分区在当前的消费者组里面没有人消费了，这时候就需要将没有人消费的分区交给消费者组里面的另一个消费者消费，这时候就会触发Rebalance机制

2. 如果有新增一个消费者，也会触发触发Rebalance机制

总结：
Rebalance机制触发的前提是：消费者没有指明分区消费（就是说每一个消费者指明消费哪一个Partition）。当消费组里消费者和分区的关系发生变化，那么就会触发rebalance机制。

Rebalance机制的作用：这个机制会重新调整消费者消费哪个分区。

在触发rebalance机制之前，消费者消费哪个分区有三种策略:

1. range：通过公示来计算某个消费者消费哪个分区（分区总数 / 消费者数目+1）

2. 轮询：大家轮着消费
   

3. sticky：在触发了rebalance后，在消费者消费的原分区不变的基础上进行调整。（基于1和2的策略，如果没有用这种策略的话，如果一个消费者挂了之后，之前所有的分配都会重新分配，性能影响比较大）
   

总结：

1. 前提：消费组中的消费者没有指明分区来消费
2. 触发的条件：当消费组中的消费者和分区的关系发生变化的时候
3. 分区分配的策略:在rebalance之前，分区怎么分配会有这么三种策略
   • range:根据公示计算得到每个消费消费哪几个分区︰前面的消费者是分区总数/消费者数量+1，之后的消费者是分区总数/消费者数量
   • 轮询:大家轮着来
   • sticky:粘合策略，如果需要rebalance，会在之前已分配的基础上调整，不会改变之前的分配情况。如果这个策略没有开，那么就要进行全部的重新分配。建议开启。

三：HW和LEO说明

HW 俗称高水位，HighWatermark的缩写，取一个partition对应的ISR中最小的LEO(log-end-offset)作为HW，consumer最多只能消费到HW所在的位置。

另外每个replica都有HW，leader和follower各自负责更新自己的HW的状态。

对于leader新写入的消息，consumer不能立刻消费，leader会等待该消息被所有ISR中的replicas同步后更新HW，此时消息才能被consumer消费。这样就保证了如果leader所在的broker失效，该消息仍然可以从新选举的leader中获取。

总结：

1. LEO是某个副本最后消息的消息位置（log-end-offset）

2. HW是已完成同步的位置。消息在写⼊broker时，且每个broker完成这条消息的同步后，hw 才会变化。在这之前消费者是消费不到这条消息的。

3. 在同步完成之后，HW更新之后，消费者才能消费到这条消息，这样的⽬的是防⽌消息的丢失。