高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。
可扩展性：kafka集群支持热扩展
持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
高并发：支持数千个客户端同时读写

2、请简述下你在哪些场景下会选择 Kafka？

日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、HBase、Solr等。
消息系统：解耦和生产者和消费者、缓存消息等。
用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
流式处理：比如spark streaming和 Flink。

3、Kafka 的设计架构你知道吗？

32 道常见的 Kafka 面试题你都会吗？附答案

Kafka 架构分为以下几个部分：

Producer：消息生产者，就是向Kafka broker发送消息的客户端。
Consumer：消息消费者，向Kafka broker收取消息的客户段。
Topic：主题，每个消息都属于一种主题。可以理解为一个消息队列，一个Topic可以分为一个或者多个分区。
Consumer Group：这是Kafka用来实现topic消息的广播(发送给所有的consumer)和单播(发给任意一个consumer)的手段。一个topic可以被多个消费者组进行消费。但是每一个消费者组内的消费者不能消费相同topic下的相同分区。
Broker：一台Kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。
Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker上，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的id（offset）。将消息发给 consumer，kafka 只保证按一个 partition 中的消息的顺序，不保证一个 topic 的整体（多个 partition 间）的顺序。
Offset：偏移量，每一个partition对应一个log文件，并且每个文件内存在多个segment，segment当中有两类文件，一种是".index"，另一种是".log"，两种都用 offset 做名字，好处是方便查找(查找的算法是使用二分查找)。例如：first这个topic存在多个分区，则其对应的文件为first-0，first-1…index 和 log 文件以当前 segment 的第一条消息的 offset 命名。“.index” 文件存储大量的索引信息，“.log” 文件存储大量的数据，索引文件中的元数据指向对应数据文件中 message 的物理偏移量。

4、Kafka分区的目的？

1、实现负载均衡，方便在集群中扩展，每个partition可以通过调整以适应它所在的机器，而一个topic又可以有多个partition组成，因此可以以partition为单位读写了。

2、可以提高并发，因为可以以partition为单位读写了。

5、你知道 Kafka 是如何做到消息的有序性？

kafka 中的每个 partition 中的消息在写入时都是有序的，而且单独一个 partition 只能由一个消费者去消费，可以在里面保证消息的顺序性。但是分区之间的消息是不保证有序的。

6、Kafka 的高可靠性是怎么实现的？

基本上从Producer往Broker发送消息、Topic分区副本以及Leader的选举来回答。详情请看（https://blog.csdn.net/Stray_Lambs/article/details/117250197）

7、Kafka 数据一致性原理

主要通过HW机制以及ISR机制来实现，有点类似于木桶原理。

https://blog.csdn.net/Stray_Lambs/article/details/117250197

8、ISR、OSR、AR 是什么？

ISR：In-Sync Replicas 副本同步队列

OSR：Out-of-Sync Replicas

AR：Assigned Replicas 所有副本

ISR是由leader维护，follower从leader同步数据有一些延迟（具体可以参见Kafka 的副本复制机制），超过相应的阈值会把 follower 剔除出 ISR, 存入OSR（Out-of-Sync Replicas ）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

9、LEO、HW、LSO、LW等分别代表什么

LEO：是 LogEndOffset 的简称，代表当前日志文件中下一条
HW：水位或水印（watermark）一词，也可称为高水位(high watermark)，通常被用在流式处理领域（比如Apache Flink、Apache Spark等），以表征元素或事件在基于时间层面上的进度。在Kafka中，水位的概念反而与时间无关，而是与位置信息相关。严格来说，它表示的就是位置信息，即位移（offset）。取 partition 对应的 ISR中最小的 LEO 作为 HW，consumer 最多只能消费到 HW 所在的位置上一条信息。
LSO：是 LastStableOffset 的简称，对未完成的事务而言，LSO 的值等于事务中第一条消息的位置(firstUnstableOffset)，对已完成的事务而言，它的值同 HW 相同。
LW：Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值。

