本文已参与「新人创作礼」活动， 一起开启掘金创作之路。
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文件下一条要写入的消息的位移，例如 LEO=10则当前文件已经写了了10条消息，位移是[0,10)。
HW： 所有分区已提交的的位移，一般HW<=LEO。
