Kafka涉及到的多种选举机制

提起Kafka中的选举，第一印象肯定是broker节点之间的选举，它依赖于Zookeeper来进行选举，其实还有partition之间也有选举，以及其他地方都存在选举，但这些都是由Kafka内部完成，它们都需要一个leader来把控全场，由leader来负责读写请求，处理消息的同步，监听分区变化，监听主题变化，保存一些分区方案，记录消费位移等信息。我总结的有以下几种选举。

1. broker Leader
2. partition Leader
3. GroupCoordinator Leader
4. Group Leader

控制器的选举

在Kafka集群中会有一个或多个broker，只有其中一个broker会选举为控制器，即Kafka Controller，它负责管理整个集群中所有分区和副本的状态，当分区中leader 副本出现问题及时选举新的leader副本，更新ISR集合的元数据信息。broker的选举过程是在zookeeper中创建/controller临时节点，临时节点的内容如下图

每个broker还是会对/controller节点添加监听器,以此来监昕此节点的数据变化，当/controller节点发生变更，就会触发新一轮的选举。

分区Leader的选举

分区leader副本的选举由控制器负责具体实施。当创建分区（创建主题或增加分区都有创建分区的动作），或分区上线（比如分区中原先的leader 副本下线，此时分区需要选举一个新的leader上线来对外提供服务）的时候，都需要执行leader的选举动作。基本策略是按照AR集合中副本的顺序查找第一个存活的副本，并且这个副本在ISR集合中 。一个分区的AR集合在分配的时候就被指定,并且只要不发生重分配的情况，集合内部副本的顺序是保持不变的，而分区的ISR集合中副本的顺序可能会改变。

partitions后的字符串中，方括号的就是Leader副本。

GroupCoordinator的选举

GroupCoordinator是负责执行消费者的分区分配和再均衡操作，在初始阶段，当消费者未保存与消费组对应的GroupCoordinator节点信息时，需要通过向集群中负载最小的节点发送请求来寻找，Kafka通过消费组的groupId的哈希值计算__consumer_offsets中的分区编号，找到分区后，再寻找分区leader副本所在的broker节点，该节点就是对应的GroupCoordinator，消费者最终的分区分配方案以及组内消费者所提交的消费位移信息都会发送给次分区leader副本所在的broker节点。

消费组Leader的选举

GroupCoordinator需要为消费组内的消费者选举出一个消费组的leader，这个选举的算法很简单，当消费组内还没有leader，那么第一个加入消费组的消费者即为消费组的leader，如果当前leader退出消费组，则会挑选以HashMap结构保存的消费者节点数据中，第一个键值对来作为leader。