10、Kafka 在什么情况下会出现消息丢失？

可能producer发送的消息还没写入磁盘，而broker（leader）返回ack后，直接宕机，那么就有可能造成数据丢失。

11、怎么尽可能保证 Kafka 的可靠性？

基本上也就是问Kafka如何实现高可靠性，无非就是分区副本，ack机制的那三个值，ISR机制中leader的选举等，可以参考问题6。

12、消费者和消费者组有什么关系？

每个消费者从属于一个消费者组。组内可能只有一个消费者或者多个。

32 道常见的 Kafka 面试题你都会吗？附答案

13、Kafka 的每个分区只能被一个消费者线程，如何做到多个线程同时消费一个分区？

可以采用平衡分区算法(具体怎么样，我有点还没有领悟，这里只能弱弱的放个大佬的博客)

一个分区能同时被一个消费组的多个消费者消费。而kafka中消费者是以pull拉取数据的,一般是拉取方提供offset,数据方根据offset返回数据。如果是数据方维护offset,会增加获取offset的通信开销,consumer端维护就涉及多个消费者之间offset同步问题,增加了复杂性。好处就是实现分区的分布式消费但多个分区已经实现了主题的分布式消费,权衡下kafka选择了一个分区只能被一个消费组的一个消费者消费。

Airbnb 是如何通过 balanced Kafka reader 来扩展 Spark streaming 实时流处理能力的

14、数据传输的事务有几种？

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

最多一次: 消息不会被重复发送，最多被传输一次，但也有可能漏传
最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输
精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输一次

15、Kafka 消费者是否可以消费指定分区消息？

Kafa consumer消费消息时，向broker发出fetch请求去消费特定分区的消息，consumer指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息，customer拥有了offset的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的。

16、Kafka消息是采用Pull模式，还是Push模式？

Kafka最初考虑的问题是，customer应该从brokes拉取消息还是brokers将消息推送到consumer，也就是pull还push。在这方面，Kafka遵循了一种大部分消息系统共同的传统的设计：producer将消息推送到broker，consumer从broker拉取消息。

一些消息系统比如Scribe和Apache Flume采用了push模式，将消息推送到下游的consumer。这样做有好处也有坏处：由broker决定消息推送的速率，对于不同消费速率的consumer就不太好处理了。消息系统都致力于让consumer以最大的速率最快速的消费消息，但不幸的是，push模式下，当broker推送的速率远大于consumer消费的速率时，consumer恐怕就要崩溃了。最终Kafka还是选取了传统的pull模式。
Pull模式的另外一个好处是consumer可以自主决定是否批量的从broker拉取数据。Push模式必须在不知道下游consumer消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免consumer崩溃而采用较低的推送速率，将可能导致一次只推送较少的消息而造成浪费。Pull模式下，consumer就可以根据自己的消费能力去决定这些策略。
Pull有个缺点是，如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到t达。为了避免这点，Kafka有个参数可以让consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发）

17、Kafka 高效文件存储设计特点

Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除(默认是7天)或删除已经消费完文件，减少磁盘占用。
通过索引信息可以快速定位message和确定response的最大大小。
通过index元数据全部映射到memory，可以避免segment file的IO磁盘操作。
通过索引文件稀疏存储(稀疏存储为了避免了索引文件占用过多的空间，从而可以将索引文件保留在内存中)，每隔一定字节的数据建立一条索引，可以大幅降低index文件元数据占用空间大小。

18、Kafka创建Topic时如何将分区放置到不同的Broker中？

副本因子不能大于 Broker 的个数；
第一个分区（编号为0）的第一个副本放置位置是随机从 brokerList 选择的；
其他分区的第一个副本放置位置相对于第0个分区依次往后移。也就是如果我们有5个 Broker，5个分区，假设第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个 Broker 上，依次类推；
剩余的副本相对于第一个副本放置位置其实是由 nextReplicaShift 决定的，而这个数也是随机产生的。

