一、KafKa分区副本ISR选举机制
kafka 中每一个主题又进一步划分成若干个分区。副本的概念实际上是在分区层级下定义的，每个分区配置有多若干个副本。
所谓的副本，本质上就是一个只能追加写消息的提交日志，根据kafka副本机制的定义，同一个分区下的所有副本保存着相同的消息序列，这些副本分散的保存在不同的Broker上，从而能够对抗部分Broker宕机带来的数据不可用。
如下图，在3节点的 kafka 集群中，对 topic：主题1 分了三个分区三个副本。
在 kafka 分区中的副本机制中，又分了 Leader 节点 和 Follower 节点，消息会写到Leader 节点中，由Leader 节点将数据同步给 Follower 节点，每个副本都可以进行读操作，从而减轻读的压力。
既然存在 Leader 和 Follower 节点，肯定需要一个 Leader 选举机制，谁也不能确保 Leader 节点可以一直正常存活，有可能因为某些原因导致 Leader 节点宕机或 网络异常，这种情况下就需要在剩下的节点中选举出一个Follower 节点升级为 Leader 节点，继续提供服务。
注意：分区的副本选举问题，不是Broker的选举，而是分区中副本选举的问题，在一个Broker 中，不同的 topic 的分区下，有可能存在有的是 Leader而有的又是 Follower ，因此Broker的选举和分区的选举需要区分开来，会在本专栏后面的文章中继续讲解 Broker的 Leader节点的作用和选举机制。
ISR选举机制：
在 kafka 中分区副本选举机制采用的ISR的机制，全称为 In-Sync Replicas，挑选出Leader节点，而 ISR 其实就是一个存放分区副本ID的集合，如果某个副本所在的 Broker 正常的和 zookeepeer能够建立连接的情况下，那这个副本的ID就会存放到该集合中，如果某个副本节点宕机之后，该副本数据就会从该ISR集合中剔除。
当Leader 收到消息数据同步给Follower 节点时，如果 Follower 节点一直阻塞，长时间不给Leader 节点发送 ack ，这种情况也会从ISR集合中剔除。
如果 Leader 节点宕机之后，其他副本就会将ISR中的 Leader 节点移除，而ISR列表中最前面的副本就被选举为一个新的Leader 节点。
假如三分区，三副本的情况信息，Leader 节点发生宕机，就如下图的过程：
从上面这种方式可以看出，当 Leader 副本宕机之后，会从ISR同步副本列表中剔除，然后取剩下的ISR列表中第一个为Leader 副本，显然有可能还有些副本数据没有及时同步完成，当选择为Leader副本之后有可能数据会丢失。
相关配置讲解：
## 默认10s，isr中的follow没有向isr发送心跳包就会被移除
replica.lag.time.max.ms = 10000## 根据leader 和副本的信息条数差值决定是否从isr 中剔除此副本，此信息条数差值根据配置参数，在broker数量较少,或者网络不足的环境中,建议提高此值.
replica.lag.max.messages = 4000## follower与leader之间的socket超时时间
replica.socket.timeout.ms=30*1000## 数据同步时的socket缓存大小
replica.socket.receive.buffer.bytes=64*1024## replicas每次获取数据的最大大小
replica.fetch.max.bytes =1024*1024## replicas同leader之间通信的最大等待时间，失败了会重试
replica.fetch.wait.max.ms =500## fetch的最小数据尺寸，如果leader中尚未同步的数据不足此值,将会阻塞,直到满足条件
replica.fetch.min.bytes =1## leader进行复制的线程数，增大这个数值会增加follower的IO
num.replica.fetchers=1## 每个replica检查是否将最高水位进行固化的频率
replica.high.watermark.checkpoint.interval.ms = 5000## leader的不平衡比例，若是超过这个数值，会对分区进行重新的平衡
leader.imbalance.per.broker.percentage = 10## 检查leader是否不平衡的时间间隔
leader.imbalance.check.interval.seconds = 300
