kafka常见⾯试题⼤全含答案（上）
1 什么是kaf ka
Kafka是分布式发布-订阅消息系统，它最初是由LinkedIn公司开发的，之后成为Apache项⽬的⼀部分，Kafka是⼀个分布式，可划分的，冗余备份的持久性的⽇志服务，它主要⽤于处理流式数据。
2 为什么要使⽤ kaf ka，为什么要使⽤消息队列
缓冲和削峰：上游数据时有突发流量，下游可能扛不住，或者下游没有⾜够多的机器来保证冗余，kafka在中间可以起到⼀个缓冲的作⽤，把消息暂存在kafka中，下游服务就可以按照⾃⼰的节奏进⾏慢慢处理。
解耦和扩展性：项⽬开始的时候，并不能确定具体需求。消息队列可以作为⼀个接⼝层，解耦重要的业务流程。只需要遵守约定，针对数据编程即可获取扩展能⼒。
冗余：可以采⽤⼀对多的⽅式，⼀个⽣产者发布消息，可以被多个订阅topic的服务消费到，供多个毫⽆关联的业务使⽤。
健壮性：消息队列可以堆积请求，所以消费端业务即使短时间死掉，也不会影响主要业务的正常进⾏。
异步通信：很多时候，⽤户不想也不需要⽴即处理消息。消息队列提供了异步处理机制，允许⽤户把⼀个消息放⼊队列，但并不⽴即处理它。想向队列中放⼊多少消息就放多少，然后在需要的时候再去处理它们。
3.K af ka中的I SR、A R⼜代表什么？I SR的伸缩⼜指什么
ISR:In-Sync Replicas 副本同步队列
AR:Assigned Replicas 所有副本
ISR是由leader维护，follower从leader同步数据有⼀些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.ssages两个维度, 当前最新的版本0.10.x中只⽀持replica.lag.time.max.ms这个维度），任意⼀个超过阈值都会把follower剔除出ISR, 存⼊OSR（Outof-Sync Replicas）列表，新加⼊的follower也会先存放在OSR中。AR=ISR+OSR。
4.kaf ka中的b r oke r 是⼲什么的
broker 是消息的代理，Producers往Brokers⾥⾯的指定Topic中写消息，Consumers从Brokers⾥⾯拉取指定Topic的消息，然后进⾏业务处理，broker在中间起到⼀个代理保存消息的中转站。
5.kaf ka中的 zooke e p e r 起到什么作⽤，可以不⽤zooke e p e r么
zookeeper 是⼀个分布式的协调组件，早期版本的kafka⽤zk做meta信息存储，consumer的消费状态，group的管理以及 offt的值。考虑到zk本⾝的⼀些因素以及整个架构较⼤概率存在单点问题，新版本中逐渐弱化了zookeeper的作⽤。新的consumer使⽤了kafka内部的group coordination协议，也减少了对zookeeper的依赖，
但是broker依然依赖于ZK，zookeeper 在kafka中还⽤来选举controller 和 检测broker是否存活等等。
6.kaf ka f ollowe r如何与le ad e r同步数据
Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制⽅式极⼤的影响了吞吐率。⽽异步复制⽅式下，Follower异步的从Leader复制数据，数据只要被Leader写⼊log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据，kafka使⽤ISR的⽅式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，⽽且Leader充分利⽤磁盘顺序读以及nd file(zero copy)机制，这样极⼤的提⾼复制性能，内部批量写磁盘，⼤幅减少了Follower与Leader的消息量差。
7.什么情况下⼀个 b r oke r 会从 is r中踢出去
leader会维护⼀个与其基本保持同步的Replica列表，该列表称为ISR(in-sync Replica)，每个Partition
都会有⼀个ISR，⽽且是由leader动态维护 ，如果⼀个follower⽐⼀个leader落后太多，或者超过⼀定时间未发起数据复制请求，则leader将其重ISR中移除 。
8.kaf ka 为什么那么快
Cache Filesystem Cache PageCache缓存
顺序写 由于现代的操作系统提供了预读和写技术，磁盘的顺序写⼤多数情况下⽐随机写内存还要快。
Zero-copy 零拷技术减少拷贝次数
Batching of Messages 批量量处理。合并⼩的请求，然后以流的⽅式进⾏交互，直顶⽹络上限。
Pull 拉模式 使⽤拉模式进⾏消息的获取消费，与消费端处理能⼒相符。
9.kaf ka p r od uce r如何优化打⼊速度
增加线程
提⾼ batch.size
增加更多 producer 实例
增加 partition 数
设置 acks=-1 时，如果延迟增⼤：可以增⼤ plica.fetchers（follower 同步数据的线程数）来调解；
跨数据中⼼的传输：增加 socket 缓冲区设置以及 OS tcp 缓冲区设置。
10.kaf ka p r od uce r 打数据，ack 为 0， 1， -1 的时候代表啥， 设置 -1 的时候，什么情况下，le ad e r 会认为⼀条消息 com m it了
1（默认） 数据发送到Kafka后，经过leader成功接收消息的的确认，就算是发送成功了。在这种情况下，如果leader宕机了，则会丢失数据。
0 ⽣产者将数据发送出去就不管了，不去等待任何返回。这种情况下数据传输效率最⾼，但是数据可靠性确是最低的。
-1 producer需要等待ISR中的所有follower都确认接收到数据后才算⼀次发送完成，可靠性最⾼。当ISR中所有Replica都向Leader发送ACK 时，leader才commit，这时候producer才能认为⼀个请求中的消息都commit了。
11.kaf ka uncle an 配置代表啥，会对 s p ar k s tr e am ing 消费有什么影响
unclean.able 为true的话，意味着⾮ISR集合的broker 也可以参与选举，这样有可能就会丢数据，spark streaming在消费过程中拿到的 end offt 会突然变⼩，导致 spark streaming job挂掉。如果unclean.able参数设置为true，就有可能发⽣数据丢失和数据不⼀致的情况，Kafka的可靠性就会降低；⽽如果unclean.able参数设置为fal，Kafka的可⽤性就会降低。
12.如果le ad e r cr as h时，I SR为空怎么办
kafka在Broker端提供了⼀个配置参数：unclean.leader.election，这个参数有两个值：
true（默认）：允许不同步副本成为leader，由于不同步副本的消息较为滞后，此时成为leader，可能会出现消息不⼀致的情况。
fal：不允许不同步副本成为leader，此时如果发⽣ISR列表为空，会⼀直等待旧leader恢复，降低了可⽤性。
13.kaf ka的m e s s ag e格式是什么样的
⼀个Kafka的Message由⼀个固定长度的header和⼀个变长的消息体body组成
header部分由⼀个字节的magic(⽂件格式)和四个字节的CRC32(⽤于判断body消息体是否正常)构成。
当magic的值为1的时候，会在magic和crc32之间多⼀个字节的数据：attributes(保存⼀些相关属性，
⽐如是否压缩、压缩格式等等)；如果magic的值为0，那么不存在attributes属性
body是由N个字节构成的⼀个消息体，包含了具体的key/value消息
14.kaf ka中cons um e r g r oup 是什么概念
同样是逻辑上的概念，是Kafka实现单播和⼴播两种消息模型的⼿段。同⼀个topic的数据，会⼴播给不同的group；同⼀个group中的worker，只有⼀个worker能拿到这个数据。换句话说，对于同⼀个topic，每个group都可以拿到同样的所有数据，但是数据进⼊group后只能被其中的⼀个worker消费。group内的worker可以使⽤多线程或多进程来实现，也可以将进程分散在多台机器上，worker的数量通常不超过partition的数量，且⼆者最好保持整数倍关系，因为Kafka在设计时假定了⼀个partition只能被⼀个worker消费（同⼀group内）。
15.K af ka中的消息是否会丢失和重复消费？
要确定Kafka的消息是否丢失或重复，从两个⽅⾯分析⼊⼿：消息发送和消息消费。
1、消息发送
Kafka消息发送有两种⽅式：同步（sync）和异步（async），默认是同步⽅式，可通过pe属性进⾏配置。Kafka通过配置quired.acks属性来确认消息的⽣产：
0---表⽰不进⾏消息接收是否成功的确认；
1---表⽰当Leader接收成功时确认；
-1---表⽰Leader和Follower都接收成功时确认；
综上所述，有6种消息⽣产的情况，下⾯分情况来分析消息丢失的场景：
（1）acks=0，不和Kafka集群进⾏消息接收确认，则当⽹络异常、缓冲区满了等情况时，消息可能丢失；
（2）acks=1、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；
2、消息消费
Kafka消息消费有两个consumer接⼝，Low-level API和High-level API：
Low-level API：消费者⾃⼰维护offt等值，可以实现对Kafka的完全控制；
High-level API：封装了对parition和offt的管理，使⽤简单；
如果使⽤⾼级接⼝High-level API，可能存在⼀个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offt值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就“诡异”的消失了；
解决办法：
针对消息丢失：同步模式下，确认机制设置为-1，即让消息写⼊Leader和Follower之后再确认消息发送成功；异步模式下，为防⽌缓冲区满，可以在配置⽂件设置不限制阻塞超时时间，当缓冲区满时让⽣产者⼀直处于阻塞状态；
针对消息重复：将消息的唯⼀标识保存到外部介质中，每次消费时判断是否处理过即可。
16.为什么K af ka不⽀持读写分离？
在 Kafka 中，⽣产者写⼊消息、消费者读取消息的操作都是与 leader 副本进⾏交互的，从 ⽽实现的是⼀种主写主读的⽣产消费模型。
Kafka 并不⽀持主写从读，因为主写从读有 2 个很明 显的缺点:
(1)数据⼀致性问题。数据从主节点转到从节点必然会有⼀个延时的时间窗⼝，这个时间 窗⼝会导致主从节点之间的数据不⼀致。某⼀时刻，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值修改为 Y，那么在这个变更通知到从节点之前，应⽤读取从节点中的 A 数据的值并不为最新的 Y，由此便产⽣了数据不⼀致的问题。
(2)延时问题。类似 Redis 这种组件，数据从写⼊主节点到同步⾄从节点中的过程需要经 历⽹络→主节点内存→⽹络→从节点内存这⼏个阶段，整个过程会耗费⼀定的时间。⽽在 Kafka 中，主从同步会⽐ Redis 更加耗时，它需要经历⽹络→主节点内存→主节点磁盘→⽹络→从节 点内存→从节点磁盘这⼏个阶段。对延时敏感的应⽤⽽⾔，主写从读的功能并不太适⽤。
17.K af ka中是怎么体现消息顺序性的？
kafka每个partition中的消息在写⼊时都是有序的，消费时，每个partition只能被每⼀个group中的⼀个消费者消费，保证了消费时也是有序的。
整个topic不保证有序。如果为了保证topic整个有序，那么将partition调整为1.
18.消费者提交消费位移时提交的是当前消费到的最新消息的of f s e t还是of f s e t+1?
offt+1
19.kaf ka如何实现延迟队列？
Kafka并没有使⽤JDK⾃带的Timer或者DelayQueue来实现延迟的功能，⽽是基于时间轮⾃定义了⼀个⽤于实现延迟功能的定时器（SystemTimer）。JDK的Timer和DelayQueue插⼊和删除操作的平均时间复杂度为O(nlog(n))，并不能满⾜Kafka的⾼性能要求，⽽基于时间轮可以将插⼊和删除操作的时间复杂度都降为O(1)。时间轮的应⽤并⾮Kafka独有，其应⽤场景还有很多，在Netty、Akka、Quartz、Zookeeper等组件中都存在时间轮的踪影。
底层使⽤数组实现，数组中的每个元素可以存放⼀个TimerTaskList对象。TimerTaskList是⼀个环形双向链表，在其中的链表项TimerTaskEntry中封装了真正的定时任务TimerTask.
Kafka中到底是怎么推进时间的呢？Kafka中的定时器借助了JDK中的DelayQueue来协助推进时间轮。具体做法是对于每个使⽤到的TimerTaskList都会加⼊到DelayQueue中。Kafka中的TimingWheel专门⽤来执⾏插⼊和删除TimerTaskEntry的操作，⽽DelayQueue专门负责时间推进的任务。再试想⼀下，DelayQueue中的第⼀个超时任务列表的expiration为200ms，第⼆个超时任务为840ms，这⾥获取DelayQueue的队头只需要O(1)的时间复杂度。如果采⽤每秒定时推进，那么获取到第⼀个超时的任务列表时执⾏的200次推进中有199次属
于“空推进”，⽽获取到第⼆个超时任务时有需要执⾏639次“空推进”，这样会⽆故空耗机器的性能资源，这⾥采⽤DelayQueue来辅助以少量空间换时间，从⽽做到了“精准推进”。Kafka中的定时器真可谓是“知⼈善⽤”，⽤TimingWheel做最擅长的任务添加和删除操作，⽽⽤DelayQueue做最擅长的时间推进⼯作，相辅相成。
