Kafka架构总结以及常见的面试题总结

kafka名词说明

分布式 高吞吐量 消息系统

producer:生产者

consumer:消费者

broker:机器,节点

controller:kafka服务器的主节点 负责管理元数据(zk存储一份)

follower:kafka服务器的从节点 (同步元数据)

topic:主题。类似于关系型数据库中的表

partition:一个主题可以有多个分区

replica:副本,为了保证数据安全,每个partition可以设置多个副本(leader replica和slave replica)

message:消息 存放在partition里

offset:偏移量 消费者的消费进度

 

NIO:同步非阻塞,服务器实现模式为一个请求一个线程,即客户端发送的连接请求都会注册到多路复用器上,多路复用器轮询到连接有I/O请求时才启动一个线程进行处理

reactor

 

跳表索引 空间换时间 加快消息所在文件查找

 

producer端高性能:批处理、内存池、封装同一服务器请求

批处理是消息达到16K或者默认0ms发送一批次 batch.size linger.ms

consumer

同一消费者组内部是P2P模式,一个消息只能被同一个消费者组的一个消费者消费

不同组是发布订阅模式

0.10后偏移量存储方式由zk改为kafka自身的topic 名字为__consumer_offsets-0到49默认50分区

zk不适合高并发

如何通过offset查找Message

例如,读取offset=368776的Message,需要通过如下两个步骤。

第一步:查找Segment File.

00000000000000000000.index表示最开始的文件,其实偏移量(offset)为0;第二个文件00000000000000368769.index的其实偏移量为368770(368769+1),依次类推。以其实偏移量命名并排序这些文件,只要根据offset**二分查找**文件列表,就可以快速定位到具体文件。

  当offset=368776时,定位到00000000000000368769.index|log。

第二步:通过Segment File 查找Message。

  通过第一步定位到Segment File,当offset=368776时,依次定位到00000000000000368769.index的元数据物理位置和00000000000000368769.log的物理偏移地址,然后再通过00000000000000368769.log顺序查找,知道offset=368776为止。

  Segment Index File采取稀疏索引存储方式,可以减少索引文件大小,通过Linux mmap接口可以直接进行内存操作。稀疏索引为数据文件的每个对应Message设置一个元数据指针,它比稠密索引节省了更多的存储空间,但查找起来需要消耗更多的时间。

 

kafka元数据刷新时间默认5min

 

生产者发送数据流程

消息封装成ProducerRecord

序列化

消息计算分区(带key为hash,不带为轮询;与broker通信获取元数据信息)

将消息放到RecordAccumulator(缓存默认32M)

启动一个Sender线程,去缓存中取消息,封装成批次(默认16K)

该线程将批次数据发送到broker

Kafka架构总结以及常见的面试题总结_第1张图片

Kafka架构总结以及常见的面试题总结_第2张图片

RecordAccmulator 原理

Kafka架构总结以及常见的面试题总结_第3张图片

 

ISR:副本同步队列

AR:所有副本

isr由leader负责维护,follower从leader同步数据有一定的延迟,如果某个follower超过该阈值没有完成同步,leader就会把该follower从isr中剔除,放到osr中,

osr+isr = ar

kafka中的broker 是干什么的

broker 是消息的代理,Producers往Brokers里面的指定Topic中写消息,Consumers从Brokers里面拉取指定Topic的消息,然后进行业务处理,broker在中间起到一个代理保存消息的中转站。

producer如何优化速度:

增加线程

提高 batch.size

增加更多 producer 实例

增加 partition 数

设置 acks=-1 时,如果延迟增大:可以增大 num.replica.fetchers(follower 同步数据的线程数)来调解;

跨数据中心的传输:增加 socket 缓冲区设置以及 OS tcp 缓冲区设置。

 

消费者分区分配策略

range

range策略是基于每个主题的 对于每个主题,我们以数字顺序排列可用分区,以字典顺序排列消费者。然后,将分区数量除以消费者总数,以确定分配给每个消费者的分区数量。如果没有平均划分(PS:除不尽),那么最初的几个消费者将有一个额外的分区。

轮询

轮询分配策略是基于所有可用的消费者和所有可用的分区的

与前面的range策略最大的不同就是它不再局限于某个主题

如果所有的消费者实例的订阅都是相同的,那么这样最好了,可用统一分配,均衡分配

 

丢数据场景:

ack=0 没有消息确认,

ack=1 leader收到消息即发送ack,此时如果isr中的follower还没同步leader,leader就出问题,这部分数据就回丢失

ack=-1 等待所有follower同步完数据后,再发送ack,延时高,数据安全性最高,也会出现丢失数据的情况:如果isr中只有leader一台机器时,相当于ack=1的时候

另一个是使用高级消费者的时候消费者读完数据就提交offset,但数据还没处理完就挂掉了,此时重新启动后上一部分数据就不能再消费(使用低级消费者)

 

数据重复场景:

cks = -1 的情况下,数据发送到 leader 后 ,部分 ISR 的副本同步,leader 此时挂掉。比如 follower1 和 follower2 都有可能变成新的 leader, producer 端会得到返回异常,producer 端会重新发送数据,数据可能会重复

 

另外, 在高阶消费者中,offset 采用自动提交的方式, 自动提交时,假设 1s 提交一次 offset 的更新,设当前 offset = 10,当消费者消费了 0.5s 的数据,offset 移动了 15,由于提交间隔为 1s,因此这一 offset 的更新并不会被提交,这时候我们写的消费者挂掉,重启后,消费者会去 ZooKeeper 上获取读取位置,获取到的 offset 仍为10,它就会重复消费. 解决办法使用低级消费者

