1、kafka消息发送的流程
在消息发送的过程中,涉及到了两个线程——main 线程和 Sender 线程。在 main 线程中创建了一个双端队列 RecordAccumulator。main 线程将消息发送给 RecordAccumulator,Sender 线程不断从 RecordAccumulator 中拉取消息发送到 Kafka Broker。
0: 生产者发送的数据,不需要等数据落盘应答。
1:生产者发送过来的数据,Leader收到数据后应答。
-1:(all):生产者发送过来的数据,Leader 和 ISR 队列里面的所有节点收齐数据后应答。 -1 和 all 是等价的。
2、Kafka 的设计架构
1)Producer :消息生产者,就是向 kafka broker 发消息的客户端;
2)Consumer :消息消费者,向 kafka broker 取消息的客户端;
3)Consumer Group (CG):消费者组,由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据,一个分区只能由一个组内消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组,即消费者组是逻辑上的一个订阅者。
4)Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker可以容纳多个 topic。
5)Topic :可以理解为一个队列,生产者和消费者面向的都是一个 topic,一个 topic 里保存的是同一类消息,相当于对消息的分类,每个 producer 将消息发送到 kafka 中,都需要指明要存的 topic 是哪个,也就是指明这个消息属于哪一类
6)Partition:为了实现扩展性,一个非常大的 topic 可以分布到多个 broker(即服务器)上,一个 topic 可以分为多个 partition(分区),每个 partition 是一个有序的队列,每个 partition 在存储层面是 append log 文件。任何发布到此 partition 的消息都会被直接追加到 log 文件的尾部。为什么要进行分区呢?最根本的原因就是:kafka基于文件进行存储,当文件内容大到一定程度时,很容易达到单个磁盘的上限,因此,采用分区的办法,一个分区对应一个文件,这样就可以将数据分别存储到不同的server上去,另外这样做也可以负载均衡,容纳更多的消费者。
7)Replica:副本,为保证集群中的某个节点发生故障时,该节点上的 partition 数据不丢失,且 kafka 仍然能够继续工作,kafka 提供了副本机制,一个 topic 的每个分区都有若干个副本,一个 leader 和若干个 follower。
8)leader:每个分区多个副本的“主”,生产者发送数据的对象,以及消费者消费数据的对象都是 leader。
9)follower:每个分区多个副本中的“从”,实时从 leader 中同步数据,保持和 leader 数据的同步。leader 发生故障时,某个 follower 会成为新的leader。
3、Kafka 分区
Kafka的消息通过主题进行分类。主题可比是数据库的表或者文件系统里的文件夹。主题可以被分为若干分区,一个主题通过分区分布于Kafka集群中,提供了横向扩展的能力。
4、Kafka 消息的有序性
kafka只保证单partition有序,如果Kafka要保证多个partition有序,不仅broker保存的数据要保持顺序,消费时也要按序消费。假设partition1堵了,为了有序,那partition2以及后续的分区也不能被消费,这种情况下,Kafka 就退化成了单一队列,毫无并发性可言,极大降低系统性能。因此Kafka使用多partition的概念,并且只保证单partition有序。这样不同partiiton之间不会干扰对方。
5、ISR、OSR、AR 是什么?
1)ISR:In-Sync Replicas是一个副本的列表,里面存储的都是能跟leader 数据一致的副本
2)OSR:于leader副本同步滞后过多的副本(不包括leader副本)将组成 OSR
(Out-of-Sync Replied)由此可见,AR = ISR + OSR。
3)AR:简单来说,分区中的所有副本统称为 AR
(Assigned Replicas)。
6、Kafka 在什么情况下会出现消息丢失
在主leader挂了的时候
7、怎么尽可能保证 Kafka 的可靠性
1.可靠性策略
为保证 producer
发送的数据,能可靠的发送到指定的 topic
,topic
的每个partition
收producer
发送的数据后,都需要向producer
发送ack确认收到,如果producer
收到ack
,就会进行下一轮的发送,否则重新发送数据。
2、同步策略的问题
8、Kafka中如何做到数据唯一,即数据去重?
解决方案:幂等性,幂等性就是指Producer不论向Broker发送多少次重复数据,Broker端都只会持久化一条,保证了不重复。
9、生产者如何提高吞吐量
batch.size:批次大小,默认16K
linger.ms:等待时间,默认0,修改为20ms
RecordAccumulator:缓冲区大小,默认32M,buffer.memory,修改为64m
compression.type:压缩,默认none,可配置值gzip、snappy、lz4和zstd,修改为snappy
10、zk在kafka集群中有何作用?
Kafka使用zk的分布式协调服务,将生产者,消费者,消息储存结合在一起。同时借助zk,kafka能够将生产者,消费者和broker在内的所有组件在无状态的条件下建立起生产者和消费者的订阅关系,实现生产者的负载均衡。
11、简述kafka集群中的Leader选举机制
Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader,负责管理集群broker 的上下线,所有 topic 的分区副本分配和 Leader 选举等工作。
选举是按照AR(跟Replicas一样)进行的,而不是ISR
12、kafka是如何处理数据乱序问题的
当重试请求到来时,batch 会根据 seq重新添加到队列的合适位置,并把max.in.flight.requests.per.connection设为1,这样它前面的 batch序号都比它小,只有前面的都发完了,它才能发。
13、kafka中节点如何服役和退役
服役新节点
新节点准备
开启 hadoop14,并修改 IP 地址。
新启动 hadoop13、hadoop14。
修改 haodoop14 中 kafka 的 broker.id 为 3。
删除 hadoop14 中 kafka 下的 datas 和 logs。
启动 hadoop11、hadoop12、hadoop13 上的 kafka 集群。
单独启动 hadoop14 中的 kafka。
执行负载均衡操作
创建一个要均衡的主题
生成一个负载均衡的计划
创建副本存储计划(所有副本存储在 broker0、broker1、broker2、broker3 中)。
执行副本存储计划。
验证副本存储计划。
退役旧节点
执行负载均衡操作
创建一个要均衡的主题。
创建执行计划。
创建副本存储计划(所有副本存储在 broker0、broker1、broker2 中)。
执行副本存储计划
验证副本存储计划。
执行停止命令
14、Kafka中Leader挂了,Follower挂了,然后再启动,数据如何同步
由于数据同步的时候先进入Leader,随后同步给Follower,假如Follower挂掉了,Leader和其他的Follower 继续往前存储数据,挂掉的节点从ISR集合中剔除,此时挂掉的Follower又重启了,它会先从上一次挂掉的节点的HW开始同步数据,直到追上最后一个Follower为止,此时会重新回归ISR.
15、kafka中初始化的时候Leader选举有一定的规律,如何打破这个规律呢?
手动调整分区副本存储
16、kafka是如何做到高效读写
1)Kafka 本身是分布式集群,可以采用分区技术,并行度高
2)读数据采用稀疏索引,可以快速定位要消费的数据
3)顺序写磁盘
Kafka 的 producer 生产数据,要写入到 log 文件中,写的过程是一直追加到文件末端, 为顺序写。官网有数据表明,同样的磁盘,顺序写能到 600M/s,而随机写只有 100K/s。这与磁盘的机械机构有关,顺序写之所以快,是因为其省去了大量磁头寻址的时间。
4)页缓存 + 零拷贝技术
17、Kafka集群中数据的存储是按照什么方式存储的?
Topic是逻辑上的概念,而partition是物理上的概念,每个partition对应于一个log文件,该log文件中存储的就是Producer生产的数据。Producer生产的数据会被不断追加到该log文件末端,为防止log文件过大导致数据定位效率低下,Kafka采取了分片和索引机制,将每个partition分为多个segment。每个segment包括:“.index”文件、“.log”文件和.timeindex等文件。这些文件位于一个文件夹下,该文件夹的命名规则为:topic名称+分区序号,例如:first-0。
19、简述kafka中的数据清理策略。
Kafka 中默认的日志(这个地方是数据的意思,就是Segment)保存时间为 7 天,可以通过调整如下参数修改保存时间。
log.retention.hours,最低优先级小时,默认 7 天。
log.retention.minutes,分钟。 --如果设置了该值,小时的设置不起作用。
log.retention.ms,最高优先级毫秒。 --如果设置了该值,分钟的设置不起作用。
log.retention.check.interval.ms,负责设置检查周期,默认 5 分钟。
那么日志一旦超过了设置的时间,怎么处理呢?
Kafka 中提供的日志清理策略有 delete 和 compact 两种。
1)delete 日志删除:将过期数据删除
log.cleanup.policy = delete 所有数据启用删除策略
(1)基于时间:默认打开。以 segment 中所有记录中的最大时间戳作为该文件时间戳。
(2)基于大小:默认关闭。超过设置的所有日志总大小,删除最早的 segment。
log.retention.bytes,默认等于-1,表示无穷大。
20、消费者组和分区数之间的关系是怎样的?
(1)每个分区只能被一个消费组中的一个消费者所消费,
(2)消费组中一个消费者可以消费多个分区。
(3)多个消费组,每个消费组都可以消费topic中的所有数据,且消费位移之间互不影响。
21、kafka如何直到哪个消费者消费哪个分区?
Kafka 生产者只会把数据发往 Leader, 然后 Follower 找 Leader 进行同步数据,消费者对Leader进行消费。
22、kafka消费者的消费分区策略有哪些,默认是个?
(1)修改主题 first 为 7 个分区。
bin/kafka-topics.sh --bootstrap-server hadoop11:9092 --alter --topic first --partitions 7
注意:分区数可以增加,但是不能减少。
(2)这样可以由三个消费者
CustomConsumer、CustomConsumer1、CustomConsumer2 组成消费者组,组名都为“test”, 同时启动 3 个消费者。
(3)启动 CustomProducer 生产者,发送 500 条消息,随机发送到不同的分区。
备注:只需要将以前的CustomProducerCallback,修改发送次数为500次即可。
23、kafka中的消费者,他们的偏移量存储在哪里?
consumer 默认将 offset 保存在 Kafka 一个内置的topic 中,该 topic 为 __consumer_offsets
24、kafka中数据挤压太多,怎么办?(提高消费者的效率)
1. 增大partion数量,
2. 消费者加了并发,服务, 扩大消费线程
3. 增加消费组服务数量
4. kafka单机升级成了集群
5. 避免消费者消费消息时间过长,导致超时
6. 使Kafka分区之间的数据均匀分布
25、Kafka中的数据在消费过程中,有漏消费和重复消费的情况,怎么办?
1.先提交offset,再消费消息
offset被提交到kafka broker,但是消息还没来得及被消费,消费者故障了需要重启,由于offset已经被提交了,所以这个情况会发生漏消费的问题。
2.先消费消息,再提交offset
先把消息消费完了,但offset还未被提交,消费者故障重启,消息已经被消费,但offset未提交,此时故障会产生消息重复消费的问题。
26、kafka中的数据已经消费过的数据,是否可以再次消费?怎么做?
通过不同的group来重新消费数据方法简单,但我们无法指定我们要重复消费哪些数据。这里需要注意的是新的group是重新消费所有数据,但也并非是topic中所有数据,它只会消费topic下现在存在的数据。