面试题:Kafka如何保证高可用?有图有真相

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 什么是高可用「高可用性」,指系统无间断地执行其功能的能力,代表系统的可用性程度Kafka从0.8版本开始提供了高可用机制,可保障一个或多个Broker宕机后,其他Broker能继续提供服务备份机制Kafka允许同一个Partition存在多个消息副本,每个Partition的副本通常由1个Leader及0个以上的Follower组成,生产者将消息直接发往对应Partition的Leader,Follower会周期地向Leader发送同步请求同一Partition的Replica不应存储在同一个Broker上,因为一旦该Broker宕机,对应Partition的所有Replica都无法工作,这就

上次面试多次被问到一个问题:

Kafka如何保证高可用的?

「下面来跟大家分享下当时我答到的点」

什么是高可用

「高可用性」,指系统无间断地执行其功能的能力,代表系统的可用性程度

Kafka从0.8版本开始提供了高可用机制,可保障一个或多个Broker宕机后,其他Broker能继续提供服务


备份机制

Kafka允许同一个Partition存在多个消息副本,每个Partition的副本通常由1个Leader及0个以上的Follower组成,生产者将消息直接发往对应Partition的Leader,Follower会周期地向Leader发送同步请求

同一Partition的Replica不应存储在同一个Broker上,因为一旦该Broker宕机,对应Partition的所有Replica都无法工作,这就达不到高可用的效果

所以Kafka会尽量将所有的Partition以及各Partition的副本均匀地分配到整个集群的各个Broker上

「如下图举个例子:」


ISR机制

「ISR 副本集合」

ISR 中的副本都是与 Leader 同步的副本,相反,不在 ISR 中的追随者副本就被认为是与 Leader 不同步的

这里的保持同步不是指与Leader数据保持完全一致,只需在replica.lag.time.max.ms时间内与Leader保持有效连接

Follower周期性地向Leader发送FetchRequest请求,发送时间间隔配置在replica.fetch.wait.max.ms中,默认值为500

public class FetchRequest {
    private final short versionId;
    private final int correlationId;
    private final String clientId;
    private final int replicaId;
    private final int maxWait;    // Follower容忍的最大等待时间: 到点Leader立即返回结果,默认值500
    private final int minBytes;   // Follower容忍的最小返回数据大小:当Leader有足够数据时立即返回,兜底等待maxWait返回,默认值1
    private final Map<TopicAndPartition, PartitionFetchInfo> requestInfo;  // Follower中各Partititon对应的LEO及获取数量
}

各Partition的Leader负责维护ISR列表并将ISR的变更同步至ZooKeeper,被移出ISR的Follower会继续向Leader发FetchRequest请求,试图再次跟上Leader重新进入ISR

ISR中所有副本都跟上了Leader,通常只有ISR里的成员才可能被选为Leader

「Unclean领导者选举」

当Kafka中unclean.leader.election.enable配置为true(默认值为false)且ISR中所有副本均宕机的情况下,才允许ISR外的副本被选为Leader,此时会丢失部分已应答的数据

开启 Unclean 领导者选举可能会造成数据丢失,但好处是,它使得分区 Leader 副本一直存在,不至于停止对外提供服务,因此提升了高可用性,反之,禁止 Unclean 领导者选举的好处在于维护了数据的一致性,避免了消息丢失,但牺牲了高可用性


ACK机制

生产者发送消息中包含acks字段,该字段代表Leader应答生产者前Leader收到的应答数

  • 「acks=0」

生产者无需等待服务端的任何确认,消息被添加到生产者套接字缓冲区后就视为已发送,因此acks=0不能保证服务端已收到消息

  • 「acks=1」

只要 Partition Leader 接收到消息而且写入本地磁盘了,就认为成功了,不管它其他的 Follower 有没有同步过去这条消息了

  • 「acks=all」

Leader将等待ISR中的所有副本确认后再做出应答,因此只要ISR中任何一个副本还存活着,这条应答过的消息就不会丢失

acks=all是可用性最高的选择,但等待Follower应答引入了额外的响应时间。Leader需要等待ISR中所有副本做出应答,此时响应时间取决于ISR中最慢的那台机器

如果说 Partition Leader 刚接收到了消息,但是结果 Follower 没有收到消息,此时 Leader 宕机了,那么客户端会感知到这个消息没发送成功,他会重试再次发送消息过去

Broker有个配置项min.insync.replicas(默认值为1)代表了正常写入生产者数据所需要的最少ISR个数

当ISR中的副本数量小于min.insync.replicas时,Leader停止写入生产者生产的消息,并向生产者抛出NotEnoughReplicas异常,阻塞等待更多的Follower赶上并重新进入ISR

被Leader应答的消息都至少有min.insync.replicas个副本,因此能够容忍min.insync.replicas-1个副本同时宕机

「结论:」

发送的acks=1和0消息会出现丢失情况,为不丢失消息可配置生产者acks=all & min.insync.replicas >= 2


故障恢复机制

「Kafka从0.8版本开始引入了一套Leader选举及失败恢复机制」

