点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

  • Hadoop（已更完）
  • HDFS（已更完）
  • MapReduce（已更完）
  • Hive（已更完）
  • Flume（已更完）
  • Sqoop（已更完）
  • Zookeeper（已更完）
  • HBase（已更完）
  • Redis （已更完）
  • Kafka（正在更新…）

章节内容

上节我们完成了如下的内容，基本都是特性概念相关的：

  • kafka-topics.sh 的基本参数和基本使用，涉及到创建、查看、修改、主题，增加分区等。
  • KafkaAdminClient
  • Kafka偏移量管理

大数据-63 Kafka 高级特性 分区 副本机制 宕机恢复 Leader选举_大数据

副本机制

大数据-63 Kafka 高级特性 分区 副本机制 宕机恢复 Leader选举_java_02


Kafka在一定数量的服务器上对主题分区进行复制，当集群中一个Broker宕机之后们可以自动故障转移到其他可用的副本上，不会造成数据丢失。

  • 将复制因子为1的未复制主题称为复制主题
  • 主题的分区是复制的最小单元
  • 在非故障的情况下，Kafka中的每个分区都由1个Leader副本，0个或N个Follower副本。
  • 包括Leader副本在内的副本总数构成复制因子
  • 所有读取和写入都是由Leader副本负责
  • 通常分区比Broker多，并且Leader分区在Broker之间平均分配

Follower分区像普通的Kafka消费者一样，消费者来自Leader分区的消息，并将其持久化到自己的日志中，允许Follower对日志条目拉取进行批处理。

同步节点

  • 节点必须能够维持ZooKeeper的会话（通过ZooKeeper的心跳机制）
  • 对于Follower副本分区，它复制在Leader分区上的写入，并且不要延迟太多

Kafka提供的保证是：只要至少有一个同步副本处于活动状态，提交的消息就不会丢失。

宕机恢复

少副本宕机

当Leader宕机了，会从Follower选择一个作为Leader，当宕机重新恢复时，会把之前的commit清空，重新从Leader中Pull数据。

全副本宕机

  • 恢复方式1：等待ISR中的一个恢复后，选为Leader（时间久，可用性低）
  • 恢复方式2：选择一个恢复的副本作为新的Leader，无论是否在ISR中（可能未包含提交commit，会丢失数据）

Leader选举

  • 3个分区
  • 3个Broker

基础概念

大数据-63 Kafka 高级特性 分区 副本机制 宕机恢复 Leader选举_分布式_03


生产者和消费者的请求都由Leader副本处理，Follower副本只负责Leader副本的数据和Leader保持同步。

Leader副本和Follower副本之间的关系并不是固定不变的，在Leader所在的Broker发生故障的时候，就需要进行分区的Leader副本和Follower副本之间的切换，需要选举Leader副本。

如何选举

如果某个分区所在的服务器出了问题导致不可用，Kafka会从该分区的其他副本中选择一个成为新的Leader，之后所有的读写就会转移到这个新的Leader上。
那么如何选择Leader呢？

  • 只有那些跟Leader保持同步的Follower才应该被选择为新的Leader
  • Kafka会在ZooKeeper上针对每个Topic维护一个成为ISR（in-sync replica，已同步的副本）的集合，该集合中是一些分区的副本。
  • 只有当这些副本都跟Leader中的副本同步了之后，Kafka才会认为消息已提交，并反馈给消息的生产者
  • 如果这个集合有增有减，Kafka会更新ZOoKeeper上的记录
  • 如果某个分区的Leader不可用，Kakfa就会从ISR集合中选择一个副本作为新的Leader

显然通过ISR，Kafka需要的冗余度是较低的，可以容忍的失败度较高。
假设某个Topic有N+1个副本，Kafka可以容忍N个服务器不可用。

为何不用少数服从多数

  • 少数服从多数是一种比较常见的一致性算法和Leader选举法
  • 它的含义是只有超过半数的副本同步了，系统才会认为数据已经同步
  • 选择Leader时也是超过半数的同步副本中选择
  • 这种算法需要较高的冗余度，更Kafka比起来，浪费资源
  • 譬如：允许一台机器失败，则要三个副本。允许两台机器失败，则需要五个副本

而在Kafka的ISR集合中，允许一台机器失败，要两个副本。允许三台机器失败，需要五个副本。

若ISR全部失败

此时有两种方案可以选择：

  • 等待ISR集合中的副本复活
  • 选择任何一个立即可用的副本，而这个副本不一定是在ISR集合中（需要设置：unclean.leader.election.enable=true）

这两种方法各有利弊，实际生产中按需选择即可。

  • 如果要等待ISR副本复活，虽然保证一致性，但可能需要很长的时间。
  • 如果选择立即可用的副本，虽然保证可用性，但是数据可能会丢失。