kafka高可用分析

  kafka作为大数据中常用的消息队列，除了其吞吐量高外，当然高可用更是保障数据可靠性的保证，作为载体的topic，在物理内部其实是由很多歌partition组成，也就是topic也是分片了的，这是高吞吐率的保证。每个partition又由多个segment组成，这是出于便于管理消息，因为若是按照partition作为基本单位的话，那么以后对消息的增删是个很大的问题。示意图如下：

 

   注意：这里出现了HW和LEO，这是为了给consumer用的，后面会说明。

    一般来说，服务端的构架的可靠性都是通过备份（leader+flower）来解决的，kafka也不例外，一般会给其设置若干个副本，当然副本过多会影响其性能，若不设置，单节点可靠性就得不得保证，这就是需要根据实际情况，通常都会成设置大于1的。虽然我们设置了副本，那leader怎么知道flower备份就完成了呢？究竟应该以什么样的标准判断其备份完成了呢？若迟迟不给leader回应显然又会影响其运行效率。那怎么告诉leader已经备份完成了呢？假若我们等所有的flower备份完成才告诉leader，那么万一flower里面出现故障或者挂了，那岂不是让leader迟迟等不到回应，显然这样的策略是极其慢的。那假若不管flower是否备份完成，那可靠性就没法保证，设置flower的作用就没了价值，因为万一leader挂了，该什么办，如果从flower里面选择出的新的leader，有可能信息不完整（不是最新的数据），这样的策略显然也是不行的。kafka选择的策略特别机智，就是区别对待，效率高的flower放在一个区，效率低的flower放在一个区，这样如果直接以快的区的flower备份完成为信号给leader回应完成，效率低的区，尽量去备份，这样不仅仅解决了效率问题还解决了可靠性保证。一旦在快的区发现效率低的就直接剔除到慢的区，直到其效率恢复后又可以进效率高的区。新的flower也是进入慢的区，代考验期效率后又进入效率高的区。这里说的快的区，在kafka里面被称为ISR，慢的区被称为OSR，ISR和OSR加起来称为AR。AR也就是当前partition所有的flower。示意图如图所示：

    假若leader挂了该怎么办呢？当然是重新选择新的leader，那怎么选择新的leader，通常高可用里面选择新的leader是通过第三方投票，多票者胜出担任新leader，kafka没有这样采用这样的策略，这是考虑到，既然ISR里面的都备份了leader的数据，干嘛不直接随便选择一个作为新的leader，那么大费周章干嘛。那下一个问题又来了，假如ISR里面的没了flower，首先leader得不到回应，其次压根就没了新leader的候选人，这可如何是好呢？

    首先，ISR里面的没了flower分为两种情况一个是都被剔除到了OSR，一种是都挂了。鉴于前者，配置一个参数（min.insync.replicas）即可，如果ISR中的副本数少于min.insync.replicas配置的数量时，客户端会返回异常：org.apache.kafka.common.errors.NotEnoughReplicasExceptoin: Messages are rejected since there are fewer in-sync replicas than required。对于后者，kafka考虑到了这种情况，通过unclean.leader.election.enable来进行控制。如果配置为true （默认就是 true） 则选择第一个复活的副本作为leader 无论其是否是ISR中的成员 这种方式下 恢复的最快但是可能丢失数据；如果配置为false，则必须等待 ISR中得到一个成员复活，才能成为新的leader，这种情况下 可以保证数据不丢，但是可能比较慢，如果ISR中的成员都无法复活，则即使OSR中的follower启来，整个分区都仍然无法访问。

    对了，前面提到的HW和LEO还没解释，设置这样一个场景，如果我们在备份还没完成的时候消费者向我们要数据，那该如何是好？于是设置了一个阈值HW，就是消费者只能消费HW之前的数据，新的数据是没法消费的，等完成备份后才能消费。LEO表示的是最新的日志数据的位置，那个位置只有等到LW到达后才能进行消费。为啥考虑这样操作，如果我们还没备份完成，消费者消费到了数据，突然leader挂了，那数据怎么保证可靠性呢？

这篇文章基本上都是参考这篇博客（https://blog.csdn.net/u013256816/article/details/71091774），作者写的确实很详细。