Kafka集群的Leader选举
- Kafka并没有采用多数投票来选举Leader
原因：
1）节点数据完整性不同，如果完整数据为1万挑，如果不完整数据节点只有9000条数据，如果当选了Leader，数据就丢失了1000条，而导致数据不一致；
2）大数据文本比较慢；
- Kafka会动态维护一组Leader数据的副本（ISR）
ISR的作用：
1）保证所有副本数据的一致性；
2）数据写入的时候，告知所有的ISR都保存一份；
- Kafka会在ISR中选择一个速度比较快的设为Leader
如何判断一个Leader速度比较快？
1）Controller：集群启动的时候会在Zookeeper中去注册一个controller，所有的ISR会去session文件中抢注为Leader；
Controller的作用：
1）管理所有的Broker，检查Broker的健康状态，节点剔除；
2）针对已经损坏的Broker，检查该Broker中有多少的Leader和Follwer；
3）重新分配之类的事情；
特殊情况：ISR中副本全部宕机
对于这种情况，Kafka会如何处理呢？
- 对于这种情况，Kafka会进行 unclean leader选举（脏选举），对于脏选举，提供了两种解决思路
1）等待，当其中一个ISR好了，就选择为Leader；
2）ISR以外的Follower中选举，此情况是丢失数据 ，生产不允许
Leader选举配置建议
- 禁用 “unclean leader” 选举
- 手动指定最小ISR（当ISR小于指定数量的时候，消息发送失败）
故障处理细节
- LEO（Log End Offset）
每个副本的最后一个offset
- HW（High Watermark）
保证消费者数据的一致性，消费者能见到的最大的offset，ISR队列中最小的LEO（所有副本中的最小LEO）
HW解决了两个问题：
1）消费一致性；
2）存储一致性（新的Leader从ISR中选举出来之后，其他的follower会将各自的log文件 高于 HW的部分截掉，然后从新的Leader同步数据）
缺点：
只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。