【车联网kafka】Kafka核心架构与实战经验（第四篇）
一、社团扛把子不为人知的秘密
香港社团里，Kafka 是整个组织的名号，ZooKeeper 就是说一不二的长老团，各个片区的 “话事人” 就是 broker，而能统领所有片区的 “扛把子”，就是 Kafka 里的控制器。
1.1 选举的秘密
每天社团开工，各个片区的话事人都要先去长老团报备。这时候，大家都会偷偷瞄一眼长老团手里的 “花名册”—— 也就是 ZooKeeper 里的 /controller 节点。
要是花名册上已经写了某个片区话事人的名字（brokerid），其他人就只能乖乖退回，承认对方是扛把子；
可要是花名册是空的，或者上面的名字糊了，所有人就得立刻抢着去长老团登记，谁先把自己名字写上，谁就是新扛把子。不过这登记有讲究，花名册是 “临时的”，要是扛把子出了意外（节点宕机），名字会自动从花名册上消失，这时候就得重新选扛把子。
每个新扛把子上任，长老团还会给一个 “任期编号”—— 也就是 controller_epoch。
头一任扛把子是 1 号，要是扛把子换了人，编号就自动加 1。为啥要有这编号？比如前扛把子的小弟拿着命令来找现任扛把子，现任一看编号不对（比自己的小），就知道这是过期命令，直接不认。这规矩能避免前任的旧指令扰乱社团。
1.2 日常工作的职责之谜
当了扛把子，就得比普通话事人多扛不少活儿（这些事都得扛把子亲自拍板，还得让长老团盯着相关的节点，随时汇报动静）。
-
片区地盘调整（分区重分配）：
-
为ZooKeeper中的/admin/reassign_partitions 节点注册 PartitionReassignmentHandler
-
-
手下兄弟变动（ISR 集合变更）：
-
为 ZooKeeper 中的/isr_change_notification节点注册IsrChangeNotificetionHandler
-
-
换片区负责人（优先副本选举）：
-
为ZooKeeper中的/admin/preferred-replica-election节点添加PreferredReplicaElectionHandler
-
-
社团里新来重大任务（新增主题）：
-
为 ZooKeeper 中的/brokers/topics 节点添加TopicChangeHandler
-
-
社团某些重大任务不干了（删除主题）：
-
为 ZooKeeper 中的/admin/delete_topics节点点添加TopicDeletionHandler。
-
-
有新话事人加入（broker 上线）或者老话事人跑路（broker 下线），扛把子得盯着花名册（/brokers/ids），及时调整人手。
- 为ZooKeeper中的/brokers/ids节点添加BrokerChangeHandler，用来处理broker增减的变化。
-
每天开工，扛把子得先从长老团那里把所有地盘、兄弟的信息抄一遍，整理成总表，再下发给所有片区，保证大家信息一致。
-
为ZooKeeper中的/brokers/topics/＜topic＞节点添加PartitionModificationsHandler。
-
对了，社团里还有个规矩：要不要定期调整各个地盘的负责人（优先副本均衡），得看扛把子手里的 “自动调整开关”（auto.leader.rebalance.enable）。这开关要是打开，扛把子会每 5 分钟查一次，要是发现 10% 以上的地盘负责人不合适，就会自动换人。但老江湖都知道，这自动调整容易出乱子，万一正忙着做事呢，突然换负责人会耽误事，所以社团里一般都把这开关关了，换成手动调整 —— 就像用脚本 kafka-perferred-replica-election.sh 指定换人，稳妥得多。
说到底，扛把子的存在就是为了让整个社团不乱套：谁的地盘谁负责，兄弟变动有记录，地盘调整有章法，就算扛把子换了人，有任期编号顶着，新老大照样能顺利接盘。这一套规矩下来，社团才能在香港的复杂环境里稳稳当当运行。