详情可以看Kafka创建Topic时如何将分区放置到不同的Broker中

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

我们知道，在启动 Kafka 集群之前，我们需要配置好 log.dirs 参数，其值是 Kafka 数据的存放目录，这个参数可以配置多个目录，目录之间使用逗号分隔，通常这些目录是分布在不同的磁盘上用于提高读写性能。当然我们也可以配置 log.dir 参数，含义一样。只需要设置其中一个即可。

如果 log.dirs 参数只配置了一个目录，那么分配到各个 Broker 上的分区肯定只能在这个目录下创建文件夹用于存放数据。

但是如果 log.dirs 参数配置了多个目录，那么 Kafka 会在哪个文件夹中创建分区目录呢？答案是：Kafka 会在含有分区目录最少的文件夹中创建新的分区目录，分区目录名为 Topic名+分区ID。注意，是分区文件夹总数最少的目录，而不是磁盘使用量最少的目录！也就是说，如果你给 log.dirs 参数新增了一个新的磁盘，新的分区目录肯定是先在这个新的磁盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。

详情可以看新建分区存放在哪个目录

20、谈一谈 Kafka 的再均衡

在Kafka中，当有新消费者加入或者订阅的topic数发生变化时，会触发Rebalance(再均衡：在同一个消费者组当中，分区的所有权从一个消费者转移到另外一个消费者)机制，Rebalance顾名思义就是重新均衡消费者消费。Rebalance的过程如下：

第一步：所有成员都向coordinator节点发送请求，请求入组。一旦所有成员都发送了请求，coordinator会从中选择一个consumer担任leader的角色，并把组成员信息以及订阅信息发给leader。
第二步：leader开始分配消费方案，指明具体哪个consumer负责消费哪些topic的哪些partition。一旦完成分配，leader会将这个方案发给coordinator。coordinator接收到分配方案之后会把方案发给各个consumer，这样组内的所有成员就都知道自己应该消费哪些分区了。
所以对于Rebalance来说，Coordinator起着至关重要的作用。

21、谈谈 Kafka 分区分配策略

具体请看Kafka分区分配策略

22、Kafka Producer 是如何动态感知主题分区数变化的？

在启动Kafka Producer往Kafka的Broker发送消息的时候，用户修改了该Topic的分区数，Producer可以在最多topic.metadata.refresh.interval.ms的时间之后感知到，此感知同时适用于async和sync模式，并且可以将数据发送到新添加的分区中。下面附上topic.metadata.refresh.interval.ms参数的解释：

The producer generally refreshes the topic metadata from brokers when there is a failure (partition missing, leader not available...). It will also poll regularly (default: every 10min so 600000ms). If you set this to a negative value, metadata will only get refreshed on failure. If you set this to zero, the metadata will get refreshed after each message sent (not recommended) Important note: the refresh happen only AFTER the message is sent, so if the producer never sends a message the metadata is never refreshed.

23、 Kafka 是如何实现高吞吐率的？

Kafka是分布式消息系统，需要处理海量的消息，Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失。kafka主要使用了以下几个方式实现了超高的吞吐率：

顺序读写
零拷贝
文件分段
批量发送
数据压缩

24、如何为Kafka集群选择合适的Topics/Partitions数量？

具体请看如何为Kafka集群选择合适的Topics/Partitions数量

25、谈谈你对 Kafka 幂等的了解？

0.11版本的 Kafka，引入了幂等性：producer 不论向 server 发送多少重复数据，server 端都只会持久化一条。

要启用幂等性，只需要将 producer 的参数中 enable.idompotence 设置为 true 即可。开启幂等性的 producer 在初始化时会被分配一个 PID，发往同一 partition 的消息会附带 Sequence Number。而 borker 端会对 <PID,Partition,SeqNumber> 做缓存，若三个主键都相同则表示重复数据，否则就是不同数据，当具有相同主键的消息提交时，broker 只会持久化一条。

