kafka leader和flower故障处理过程

在kafka集群工作过程中，难免会碰到某个kafka服务实例宕机或挂掉的情况，服务一旦挂掉，意味着某个分区中的leader或follower将不能正常工作了

具体来说，leader和follower出现故障时各自的处理细节是不同的，假设kafka集群中有3个服务实例，对应到ISR中存储的就是3个brokerid的信息，假如brokerid为0的服务是leader，其他两个是follower，在broker实际工作过程中，发往broker的数据在leader和follower上均维持着一个HW和LEO，从实际经验来看，由于leader对外提供读写服务，而follower同步leader的数据，所以follower的HW（高水位线）同步到的最后那个水位所在位置数要低于leader的HW，基于这种情况前提下，会造成当leader出现故障，以及follower出现故障时内部在数据同步上的两种不同的情况

LEO（Log End Offset）：每个副本的最后一个offset，LEO其实就是最新的offset + 1

HW（High Watermark）：所有副本中最小的LEO

当follower出现故障时，由于leader并没有任何影响，整个集群仍然能够对外提供读写服务，内部大致的处理步骤如下：

follower 发生故障后会被临时踢出ISR； 这个期间Leader和Follower继续接收数据； 待该follower恢复后，Follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向Leader进行同步； 等到该Follower的LEO大于等于该Partition的HW，即follower追上Leader之后，就可以重新加入ISR了

如下为leader发生故障时处理的业务流程，可对照上面的follower的处理过程

 leader处理故障的过程相对来说要简单一些，主要步骤如下：

Leader发生故障之后，会从ISR中选出一个新的Leader；为保证多个副本之间的数据一致性，其余的Follower会先将各自的log文件高于HW的部分截掉，然后从新的Leader同步数据。

为保证多个副本之间的数据一致性，其余的Follower会先将各自的log文件高于HW的部分截掉，然后从新的Leader同步数据。