kafka的Leader选举机制

Kafka设计原理详解

Kafka核心总控制器Controller

kafka的所有Broker都会注册到kafka集群中去。kafka集群会选举一个Broker作为Leader作为kafka七群的总控制器Controller。他负责管理整个集群所有分区Partition和副本follower的状态。

1. 当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。
2. 当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。
3. 当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责让新分区被其他节点感知 到。

这里请不要与Topic层面的多个partition中选举一个Partition作为Leader混淆了。
Controller选举机制是使用zookeeper的选举机制来实现：
在zookeeper中的主节点下面创建一个 /controller 临时节点，zookeeper会保证有且仅有一个broker能创建成功，这个broker
就会成为集群的总控器controller，如下：

Controller里面记录了当前的Controller是哪个节，如下：

Controller会用zookeeper的watcher机制，监控brokers下面的所有的broker，一旦发现某个broker挂掉了，就会去找到该broker有多少partion是leader并发起对该partition的选举。
对partition的leader重新选举的机制为：
监听topic相关的变化。为Zookeeper中的/brokers/topics节点添加TopicChangeListener，用来处理topic增减
的变化；
如下图， 对于每个Topic都有一个ISR列表，直接取ISR列表的第一个作为leader，如果当前挂的就是第一个，则选择后面一个作为leader。

unclean.leader.election.enable=false, 默认情况下， 是从IRS列表里面的节点作为leader，但是如果这个参数配置成true，不在ISR列表但是在Replicas列表里面的也可以作为选举leader的。但是可以想像得出来，这个不在ISR列表得副本数据不是很全得所以需要谨慎使用。
消费者消费消息得offset记录机制
每个consumer会定期将自己消费分区得offset提交给kafka内部topic__consumer_offsets里面，提交过得时候是用consumerGroupId + Topic + 分区号 ,value 就是offset得值。kafka会定期清理topic里得消息，最后就保留最新得那条数据。
kafka的log中为了提高并发量，默认会有50个分区，对于你提交得那条数据会放到那个分区使用下面得公式计算：
hash(consumerGroupId) % _Consumer_offsets 主题的分区数