消息队列-Kafka-选举机制

Kafka的”选举”包括: Kafka Controller的选举, Partition Leader的选举, Consumer Group Coordinator(消费组协调者)的选举;

➤ Controller的选举

Controller的作用: 运行 Partition的节点叫 Broker, 其中一个Broker将会被选为Controller, 它负责整个集群中所有分区和副本的管理工作, 其主要职责有: Partition leader的选举, ISR的维护等;
选举触发: Controller(Leader角色)在zk上创建临时节点, 当Leader宕机, 这个临时节点因为心跳检测失败而被删除, 同时zk将消息发送给所有Broker;
选举过程: 收到消息的Broker在zk上创建/controller临时节点, 利用zk的强一致性, 只有一个 Broker能创建成功, 这个节点成为新的Controller;

Partition leader的作用: 每个 Partition都有数个副本(replica), 但消息的读写都是在 Leader Partition上完成的, 然后批量同步到副本;
选举触发: 当有Broker宕机, 这个Broker在zk上的临时节点(znode)也会被删除, zk会通知正在watch的 Controller进行处理;
选举过程: Controller接到通知后, 先选出 set_p(该集合包括了宕机的Broker上包含的所有 Partition), 然后Controller从zk读取 set_p中每一个分区的 ISR, 然后从ISR中选出一个副本作为该Partition的新 Leader, 然后将{新Leader/leader_epoch/controller_epoch} 写入 /brokers/topics/[topic]/partitions/[partition]/state // epoch是需要记录进选举结果的, 任期(term)的概念;
为什么不采用少数服从多数(majority)的选举? (少数服从多数, 类似 Redis Sentinel Leader的选举, 不少于quorum且选票高于一半). Kafka的分区选举, 使用的是 “从ISR中选举”, 而 ISR的可以最多容忍总数“f+1个节点有f个失败”,也即至少有1个在ISR即可. 可以看出, majority的方式(总数2f+1个, 最大容忍f个失败)需要更高的冗余度, 例如能容忍2台机器宕机, 那么majority方式至少需要5台机器. 另外, majority的方式也要求更多的replica “能跟上Partition Leader的写入进度”, 吞吐量也会下降(详见消息的commit机制).