目录
1、kafka的消费者是pull(拉)还是push(推)模式,这种模式有什么好处?
6、partition的数据文件(offffset,MessageSize,data)
1、kafka 分布式(不是单机)的情况下,如何保证消息的顺 序消费?
2、kafka 如何不消费重复数据?比如扣款,我们不能重复的扣。
3、kafka如何实现数据的高效读取?(顺序读写、分段命令、二分查找)
4、Kafka 中的ISR(InSyncRepli)、OSR(OutSyncRepli)、AR(AllRepli)代表什么?
Kafka 面试题
Kafka是一种高吞吐量、分布式、基于发布/订阅的消息系统,最初由LinkedIn公司开发,使用Scala语言编写,目前是Apache的开源项目。
普通问题
1、kafka常用命令
创建主题(topic)
kafka-topic.sh --create --topic hadoop01 --zookeeper bigdata01:2181,bigdata02:2181,bigdata03:2181 --partitions 3 --replication-factor 3
创建一个名叫hadoop01的主题,它拥有三个分区,三个备份,运行在bigdata01,bigdata02,bigdata03所组成的集群上。
产生数据
kafka-console-producer.sh --topic laoyankafka --broker-list bigdata01:9092,bigdata02:9092,bigdata03:9092
消费数据
kafka-console-consumer.sh --topic laoyankafka --bootstrap-server bigdata01:9092,bigdata02:9092,bigdata03:9092
查看主题列表
kafka-topics.sh --list --zookeeper bigdata01:2181,bigdata02:2181,bigdata03:2181
查看某一个topic的详细信息
kafka-topics.sh --describe --topic laoyankafka --zookeeper bigdata01:2181,bigdata02:2181,bigdata03:2181
修改topic的参数
kafka-topics.sh --alter --topic laoyankafka --partitions 4 --zookeeper bigdata01:2181,bigdata02:2181,bigdata03:2181
修改分区数量,只能增加,不能减少
删除topic
kafka-topic.sh --delect --topic hadoop --zookeeper bigdata01:2181,bigdata02:2181,bigdata03:2181
这个删除只是标记这个主题删除,并不是立即删除。在重启kafka之后才会删除。
也可以在server.propertise中配置 delete.topic.enable=true 表示立即删除
上述命令必须有环境变量
2、常用的消息中间价
-
Kafka: 是最适用于大数据技术的消息中间件。
-
RabbitMQ: Erlang编写。
-
RocketMQ: 阿里出品,纯java,性能特别好,但是特别大,不好安装,还收费。
-
ActiveMQ: 实现了SUN公司当年JMS规范的,学习成本不高,也比较好用,性能不是特别高。
-
Redis: 也有分布订阅模式,但是一般不说它是消息中间件。
3、kafka的应用场景
-
解耦:各个系统通过消息系统这个统一的接口交换数据,可以独立的扩展或修改两边的处理过程。
-
削峰:消息系统可顶住峰值流量,业务系统可根据处理能力从消息系统中获取并处理对应量的请求
-
冗余:消息系统有持久化数据的能力,可以避免数据在处理前丢失
-
扩展:消息系统是统一的数据接口,各系统可独立扩展
-
可恢复性:系统中部分键失效并不会影响整个系统,它恢复会仍然可从消息系统中获取并处理数据
-
异步通信 在不需要立即处理请求的场景下,可以将请求放入消息系统,合适的时候再处理
4、消息队列的分类
1、点对点
消息发送方给消息接收方发送消息,别人是无法获取的
2、发布订阅模式(重点)
消息发送方,将消息发送给topic ,只要订阅了这个topic的消费者就会收到消息,类似于群发(报纸订阅)
5、kafka核心组成部分
生产者(producers)
允许应用程序发布记录流至一个或者多个kafka的主题(topics)。
消费者(consumers)
允许应用程序订阅一个或者多个主题,并处理这些主题接收到的记录流
StreamsAPI
允许应用程序充当流处理器(stream processor),从一个或者多个主题获取输入流,并生产一个输出流到一个或 者多个主题,能够有效的变化输入流为输出流。
ConnectorAPI
允许构建和运行可重用的生产者或者消费者,能够把kafka主题连接到现有的应用程序或数据系统。例如:一个连 接到关系数据库的连接器可能会获取每个表的变化。
6、kafka的三大特征
-
高吞吐量 可以满足每秒百万级别消息的生产和消费——生产消费。
-
持久性 有一套完善的消息存储机制,确保数据的高效安全的持久化——中间存储。
-
分布式 基于分布式的扩展和容错机制;Kafka的数据都会复制到几台服务器上。当某一台故障失效时,生产者和消费者转而使用其它的机器——整体
7、kafka名词解释
-
Kafka服务:
-
Topic:主题,Kafka处理的消息的不同分类。
-
Broker:消息服务器代理,Kafka集群中的一个kafka服务节点称为一个broker,主要存储消息数据。存在硬盘中。每个topic都是有分区的。
-
Partition:Topic物理上的分组,一个topic在broker中被分为1个或者多个partition,分区在创建topic的时候指定。
-
Message:消息,是通信的基本单位,每个消息都属于一个partition
-
Kafka服务相关
-
Producer:消息和数据的生产者,向Kafka的一个topic发布消息。
-
Consumer:消息和数据的消费者,定于topic并处理其发布的消息。
-
Zookeeper:协调kafka的正常运行。
8、Kafka的那些设计让它有如此高的性能?
-
1.kafka是分布式的消息队列
-
2.对log文件进行了segment,并对segment创建了索引
-
3.(对于单节点)使用了顺序读写,速度能够达到600M/s
-
4.引用了zero拷贝,在os系统就完成了读写操做
进阶问题
1、kafka的消费者是pull(拉)还是push(推)模式,这种模式有什么好处?
producer 将消息推送到 broker,consumer 从broker 拉取消息。
优点
pull方式consumer能自己决定是否批量拉取,拉取速度可控。而push模式的速度由broker决定,过于依赖broker性能,速度太快造成消费者崩溃,太慢又浪费性能。
缺点
如果 broker 没有可供消费的消息,将导致 consumer 不断在循环中轮询,直到新消息到到达。为了避免这点,Kafka 有个参数(timeout)可以让 consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发送)。
2、kafka维护消息状态的跟踪方法
Kafka中的Topic 被分成了若干分区,每个分区在同一时间只被一个 consumer 消费。然后再通过offset进行消息位置标记,通过位置偏移来跟踪消费状态。相比其他一些消息队列使用“一个消息被分发到consumer 后 broker 就马上进行标记或者等待 customer 的通知后进行标记”的优点是,避免了通信消息发送后,可能出现的程序奔溃而出现消息丢失或者重复消费的情况。同时也无需维护消息的状态,不用加锁,提高了吞吐量。
3、zookeeper对于kafka的作用是什么?
Zookeeper 主要用于在集群中不同节点之间进行通信,在 Kafka 中,它被用于提交偏移量,因此如果节点在任何情况下都失败了,它都可以从之前提交的偏移量中获取,除此之外,它还执行其他活动,如: leader 检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。
它是一个分布式协调框架。很好的将消息生产、消息存储、消息消费的过程结合在一起。在典型的Kafka集群中, Kafka通过Zookeeper管理集群配置,选举leader,以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker,Consumer使用pull模式从broker订阅并消费消息.
4、kafka判断一个节点还活着的有那两个条件?
-
(1)节点必须维护和 ZooKeeper 的连接,Zookeeper 通过心跳机制检查每个节点的连接
-
(2)如果节点是个 follower,他必须能及时的同步 leader 的写操作,延时不能太久
5、kafka的三种ack应答机制
request.required.acks 有三个值 0 1 -1(all),具体如下:
-
0:生产者不会等待 broker 的 ack,这个延迟最低但是存储的保证最弱当 server 挂掉的时候就会丢数据。
-
1:服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader挂掉后他不确保是否复制完成新 leader 也会导致数据丢失。
-
-1(all):服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的ack,这样数据不会丢失。
6、partition的数据文件(offffset,MessageSize,data)
partition中的每条Message包含了以下三个属性: offset,MessageSize,data,其中offset表示Message在这个partition中的偏移量,offset不是该Message在partition数据文件中的实际存储位置,而是逻辑上一个值,它唯一确定了partition中的一条Message,可以认为offset是partition中Message的 id;
MessageSize表示消息内容data的大小;
data为Message的具体内容。
7、kafka中的segment
一个Topic 分成多个partition ,每一个partition中的数据都是不一样的。数据是存储在partition中的,更确切来讲,在segment中。
一个partition有好几个segment。
segment是逻辑概念,他是由.log文件与.index文件组成的。在partition创建的时候会生成一个segment,segment达到1GB的时候就会生成一个新的segment,往新的segment中写入。
.log 存储的是kafka中的数据
.index 存储的是索引数据,索引数据可以非常方便的查找到log文件中的数据
这两个文件前面的Long数字是偏移量offset
8、Kafka缺点?
-
由于是批量发送,数据并非真正的实时;
-
对于mqtt协议不支持;
-
不支持物联网传感数据直接接入;
-
仅支持统一分区内消息有序,无法实现全局消息有序;
-
监控不完善,需要安装插件;
-
依赖zookeeper进行元数据管理;
高级问题
1、kafka 分布式(不是单机)的情况下,如何保证消息的顺 序消费?
Kafka 分布式的单位 是 partition,同 一 个 partition 用一 个 write ahead log 组织 , 所以可以保证 FIFO 的顺序。 不同 partition 之间不能保证顺序。 但是绝大多数用 户都可以通过 message key 来定义, 因为同一个 key 的 message 可以保证只发 送到同一个 partition。
Kafka 中发送 1 条消息的时候, 可以指定 (topic, partition, key) 3 个参数。
partiton 和 key 是可选的 。如果你指定了 partition,那就是所有消息发往同 1 个 partition,就是有序的 。并且在消费端 ,Kafka 保证 ,1 个 partition 只能 被 1 个 consumer 消费 。或者你指定 key( 比如 order id),具有同 1 个 key 的 所有消息, 会发往同 1 个 partition。
2、kafka 如何不消费重复数据?比如扣款,我们不能重复的扣。
这个问题换种问法,就是kafka如何保证消息的幂等性。对于消息队列来说,出现重复消息的概率还是挺大的,不能完全依赖消息队列,而是应该在业务层进行数据的一致性幂等校验。
比如你处理的数据要写库(mysql,redis等),你先根据主键查一下,如果这数据都有了,你就别插入了,进行一些消息登记或者update等其他操作。另外,数据库层面也可以设置唯一健,确保数据不要重复插入等 。一般这里要求生产者在发送消息的时候,携带全局的唯一id。
3、kafka如何实现数据的高效读取?(顺序读写、分段命令、二分查找)
Kafka为每个分段后的数据文件建立了索引文件,文件名与数据文件的名字是一样的,只是文件扩展名为index。 index文件中并没有为数据文件中的每条Message建立索引,而是采用了稀疏存储的方式,每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间,从而可以将索引文件保留在内存中。
4、Kafka 中的ISR(InSyncRepli)、OSR(OutSyncRepli)、AR(AllRepli)代表什么?
答:kafka中与leader副本保持一定同步程度的副本(包括leader)组成ISR。与leader滞后太多的副本组成OSR。分区中所有的副本通称为AR。
-
ISR : 速率和leader相差低于10秒的follower的集合
-
OSR : 速率和leader相差大于10秒的follower
-
AR : 全部分区的follower
5、Kafka为什么不支持读写分离?
1、 这其实是分布式场景下的通用问题,因为我们知道CAP理论下,我们只能保证C(一致性)和A(可用性)取其一,如果支持读写分离,那其实对于一致性的要求可能就会有一定折扣,因为通常的场景下,副本之间都是通过同步来实现副本数据一致的,那同步过程中肯定会有时间的消耗,如果支持了读写分离,就意味着可能的数据不一致,或数据滞后。
2、 Leader/Follower模型并没有规定Follower副本不可以对外提供读服务。很多框架都是允许这么做的,只是 Kafka最初为了避免不一致性的问题,而采用了让Leader统一提供服务的方式。
3、 不过,自Kafka 2.4之后,Kafka提供了有限度的读写分离,也就是说,Follower副本能够对外提供读服务。
6、请谈一谈 Kafka 数据一致性原理
一致性就是说不论是老的 Leader 还是新选举的 Leader,Consumer 都能读到一样的数据。
假设分区的副本为3,其中副本0是 Leader,副本1和副本2是 follower,并且在 ISR 列表里面。虽然副本0已经写入了 Message4,但是 Consumer 只能读取到 Message2。因为所有的 ISR 都同步了 Message2,只有 High Water Mark 以上的消息才支持 Consumer 读取,而 High Water Mark 取决于 ISR 列表里面偏移量最小的分区,对应于上图的副本2,这个很类似于木桶原理。
这样做的原因是还没有被足够多副本复制的消息被认为是“不安全”的,如果 Leader 发生崩溃,另一个副本成为新 Leader,那么这些消息很可能丢失了。如果我们允许消费者读取这些消息,可能就会破坏一致性。试想,一个消费者从当前 Leader(副本0) 读取并处理了 Message4,这个时候 Leader 挂掉了,选举了副本1为新的 Leader,这时候另一个消费者再去从新的 Leader 读取消息,发现这个消息其实并不存在,这就导致了数据不一致性问题。
当然,引入了 High Water Mark 机制,会导致 Broker 间的消息复制因为某些原因变慢,那么消息到达消费者的时间也会随之变长(因为我们会先等待消息复制完毕)。延迟时间可以通过参数 replica.lag.time.max.ms 参数配置,它指定了副本在复制消息时可被允许的最大延迟时间。