但是 PID 重启后就会变化，同时不同的 partition 也具有不同主键，所以幂等性无法保证跨分区会话的 Exactly Once，即可能宕机之后重新加入，则可能存在重复数据。

26、Kafka 分区数可以增加或减少吗？为什么？

我们可以使用 bin/kafka-topics.sh 命令对 Kafka 增加 Kafka 的分区数据，但是 Kafka 不支持减少分区数。
Kafka 分区数据不支持减少是由很多原因的，比如减少的分区其数据放到哪里去？是删除，还是保留？删除的话，那么这些没消费的消息不就丢了。如果保留这些消息如何放到其他分区里面？追加到其他分区后面的话那么就破坏了 Kafka 单个分区的有序性。如果要保证删除分区数据插入到其他分区保证有序性，那么实现起来逻辑就会非常复杂。

具体请看：https://blog.csdn.net/Stray_Lambs/article/details/117250197

27、阐述下 Kafka 中的领导者副本(Leader Replica)和追随者副本 (Follower Replica)的区别

这道题表面上是考核你对 Leader 和 Follower 区别的理解，但很容易引申到 Kafka 的同步机制上。因此，我建议你主动出击，一次性地把隐含的考点也答出来，也许能够暂时把面试官“唬住”，并体现你的专业性。

你可以这么回答:Kafka 副本当前分为领导者副本和追随者副本。只有 Leader 副本才能对外提供读写服务，响应 Clients 端的请求。Follower 副本只是采用拉(PULL)的方式，被动地同步 Leader 副本中的数据，并且在 Leader 副本所在的 Broker 宕机后，随时准备应聘 Leader 副本。

通常来说，回答到这个程度，其实才只说了 60%，因此，我建议你再回答两个额外的加分项。

强调 Follower 副本也能对外提供读服务。自 Kafka 2.4 版本开始，社区通过引入新的 Broker 端参数，允许 Follower 副本有限度地提供读服务。
强调 Leader 和 Follower 的消息序列在实际场景中不一致。很多原因都可能造成 Leader 和 Follower 保存的消息序列不一致，比如程序 Bug、网络问题等。这是很严重的错误，必须要完全规避。你可以补充下，之前确保一致性的主要手段是高水位机制，但高水位值无法保证 Leader 连续变更场景下的数据一致性，因此，社区引入了 Leader Epoch 机制，来修复高水位值的弊端。关于“Leader Epoch 机制”，国内的资料不是很多，它的普及度远不如高水位，不妨大胆地把这个概念秀出来，力求惊艳一把。

28、Broker 的 Heap Size 如何设置?

任何 Java 进程 JVM 堆大小的设置都需要仔细地进行考量和测试。一个常见的做法是，以默认的初始 JVM 堆大小运行程序，当系统达到稳定状态后，手动触发一次 Full GC，然后通过 JVM 工具查看 GC 后的存活对象大小。之后，将堆大小设置成存活对象总大小的 1.5~2 倍。对于 Kafka 而言，这个方法也是适用的。不过，业界有个最佳实践，那就是将 Broker 的 Heap Size 固定为 6GB。经过很多公司的验证，这个大小是足够且良好的。

29、Leader 总是 -1，怎么破?

在生产环境中，你一定碰到过“某个主题分区不能工作了”的情形。使用命令行查看状态的话，会发现 Leader 是 -1，于是，你使用各种命令都无济于事，最后只能用“重启大法”。

但是，有没有什么办法，可以不重启集群，就能解决此事呢?这就是此题的由来。

我直接给答案:删除 ZooKeeper 节点 /controller，触发 Controller 重选举。 Controller 重选举能够为所有主题分区重刷分区状态，可以有效解决因不一致导致的 Leader 不可用问题。

30、Kafka 的哪些场景中使用了零拷贝(Zero Copy)?

