Kafka——Controller、Rebalance、HW

1. Controller

• Kafka集群中的broker在zk中创建临时序号节点，序号最小的节点（最先创建的节点）将作为集群的controller，负责管理整个集群中的所有分区和副本的状态：
  • 当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。
  • 当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。
  • 当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责让新分区被其他节点感知到。

2. Rebalance

前提：消费者没有指明分区消费。当消费组里消费者和分区的关系发生变化，那么就会触发rebalance机制。

​ 这个机制会重新调整消费者消费哪个分区。

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

• range：通过公示来计算某个消费者消费哪个分区
• 轮询：大家轮着消费
• sticky：在触发了rebalance后，在消费者消费的原分区不变的基础上进行调整。

3. 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中获取。

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