controller的选举
首先第一个选举就是借助于zookeeper的controller的选举
第一个就是controller的选举 ，这个选举是借助于zookeeper的独享锁实现的 ，先启动的broker会在zookeeper的/contoller节点上面增加一个broker信息，谁创建成功了谁就是主节点，其他的broker会启动watch监视器进行监听其中的数据变化，如果宕机了其他的节点会抢占这个节点选举为controller节点。
partition leader选举
每个topic都存在多个分区，每个分区又存在多个副本，其中有一个副本是主节点其他都是从节点，负责和主分区同步数据，并且生产者和消费者都是通过主节点进行操作kafka数据的
那么他们的选举是通过什么进行选择的呢？
controller节点会按照分区的注册顺序，优先选择前面的节点进行选择
如果主节点宕机后是如何选择的呢？
首先我们使用命令来查看其中一个topic的详细信息
java
kafka-topics.sh --bootstrap-server hadoop106:9092 --topic topic_a --describe
其中我们会看到最后一列内容是ISR ，这个叫做动态副本集 ，它的作用使用强大，在kafka中存储数据的时候首先存储数据到主分区 中，然后主分区中的数据会同步到不同的副本分区中，做数据的同步备份，尤其是在producer端设定ack=-1的时候，要在所有副本都同步完毕消息以后才会返回ack，producer才会发送下一条数据过来，但是如果因为其中一个副本的网络卡顿或者是自己宕机那么会出现一直同步不成功的情况，从而producer不能继续发送数据，所以kafka动态维护了一个副本集，这个副本集中都是可以正常同步数据的，也就是说他们都是正常的，如果不正常的不能保持和主节点同步的副本就会从这个里面删除掉
为什么说这个ISR呢？
因为一旦主分区宕机了，那么broker【controller】节点就会检测到，那么就会在ISR中按照顺序选择一个好的节点成为主分区。这就是主分区宕机后的选举实现，但是选择的节点一般都是数据比较新的，不会选择落后太多的副本
但是有时候ISR中的副本如果都为空就没有办法选择新的leader分区了，这个时候为了集群的稳定性，可以设定
java
# 将这个开关打开，默认是false关闭的，它允许实现ISR以外的节点成为主节点
unclean.leader.election.enable这个会出现数据丢失问题，但是可以在一定程度上保证程序的稳定性