首先需要在集群所有Broker中选出一个Controller,负责各Partition的Leader选举以及Replica的重新分配

  • 当出现Leader故障后,Controller会将Leader/Follower的变动通知到需为此作出响应的Broker。

Kafka使用ZooKeeper存储Broker、Topic等状态数据,Kafka集群中的Controller和Broker会在ZooKeeper指定节点上注册Watcher(事件监听器),以便在特定事件触发时,由ZooKeeper将事件通知到对应Broker

Broker

「当Broker发生故障后,由Controller负责选举受影响Partition的新Leader并通知到相关Broker」

  • 当Broker出现故障与ZooKeeper断开连接后,该Broker在ZooKeeper对应的znode会自动被删除,ZooKeeper会触发Controller注册在该节点的Watcher;
  • Controller从ZooKeeper的/brokers/ids节点上获取宕机Broker上的所有Partition;
  • Controller再从ZooKeeper的/brokers/topics获取所有Partition当前的ISR;
  • 对于宕机Broker是Leader的Partition,Controller从ISR中选择幸存的Broker作为新Leader;
  • 最后Controller通过LeaderAndIsrRequest请求向的Broker发送LeaderAndISRRequest请求。

Controller

集群中的Controller也会出现故障,因此Kafka让所有Broker都在ZooKeeper的Controller节点上注册一个Watcher

Controller发生故障时对应的Controller临时节点会自动删除,此时注册在其上的Watcher会被触发,所有活着的Broker都会去竞选成为新的Controller(即创建新的Controller节点,由ZooKeeper保证只会有一个创建成功)

竞选成功者即为新的Controller


最后

「写文章画图不易,喜欢的话,希望帮忙点赞,转发下哈,谢谢」

相关文章
|
1月前
|
消息中间件 分布式计算 监控
Python面试:消息队列(RabbitMQ、Kafka)基础知识与应用
【4月更文挑战第18天】本文探讨了Python面试中RabbitMQ与Kafka的常见问题和易错点,包括两者的基础概念、特性对比、Python客户端使用、消息队列应用场景及消息可靠性保证。重点讲解了消息丢失与重复的避免策略,并提供了实战代码示例,帮助读者提升在分布式系统中使用消息队列的能力。
59 2
|
1月前
|
消息中间件 监控 大数据
Kafka消息队列架构与应用场景探讨:面试经验与必备知识点解析
【4月更文挑战第9天】本文详尽探讨了Kafka的消息队列架构,包括Broker、Producer、Consumer、Topic和Partition等核心概念,以及消息生产和消费流程。此外,还介绍了Kafka在微服务、实时数据处理、数据管道和数据仓库等场景的应用。针对面试,文章解析了Kafka与传统消息队列的区别、实际项目挑战及解决方案,并展望了Kafka的未来发展趋势。附带Java Producer和Consumer的代码示例,帮助读者巩固技术理解,为面试做好准备。
45 0
|
2天前
|
消息中间件 存储 Kafka
Kafka 如何保证消息顺序及其实现示例
Kafka 如何保证消息顺序及其实现示例
8 0
|
23天前
|
消息中间件 监控 Java
腾讯面试:如何提升Kafka吞吐量?
Kafka 是一个分布式流处理平台和消息系统,用于构建实时数据管道和流应用。它最初由 LinkedIn 开发,后来成为 Apache 软件基金会的顶级项目。 Kafka 特点是**高吞吐量、分布式架构、支持持久化、集群水平扩展和消费组消息消费**,具体来说: 1. **高吞吐量**:Kafka 具有高性能和低延迟的特性,能够处理大规模数据,并支持每秒数百万条消息的高吞吐量。 2. **分布式架构**:Kafka 采用分布式架构,可以水平扩展,多个节点之间能够实现负载均衡和高可用性。 3. **可持久化**:Kafka 将消息持久化到磁盘中,保证消息的可靠性,即使消费者下线或出现故障,消
31 0
|
29天前
|
消息中间件 关系型数据库 MySQL
MySQL 到 Kafka 实时数据同步实操分享(1),字节面试官职级
MySQL 到 Kafka 实时数据同步实操分享(1),字节面试官职级
|
30天前
|
消息中间件 Java Kafka
Java大文件排序(有手就能学会),kafka面试题2024
Java大文件排序(有手就能学会),kafka面试题2024
|
30天前
|
消息中间件 前端开发 Java
java面试刷题软件kafka和mq的区别面试
java面试刷题软件kafka和mq的区别面试
|
1月前
|
消息中间件 Kafka API
这些年背过的面试题——Kafka篇
本文是技术人面试系列Kafka篇,面试中关于Kafka都需要了解哪些基础?一文带你详细了解,欢迎收藏!
|
1月前
|
消息中间件 Kafka
【Kafka】kafka 分布式下,如何保证消息的顺序消费?
【4月更文挑战第7天】【Kafka】kafka 分布式下,如何保证消息的顺序消费?
|
1月前
|
消息中间件 网络协议 Dubbo
Kafka常见面试题
Kafka常见面试题
35 2