Zero Copy 是特别容易被问到的高阶题目。在 Kafka 中，体现 Zero Copy 使用场景的地方有两处:基于 mmap 的索引和日志文件读写所用的 TransportLayer。

先说第一个。索引都是基于 MappedByteBuffer 的，也就是让用户态和内核态共享内核态的数据缓冲区，此时，数据不需要复制到用户态空间。不过，mmap 虽然避免了不必要的拷贝，但不一定就能保证很高的性能。在不同的操作系统下，mmap 的创建和销毁成本可能是不一样的。很高的创建和销毁开销会抵消 Zero Copy 带来的性能优势。由于这种不确定性，在 Kafka 中，只有索引应用了 mmap，最核心的日志并未使用 mmap 机制。

再说第二个。TransportLayer 是 Kafka 传输层的接口。它的某个实现类使用了 FileChannel 的 transferTo 方法。该方法底层使用 sendfile 实现了 Zero Copy。对 Kafka 而言，如果 I/O 通道使用普通的 PLAINTEXT，那么，Kafka 就可以利用 Zero Copy 特性，直接将页缓存中的数据发送到网卡的 Buffer 中，避免中间的多次拷贝。相反，如果 I/O 通道启用了 SSL，那么，Kafka 便无法利用 Zero Copy 特性了。

31、简述 Follower 副本消息同步的完整流程

首先，Follower 发送 FETCH 请求给 Leader。接着，Leader 会读取底层日志文件中的消息数据，再更新它内存中的 Follower 副本的 LEO 值，更新为 FETCH 请求中的 fetchOffset 值。最后，尝试更新分区高水位值。Follower 接收到 FETCH 响应之后，会把消息写入到底层日志，接着更新 LEO 和 HW 值。

Leader 和 Follower 的 HW 值更新时机是不同的，Follower 的 HW 更新永远落后于 Leader 的 HW。这种时间上的错配是造成各种不一致的原因。

32、Kafka目前有哪些内部topic，它们都有什么特征？各自的作用又是什么？

__consumer_offsets：作用是保存 Kafka 消费者的位移信息
__transaction_state：用来存储事务日志消息

33、Kafka中的事务是怎么实现的？

太长了…… 还是放篇比较详细的博客。

https://blog.csdn.net/weixin_44723515/article/details/107583213

还有一些没有还没找答案的，现存一波题目…… 有空就去补上答案。如果答案存在问题，欢迎大佬提出来。

Kafka中有那些地方需要选举？这些地方的选举策略又有哪些？
失效副本是指什么？有那些应对措施？
多副本下，各个副本中的HW和LEO的演变过程
为什么Kafka不支持读写分离？
Kafka在可靠性方面做了哪些改进？（HW, LeaderEpoch）
Kafka中怎么实现死信队列和重试队列？
Kafka中的延迟队列怎么实现（这题被问的比事务那题还要多！！！听说你会Kafka，那你说说延迟队列怎么实现？）
Kafka中怎么做消息审计？
Kafka中怎么做消息轨迹？
Kafka中有那些配置参数比较有意思？聊一聊你的看法
Kafka中有那些命名比较有意思？聊一聊你的看法
Kafka有哪些指标需要着重关注？
怎么计算Lag？(注意read_uncommitted和read_committed状态下的不同)
Kafka的那些设计让它有如此高的性能？
Kafka有什么优缺点？
还用过什么同质类的其它产品，与Kafka相比有什么优缺点？
为什么选择Kafka?
在使用Kafka的过程中遇到过什么困难？怎么解决的？
怎么样才能确保Kafka极大程度上的可靠性？
聊一聊你对Kafka生态的理解

有空一定补上！

参考

https://www.iteblog.com/archives/category/kafka/page/2/

https://www.jianshu.com/p/511962462e58

暂时先附上这么多……

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/菜鸟追梦旅行/article/detail/679471