Kafka面试题整理

5 篇文章 0 订阅
2 篇文章 0 订阅

消息队列的作用和使用场景

  • 作用:
    • 通过异步处理提高响应时间,削峰填谷
      • 场景:数据比较集中且实时要求不是太高,如果同步处理,假如业务高峰需要4台服务支撑,那么在业务高峰过了之后,就会出现资源闲置,如果引入消息队列的话,将数据放到消息队列后直接返回成功,提升了响应时间,真正的业务在消息队列后面消费处理,可能2台服务就能够支撑的住,而且流量更加均匀
    • 降低系统间的耦合度
      • 场景:数据不止一方依赖,可能多个系统都需要这份数据,如果由发送方直接调用,那么如果新增业务也依赖数据,就得修改发送方代码;使用消息队列的话,将发送方和接收方解耦,发送方将数据扔到消息队列,依赖方可根据需求消费处理。

使用消息队列会带来哪些问题?

系统复杂度提高,可用性降低,不仅需要考虑消息队列的可用性,还要考虑数据的一致性

如何做的消息队列选型,为什么选择kafka?

  • kafka和rocketmq吞吐量可达百万级,比activemq、rabbitmq要高一个数量级
  • kafka和rocketmq都是分布式架构,高可用
  • kafka和rocketmq都是毫秒级低延时,rocketmq甚至到微秒级
  • rocketmq不支持队列层面的广播,kafka的consumer group支持组间广播,组内负载均衡
  • kafka可能会产生消息重复,业务做好幂等

kafka相关概念与消费模型

  • broker:kafka集群中的一个节点
  • topic:主题是kafka的逻辑上的队列
  • partition:一个topic可以包含一个或多个partition,每个partition的消息数据都是单独存储的,offset也是单独维护的,partition内部消息有序
  • partition复制因子:一个topic的所有分区会分布到各个broker上,允许设置复制因子使分区可以在其他节点上留存备份,在主分区所在broker宕机时,可以作为新的主分区继续提供服务
  • consumer group:一个topic可以有消费者组消费消息,kafka为每个消费者组单独管理每个分区的消费偏移量offset,消费者组间是广播模式,对于一个消费者组内是负载均衡,即一条消息可以被多个消费者组消费,只能被一个消费者组内的其中一个消费者消费;消费者组内的每个成员负责一定数量的分区,当消费者组内的消费者发生变动时,会触发分区的重平衡
  • pull消费模型:消费者向负责分区主动拉取消息,分区的消费偏移量通过一个默认的topic来记录,也可以显示指定
    • pull模型的优点:
      • 消费速度可以由消费者自由控制
      • 逐条消费或者批量消费可以由消费者自由控制
      • broker设计更简单

kafka的消息存储

  • kafka的消息存储在磁盘上,一个kafka topic分为一个或多个partition,每个partition单独存储自己的消息数据
  • partition将数据记录到.log文件中,为了避免文件过大影响查询效率,将文件分段处理
  • 记录消息到.log文件中的同时,会记录消息offset和物理偏移地址的映射作为索引,提升查找性能;
  • 这个索引并不是按消息的顺序依次记录的,而是每隔一定字节的数据记录一条索引,降低了索引文件的大小
  • kafka查找消息时,只需要根据文件名和offset进行二分查找,找到对应的日志分段后,查找.index文件找到物理偏移地址,然后查.log读取消息内容

消费组与分区重平衡

当有新的消费者加入到消费者组时,原本的分区就需要重新分配;比如一个topic有30个分区,原本只有两个消费者,每人负责15个分区,当新加入一个消费者时,并没有分区可以给他消费,只能是将30个分区重新分配

  • 每个消费者组都会有一个broker负责协调(称为group coordinator),各个消费者通过发送心跳的方式向组协调者同步状态,当有消费者一定时间没有给组协调者发送心跳或者有新的消费者加入到消费者组时,就会触发消费组的重平衡操作
  • 新加入消费者触发重平衡:
    1.新加入消费者向组协调者发送joinGroup请求,携带订阅的topic信息
    2.此后组协调者收到组内其他消费者的心跳请求时,在响应中告诉消费者要重平衡
    3.组内原有消费者会重新发送joinGroup请求到组协调者
    4.组协调者根据发送joinGroup请求的先后选出消费者leader,将topic和分区信息响应给各个消费者
    5.被选为leader的消费者将分区分配好
    6.各消费者发送SyncGroup请求给组协调者请求新分配好的分区信息,其中消费者leader会携带分配好的分区信息
    7.组协调者将各个消费者负责的分区信息响应给消费者,重平衡完成
  • 消费者主动离开导致重平衡
    1.消费者发送leaveGroup请求给组协调者
    2.此后组协调者收到组内其他消费者的心跳请求时,在响应中告诉消费者要重平衡
    3.消费者会重新发送joinGroup请求到组协调者
    4.组协调者根据发送joinGroup请求的先后选出消费者leader,将topic和分区信息响应给各个消费者
    5.被选为leader的消费者将分区分配好
    6.各消费者发送SyncGroup请求给组协调者请求新分配好的分区信息,其中消费者leader会携带分配好的分区信息
    7.组协调者将各个消费者负责的分区信息响应给消费者,重平衡完成
  • 消费者失去心跳导致重平衡
    1.消费者一定时间内没有发送心跳信息给组协调者
    2.此后组协调者收到组内其他消费者的心跳请求时,在响应中告诉消费者要重平衡
    3.消费者会重新发送joinGroup请求到组协调者
    4.组协调者根据发送joinGroup请求的先后选出消费者leader,将topic和分区信息响应给各个消费者
    5.被选为leader的消费者将分区分配好
    6.各消费者发送SyncGroup请求给组协调者请求新分配好的分区信息,其中消费者leader会携带分配好的分区信息
    7.组协调者将各个消费者负责的分区信息响应给消费者,重平衡完成

kafka如何保证不丢失消息?

  • 复制因子:创建topic的时候指定复制因子大于1时,一个分区被分配到一个broker上,同时会在其他broker上维护一个分区副本;
  • isr列表:分区及其副本分别为leader和follower,leader对外提供读写服务,follower会向leader发送同步请求,拉取最新的数据,如果follower和leader的消息差距保持在一定范围之内,那么这个follower在isr列表内;当分区leader所在broker宕机,会从isr列表中选举一个follower作为新的leader提供服务
  • 通过kafka的acks参数可以控制消息的发送行为,acks可选的值有0、1、all;当设置为0时,生产者消息发送成功即为成功,不关心是否写入到磁盘及后续操作;当设置为1时,消息发送到分区leader后写入磁盘即为成功;当设置为all时,消息发送到分区leader并写入磁盘后,同步给isr列表中的所有分区副本后即为成功

kafka高可用

  • broker启动会尝试向zookeeper创建临时节点:/controller,第一个broker选举成功成为集群的controller,其余节点都会在/controller注册watcher监控controller状态;当controller挂掉,所有broker感知到,重新尝试选举controller
  • controller节点通过zookeeper监控各broker状态,如果由broker挂掉,controller负责从其负责的leader分区的isr列表中选举一个作为新的leader
  • kafka副本和leader选举

kafka高性能原因

  • 零拷贝、利用操作系统页缓存、磁盘顺序写
  • 分区、分段、建立索引
  • 生产者、消费者批处理
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值