通过之前的篇章，我们了解到kafka集群中存在一个leader，这个leader目前来说，通常是谁先注册到zk中，即在broker的ids节点中的第一位，就是leader
但是在某些情况下，比如网络故障、服务器异常宕机时，leader所在的kafka实例可能就挂掉了，一旦出现这种情况，kafka集群将会重新选举出一个leader，下面通过演示来说明写leader选举的完整过程
kafka leader选举过程Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader，负责管理集群broker 的上下线，所有 topic 的分区副本分配和 Leader 选举等工作。
Controller 的信息同步工作是依赖于 Zookeeper 的，有了之前从ZK中了解各个节点的作用后，下面用一张图说明下ZK的leader选举过程环境准备
1、基于centos7系统搭建的kafka集群（虚拟机环境，或者云服务器）
操作步骤1、启动4个kafka实例
./bin/kafka-server-start.sh -daemon ./config/server.properties ./bin/kafka-server-start.sh -daemon ./config/server1.properties ./bin/kafka-server-start.sh -daemon ./config/server2.properties ./bin/kafka-server-start.sh -daemon ./config/server3.properties
2、创建一个4个分区4个副本的topic
./kafka-topics.sh --zookeeper IP:2181 --create --topic zcy222 --partitions 4 --replication-factor 4
检查下主题创建情况
然后通过下面的命令展示下主题的完整情况
./kafka-topics.sh --zookeeper IP:2181 --describe --topic zcy22
通过输出的信息，可以看到各个broker上面的副本信息，ISR信息
通过上一篇，我们了解到ISR中保存的是各个brokerid的信息，现在按照我们最初的设想，如果停掉第四台节点的kafka服务，理论上讲 ISR列表中为4的信息将会被移除，4后面的其他数据将会往前顺移，接下来我们做下实验验证下猜想
3、停掉第四个节点的kafka服务
然后再次使用上面的主题描述信息命令查看下当前主题的分区以及ISR情况，我们将上面的那张图拿过来对比下，看看是否可以发现什么
很明显，当集群中第四个kafka的实例断掉后，ISR中会将这个服务对应的brokerid剔除掉，从而确保ISR里面存储的一定是当前kafka集群中各个存活的，即可以提供服务的实例
假如这时候，通过人力的干预，再次将第四个kafka服务启动起来，会出现什么情况呢？
4、重启第四个kafka服务
./bin/kafka-server-start.sh -daemon ./config/server3.properties
这时候，再使用主题描述命令查看下分区leader情况,可以看到ISR中第四个brokerid又加入进来了，我们不妨对比第三步中的信息，看看有何变化
很明显，当第四个服务重新启动后，会自动加入到ISR列表中最后一个，即顺序放到最后一个
