0


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

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

目前已经更新到了:

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

章节内容

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

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

在这里插入图片描述

副本机制

在这里插入图片描述
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

基础概念

在这里插入图片描述
生产者和消费者的请求都由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副本复活,虽然保证一致性,但可能需要很长的时间。
  • 如果选择立即可用的副本,虽然保证可用性,但是数据可能会丢失。

本文转载自: https://blog.csdn.net/w776341482/article/details/140885169
版权归原作者 武子康 所有, 如有侵权,请联系我们删除。

“大数据-63 Kafka 高级特性 分区 副本机制 宕机恢复 Leader选举”的评论:

还没有评论