Kafka中是怎么体现消息顺序性的?

kafka每个partition中的消息在写入时都是有序的,消费时,每个partition只能被每一个group中的一个消费者消费,保证了消费时也是有序的。

整个topic不保证有序。如果为了保证topic整个有序,那么将partition调整为1.

 

KAFKA速度快的原因:

直接使用linux的cache高效缓存数据

顺序写磁盘 减少寻址

使用零拷贝 传统的数据发送需要发送四次上下切换,采用sendfile系统调用后,数据直接在内核态转换,系统上下文切换变成2次

 

数据传输的事物定义有哪三种?

数据传输的事务定义通常有以下三种级别:

(1)最多一次: 消息不会被重复发送,最多被传输一次,但也有可能一次不传输

(2)最少一次: 消息不会被漏发送,最少被传输一次,但也有可能被重复传输.

(3)精确的一次(Exactly once): 不会漏传输也不会重复传输,每个消息都传输被一次而

且仅仅被传输一次,这是大家所期望的

 

Kafka 判断一个节点是否还活着有那两个条件?

(1)节点必须可以维护和 ZooKeeper 的连接,Zookeeper 通过心跳机制检查每个节点的连

(2)如果节点是个 follower,他必须能及时的同步 leader 的写操作,延时不能太久

producer 是否直接将数据发送到 broker 的 leader(主节点)?

producer 直接将数据发送到 broker 的 leader(主节点),不需要在多个节点进行分发,为了

帮助 producer 做到这点,所有的 Kafka 节点都可以及时的告知:哪些节点是活动的,目标

topic 目标分区的 leader 在哪。这样 producer 就可以直接将消息发送到目的地了

Kafa consumer 是否可以消费指定分区消息?

Kafa consumer 消费消息时,向 broker 发出"fetch"请求去消费特定分区的消息,consumer

指定消息在日志中的偏移量(offset),就可以消费从这个位置开始的消息,customer 拥有

了 offset 的控制权,可以向后回滚去重新消费之前的消息,这是很有意义的

Kafka 消息是采用 Pull 模式,还是 Push 模式?

producer 将消息推送到 broker,consumer 从 broker 拉取消息

Kafka 存储在硬盘上的消息格式是什么?

消息由一个固定长度的头部和可变长度的字节数组组成。头部包含了一个版本号和 CRC32

校验码。

消息长度: 4 bytes (value: 1+4+n)

版本号: 1 byte

CRC 校验码: 4 bytes

具体的消息: n bytes

Kafka 与传统消息系统之间有三个关键区别

(1).Kafka 持久化日志,这些日志可以被重复读取和无限期保留

(2).Kafka 是一个分布式系统:它以集群的方式运行,可以灵活伸缩,在内部通过复制数据

提升容错能力和高可用性

(3).Kafka 支持实时的流式处理

Kafka 高效文件存储设计特点:

(1).Kafka 把 topic 中一个 parition 大文件分成多个小文件段,通过多个小文件段,就容易定

期清除或删除已经消费完文件,减少磁盘占用。

(2).通过索引信息可以快速定位 message 和确定 response 的最大大小。

(3).通过 index 元数据全部映射到 memory,可以避免 segment file 的 IO 磁盘操作。

(4).通过索引文件稀疏存储,可以大幅降低 index 文件元数据占用空间大小

Kafka 新建的分区会在哪个目录下创建

在启动 Kafka 集群之前,我们需要配置好 log.dirs 参数,其值是 Kafka 数据的存放目录,

这个参数可以配置多个目录,目录之间使用逗号分隔,通常这些目录是分布在不同的磁盘

上用于提高读写性能。

当然我们也可以配置 log.dir 参数,含义一样。只需要设置其中一个即可。

如果 log.dirs 参数只配置了一个目录,那么分配到各个 Broker 上的分区肯定只能在这个

目录下创建文件夹用于存放数据。

但是如果 log.dirs 参数配置了多个目录,那么 Kafka 会在哪个文件夹中创建分区目录呢?

答案是:Kafka 会在含有分区目录最少的文件夹中创建新的分区目录,分区目录名为 Topic

名+分区 ID。注意,是分区文件夹总数最少的目录,而不是磁盘使用量最少的目录!也就

是说,如果你给 log.dirs 参数新增了一个新的磁盘,新的分区目录肯定是先在这个新的磁

盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。

partition 的数据如何保存到硬盘

topic 中的多个 partition 以文件夹的形式保存到 broker,每个分区序号从 0 递增,

且消息有序

Partition 文件下有多个 segment(xxx.index,xxx.log)

segment 文件里的 大小和配置文件大小一致可以根据要求修改 默认为 1g

如果大小大于 1g 时,会滚动一个新的 segment 并且以上一个 segment 最后一条消息的偏移

量命名

消费者负载均衡策略

一个消费者组中的一个分片对应一个消费者成员,他能保证每个消费者成员都能访问,如

果组中成员太多会有空闲的成员

kafaka 生产数据时数据的分组策略

生产者决定数据产生到集群的哪个 partition 中

每一条消息都是以(key,value)格式

Key 是由生产者发送数据传入

所以生产者(key)决定了数据产生到集群的哪个 partition

你可能感兴趣的:(kafka,Hadoop相关,原理,大数据,kafka)