Kafka面试

1、kafka数据读写过程简述一下

几个基本的概念：
broker： 消息处理结点，多个broker组成kafka集群。
topic： 一类消息，如page view，click行为等。
partition： topic的物理分组，每个partition都是一个有序队列。
replica：partition 的副本，保障 partition 的高可用。
producer： 产生信息的主体，可以是服务器日志信息等。
consumer： 消费producer产生话题消息的主体。
Consumer group：high-level consumer API 中，每个 consumer 都属于一个 consumer group，每条消息只能被 consumer group 的一个 Consumer 消费，但可以被多个 consumer group 消费。
segment： 多个大小相等的段组成了一个partition。
offset： 一个连续的用于定位被追加到分区的每一个消息的序列号，最大值为64位的long大小，19位数字字符长度。
massage： kafka中最基本的传递对象，有固定格式。
zookeeper：kafka 通过 zookeeper 来存储集群的 meta 信息。
controller：kafka 集群中的其中一个服务器，用来进行 leader election 以及 各种 failover。

写过程：

图来自：https://www.jianshu.com/p/d3e963ff8b70

 

Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉去指定Topic的消息，然后进行业务处理。图中有两个topic，topic 0有两个partition，topic 1有一个partition，三副本备份。可以看到consumergroup1中的consumer2没有分到partition处理，这是有可能出现的。关于broker、topics、partitions的一些元信息用zk来存，监控和路由啥的也都会用到zk。
 

生产过程：

创建一条记录，记录中一个要指定对应的topic和value，key和partition可选。 先序列化，然后按照topic和partition，放进对应的发送队列中。kafka produce都是批量请求，会积攒一批，然后一起发送，不是调send()就进行立刻进行网络发包。发送到partition分为两种情况

指定了key，按照key进行哈希，相同key去一个partition。
没有指定key，round-robin来选partition
生产者将消息发送至该 partition leader。之后生产者会根据设置的 request.required.acks 参数不同，选择等待或或直接发送下一条消息。

request.required.acks = 0 表示 Producer 不等待来自 Leader 的 ACK 确认，直接发送下一条消息。在这种情况下，如果 Leader 分片所在服务器发生宕机，那么这些已经发送的数据会丢失。

request.required.acks = 1 表示 Producer 等待来自 Leader 的 ACK 确认，当收到确认后才发送下一条消息。在这种情况下，消息一定会被写入到 Leader 服务器，但并不保证 Follow 节点已经同步完成。所以如果在消息已经被写入 Leader 分片，但是还未同步到 Follower 节点，此时Leader 分片所在服务器宕机了，那么这条消息也就丢失了，无法被消费到。

request.required.acks = -1 表示 Producer 等待来自 Leader 和所有 Follower 的 ACK 确认之后，才发送下一条消息。在这种情况下，除非 Leader 节点和所有 Follower 节点都宕机了，否则不会发生消息的丢失。
 

当时追问了如果没有key的情况：

round-robin来选partition ，即轮询的方式

 

简述写过程：链接：https://www.jianshu.com/p/1584c425cba5

1.生产者将数据封装到ProducerRecord中,将ProducerRecord放到一个批次batch中,当该batch达到一定大小,或者一定时间,提交写入请求
2.生产者根据分区规则确定该分区的编号,根据zk保存的元数据,确定该分区leader副本 所在的broker节点的地址
3.将数据写入leader副本所在机器的页缓存(pagecache)中,操作系统级别
4.操作系统后台将数据从页缓存中flush到磁盘segment片段的xxx.log文件中,顺序写入
5.该分区的其他follower副本跟leader副本同步数据

问题 kafak为何写入数据这么快
1.用户写入数据的时候,以batch批次形式写入,减少了连接时间
2.写入数据到pagecache页缓存中
3.flush到sgement中 000.log中是顺序写入
页缓存+顺序写入

kafka为何读数据这么快
1.先内存中读数据 pagecahche + 零拷贝
2.再.读取日志文件 index稀疏索引机制+顺序读

简述读流程：链接：https://www.jianshu.com/p/1584c425cba5

1.消费者访问zk的元数据,根据topic,partition,offset确定数据所在的broker节点地址
2.然后到该节broker中leader副本的pagecache页缓存中通zero copy 零拷贝机制读取数据
3.如果页缓存中没有,就到磁盘segment中读取,根据offset的范围确定segment,然后查询xxxx.index 稀疏索引 到xxxx.log文件中定位数据.

 

2、kafka多个partition之间数据备份过程讲一下

原文链接：https://blog.csdn.net/WangMapleWang/article/details/126927457

leader副本有属性 HW、LEO、Remote LEO(所有其它follower副本的LEO)
HW = Math.max[currentHW, min(LEO1，LEO2…LEOn)]

follower副本有属性 HW、LEO
HW = Math.min(currentHW，currentLEO)

 

follower副本会定时拉取leader副本内容，保持副本在ISR列表中，初始时都为0
生产者发送一条消息leader持久化到磁盘后，leader的LEO位移+1，HW=Math.max(0, min(0))=0
follower同步leader新数据且持久化到自己的磁盘后，自身的LEO+1，HW=Math.min(0,1)=0
follower再次同步leader，leader的RemoteLEO更新为1，更新HW=Math.max(0, min(1))=1， follower收到leader的HW=1，更新HW = Math.min(1, 1) = 1
HW类似二阶段提交，leader在所有（ISR列表副本）都同步持久化后，表示消息在所有副本都可见，才去更新值。
最少同步副本min.insync.replicas，代表 ISR列表中至少要有几个可用副本，当小于该值时，就认为整个分区处于不可用状态
follower在leader更新后，下一次的同步拉取最新的HW值，这将导致一些问题：