Kafka相关面试题详解

墨蓝 2023-02-19 14:29 33阅读 0赞

### 文章目录 ###

*   *  面试题列表
     *  1.突发宕机，Kafka写入的数据如何保证不丢失？
     *   *  Kafka 分布式存储架构
         *  Kafka 高可用架构
         *  Kafka 写入数据丢失问题
         *  Kafka 的 ISR 机制是什么?
         *  Kafka 写入的数据如何保证不丢失?
         *  总结
     *  2.Kafka如何实现每秒上百万的超高并发写入？
     *   *  页缓存技术 + 磁盘顺序写
         *  零拷贝技术
         *  总结
     *  3.Kafka中的ISR(InSyncRepli)、OSR(OutSyncRepli)、AR(AllRepli)等分别代表什么？
     *  4. Kafka中的HW、LEO、LSO、LW等分别代表什么？
     *  5. Kafka的用途有哪些？使用场景如何？
     *  6.Kafka中是怎么体现消息顺序性的？
     *  7. Kafka中的分区器、序列化器、拦截器是否了解？它们之间的处理顺序是什么？
     *  8.Kafka生产者客户端的整体结构是什么样子的？使用了几个线程来处理？分别是什么？
     *  9.“消费组中的消费者个数如果超过topic的分区，那么就会有消费者消费不到数据”这句话是否正确？
     *  10.消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1?
     *  11.有哪些情形会造成重复消费？（重点）
     *  12.哪些情景会造成消息漏消费？（重点）
     *  13.当你使用kafka-topics.sh创建（删除）了一个topic之后，Kafka背后会执行什么逻辑？
     *  14.topic的分区数可不可以增加？如果可以怎么增加？如果不可以，那又是为什么？
     *  15.topic的分区数可不可以减少？如果可以怎么减少？如果不可以，那又是为什么？
     *  16.Kafka有内部的topic吗？如果有是什么？有什么所用？
     *  17.Kafka分区分配的概念？
     *  18.简述Kafka的日志目录结构？
     *  19.如果我指定了一个offset，Kafka Controller怎么查找到对应的消息？
     *  20. 聊一聊Kafka Controller的作用？
     *  21. Kafka中有那些地方需要选举？这些地方的选举策略又有哪些？
     *  22. 失效副本是指什么？有那些应对措施？
     *  23.Kafka的那些设计让它有如此高的性能？
     *  24.Kafka消息数据积压，Kafka消费能力不足怎么处理？
     *  25.Kafka中数据量计算
     *  26. Kafka的ISR副本同步队列
     *  27.Kafka丢不丢数据
     *  28.多少个Topic
     *  29.Kakfa分区数
     *  30.Kafka监控
     *  31. Kafka的硬盘大小
     *  32.Kafka的日志保存时间
     *  33.Kafka的机器数量
     *  34.Kafka压测

## 面试题列表 ##

Kafka的用途有哪些？使用场景如何？  
Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么  
Kafka中的HW、LEO、LSO、LW等分别代表什么？  
Kafka中是怎么体现消息顺序性的？  
Kafka中的分区器、序列化器、拦截器是否了解？它们之间的处理顺序是什么？  
Kafka生产者客户端的整体结构是什么样子的？  
Kafka生产者客户端中使用了几个线程来处理？分别是什么？  
Kafka的旧版Scala的消费者客户端的设计有什么缺陷？  
“消费组中的消费者个数如果超过topic的分区，那么就会有消费者消费不到数据”这句话是否正确？如果正确，那么有没有什么hack的手段？  
消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1?  
有哪些情形会造成重复消费？  
那些情景下会造成消息漏消费？  
KafkaConsumer是非线程安全的，那么怎么样实现多线程消费？  
简述消费者与消费组之间的关系  
当你使用kafka-topics.sh创建（删除）了一个topic之后，Kafka背后会执行什么逻辑？  
topic的分区数可不可以增加？如果可以怎么增加？如果不可以，那又是为什么？  
topic的分区数可不可以减少？如果可以怎么减少？如果不可以，那又是为什么？  
创建topic时如何选择合适的分区数？  
Kafka目前有那些内部topic，它们都有什么特征？各自的作用又是什么？  
优先副本是什么？它有什么特殊的作用？  
Kafka有哪几处地方有分区分配的概念？简述大致的过程及原理  
简述Kafka的日志目录结构  
Kafka中有那些索引文件？  
如果我指定了一个offset，Kafka怎么查找到对应的消息？  
如果我指定了一个timestamp，Kafka怎么查找到对应的消息？  
聊一聊你对Kafka的Log Retention的理解  
聊一聊你对Kafka的Log Compaction的理解  
聊一聊你对Kafka底层存储的理解（页缓存、内核层、块层、设备层）  
聊一聊Kafka的延时操作的原理  
聊一聊Kafka控制器的作用  
消费再均衡的原理是什么？（提示：消费者协调器和消费组协调器）  
Kafka中的幂等是怎么实现的  
Kafka中的事务是怎么实现的（这题我去面试6加被问4次，照着答案念也要念十几分钟，面试官简直凑不要脸）  
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生态的理解

## 1.突发宕机，Kafka写入的数据如何保证不丢失？ ##

原文地址：http://developer.51cto.com/art/201903/593232.htm

这篇给大家聊下写入 Kafka 的数据该如何保证其不丢失?

我们暂且不考虑写磁盘的具体过程，先大致看看下面的图，这代表了 Kafka 的核心架构原理。

![20200621105823311.png][]

### Kafka 分布式存储架构 ###

那么现在问题来了，如果每天产生几十 TB 的数据，难道都写一台机器的磁盘上吗?这明显是不靠谱的啊!

所以说，这里就得考虑数据的分布式存储了，我们结合 Kafka 的具体情况来说说。

在 Kafka 里面，有一个核心的概念叫做“Topic”，这个 Topic 你就姑且认为是一个数据集合吧。

举个例子，如果你现在有一份网站的用户行为数据要写入 Kafka，你可以搞一个 Topic 叫做“user\_access\_log\_topic”，这里写入的都是用户行为数据。

然后如果你要把电商网站的订单数据的增删改变更记录写 Kafka，那可以搞一个 Topic 叫做“order\_tb\_topic”，这里写入的都是订单表的变更记录。

然后假如说咱们举个例子，就说这个用户行为 Topic 吧，里面如果每天写入几十 TB 的数据，你觉得都放一台机器上靠谱吗?

明显不太靠谱，所以 Kafka 有一个概念叫做 Partition，就是把一个 Topic 数据集合拆分为多个数据分区，你可以认为是多个数据分片，每个 Partition 可以在不同的机器上，储存部分数据。

这样，不就可以把一个超大的数据集合分布式存储在多台机器上了吗?大家看下图，一起来体会一下。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70][]

### Kafka 高可用架构 ###

但是这个时候，我们又会遇到一个问题，就是万一某台机器宕机了，这台机器上的那个 Partition 管理的数据不就丢失了吗?

所以说，我们还得做多副本冗余，每个 Partition 都可以搞一个副本放在别的机器上，这样某台机器宕机，只不过是 Partition 其中一个副本丢失。

如果某个 Partition 有多副本的话，Kafka 会选举其中一个 Parititon 副本作为 Leader，然后其他的 Partition 副本是 Follower。

只有 Leader Partition 是对外提供读写操作的，Follower Partition 就是从 Leader Partition 同步数据。

一旦 Leader Partition 宕机了，就会选举其他的 Follower Partition 作为新的 Leader Partition 对外提供读写服务，这不就实现了高可用架构了?

大家看下面的图，看看这个过程：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 1][]

### Kafka 写入数据丢失问题 ###

现在我们来看看，什么情况下 Kafka 中写入数据会丢失呢?其实也很简单，大家都知道写入数据都是往某个 Partition 的 Leader 写入的，然后那个 Partition 的 Follower 会从 Leader 同步数据。

但是万一 1 条数据刚写入 Leader Partition，还没来得及同步给 Follower，此时 Leader Partiton 所在机器突然就宕机了呢?

大家看下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 2][]

如上图，这个时候有一条数据是没同步到 Partition0 的 Follower 上去的，然后 Partition0 的 Leader 所在机器宕机了。

此时就会选举 Partition0 的 Follower 作为新的 Leader 对外提供服务，然后用户是不是就读不到刚才写入的那条数据了?

因为 Partition0 的 Follower 上是没有同步到的一条数据的。这个时候就会造成数据丢失的问题。

### Kafka 的 ISR 机制是什么? ###

现在我们先留着这个问题不说具体怎么解决，先回过头来看一个 Kafka 的核心机制，就是 ISR 机制。

这个机制简单来说，就是会自动给每个 Partition 维护一个 ISR 列表，这个列表里一定会有 Leader，然后还会包含跟 Leader 保持同步的 Follower。

也就是说，只要 Leader 的某个 Follower 一直跟他保持数据同步，那么就会存在于 ISR 列表里。

但是如果 Follower 因为自身发生一些问题，导致不能及时的从 Leader 同步数据过去，那么这个 Follower 就会被认为是“out-of-sync”，被从 ISR 列表里踢出去。

所以大家先得明白这个 ISR 是什么，说白了，就是 Kafka 自动维护和监控哪些 Follower 及时的跟上了 Leader 的数据同步。

### Kafka 写入的数据如何保证不丢失? ###

所以如果要让写入 Kafka 的数据不丢失，你需要保证如下几点：

*  每个 Partition 都至少得有 1 个 Follower 在 ISR 列表里，跟上了 Leader 的数据同步。
 *  每次写入数据的时候，都要求至少写入 Partition Leader 成功，同时还有至少一个 ISR 里的 Follower 也写入成功，才算这个写入是成功了。
 *  如果不满足上述两个条件，那就一直写入失败，让生产系统不停的尝试重试，直到满足上述两个条件，然后才能认为写入成功。
 *  按照上述思路去配置相应的参数，才能保证写入 Kafka 的数据不会丢失。

好!现在咱们来分析一下上面几点要求。

第一条，必须要求至少一个 Follower 在 ISR 列表里。

那必须的啊，要是 Leader 没有 Follower 了，或者是 Follower 都没法及时同步 Leader 数据，那么这个事儿肯定就没法弄下去了。

第二条，每次写入数据的时候，要求 Leader 写入成功以外，至少一个 ISR 里的 Follower 也写成功。

大家看下面的图，这个要求就是保证说，每次写数据，必须是 Leader 和 Follower 都写成功了，才能算是写成功，保证一条数据必须有两个以上的副本。

这个时候万一 Leader 宕机，就可以切换到那个 Follower 上去，那么 Follower 上是有刚写入的数据的，此时数据就不会丢失了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 3][]

如上图所示，假如现在 Leader 没有 Follower 了，或者是刚写入 Leader，Leader 立马就宕机，还没来得及同步给 Follower。

在这种情况下，写入就会失败，然后你就让生产者不停的重试，直到 Kafka 恢复正常满足上述条件，才能继续写入。这样就可以让写入 Kafka 的数据不丢失。

### 总结 ###

总结一下，其实 Kafka 的数据丢失问题，涉及到方方面面。

譬如生产端的缓存问题，包括消费端的问题，同时 Kafka 自己内部的底层算法和机制也可能导致数据丢失。

但是平时写入数据遇到比较大的一个问题，就是 Leader 切换时可能导致数据丢失。所以本文仅仅是针对这个问题说了一下生产环境解决这个问题的方案。

## 2.Kafka如何实现每秒上百万的超高并发写入？ ##

http://developer.51cto.com/art/201903/592916.htm

这篇文章来聊一下 Kafka 的一些架构设计原理，这也是互联网公司面试时非常高频的技术考点。

Kafka 是高吞吐低延迟的高并发、高性能的消息中间件，在大数据领域有极为广泛的运用。配置良好的 Kafka 集群甚至可以做到每秒几十万、上百万的超高并发写入。

那么 Kafka 到底是如何做到这么高的吞吐量和性能的呢?这篇文章我们来详细说一下。

### 页缓存技术 + 磁盘顺序写 ###

首先 Kafka 每次接收到数据都会往磁盘上去写，如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 4][]

那么在这里我们不禁有一个疑问了，如果把数据基于磁盘来存储，频繁的往磁盘文件里写数据，这个性能会不会很差?大家肯定都觉得磁盘写性能是极差的。

没错，要是真的跟上面那个图那么简单的话，那确实这个性能是比较差的。

但是实际上 Kafka 在这里有极为优秀和出色的设计，就是为了保证数据写入性能，首先 Kafka 是基于操作系统的页缓存来实现文件写入的。

操作系统本身有一层缓存，叫做 Page Cache，是在内存里的缓存，我们也可以称之为 OS Cache，意思就是操作系统自己管理的缓存。

你在写入磁盘文件的时候，可以直接写入这个 OS Cache 里，也就是仅仅写入内存中，接下来由操作系统自己决定什么时候把 OS Cache 里的数据真的刷入磁盘文件中。

仅仅这一个步骤，就可以将磁盘文件写性能提升很多了，因为其实这里相当于是在写内存，不是在写磁盘，大家看下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 5][]

接着另外一个就是 kafka 写数据的时候，非常关键的一点，它是以**磁盘顺序写**的方式来写的。

也就是说，仅仅将数据追加到文件的末尾，不是在文件的随机位置来修改数据。

普通的机械磁盘如果你要是随机写的话，确实性能极差，也就是随便找到文件的某个位置来写数据。

但是如果你是追加文件末尾按照顺序的方式来写数据的话，那么这种磁盘顺序写的性能基本上可以跟写内存的性能本身也是差不多的。

所以大家就知道了，上面那个图里，Kafka 在写数据的时候，一方面基于 OS 层面的 Page Cache 来写数据，所以性能很高，本质就是在写内存罢了。

另外一个，它是采用磁盘顺序写的方式，所以即使数据刷入磁盘的时候，性能也是极高的，也跟写内存是差不多的。

基于上面两点，Kafka 就实现了写入数据的超高性能。那么大家想想，假如说 Kafka 写入一条数据要耗费 1 毫秒的时间，那么是不是每秒就是可以写入 1000 条数据?

但是假如 Kafka 的性能极高，写入一条数据仅仅耗费 0.01 毫秒呢?那么每秒是不是就可以写入 10 万条数据?

所以要保证每秒写入几万甚至几十万条数据的核心点，就是尽可能提升每条数据写入的性能，这样就可以在单位时间内写入更多的数据量，提升吞吐量。

### 零拷贝技术 ###

说完了写入这块，再来谈谈消费这块。

大家应该都知道，从 Kafka 里我们经常要消费数据，那么消费的时候实际上就是要从 Kafka 的磁盘文件里读取某条数据然后发送给下游的消费者，如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 6][]

那么这里如果频繁的从磁盘读数据然后发给消费者，性能瓶颈在哪里呢?

假设要是 Kafka 什么优化都不做，就是很简单的从磁盘读数据发送给下游的消费者，那么大概过程如下所示：

*  先看看要读的数据在不在 OS Cache 里，如果不在的话就从磁盘文件里读取数据后放入 OS Cache。
 *  接着从操作系统的 OS Cache 里拷贝数据到应用程序进程的缓存里，再从应用程序进程的缓存里拷贝数据到操作系统层面的 Socket 缓存里。
 *  \*\*\*从 Socket 缓存里提取数据后发送到网卡，\*\*\*发送出去给下游消费。

整个过程，如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 7][]

大家看上图，很明显可以看到有两次没必要的拷贝吧!一次是从操作系统的 Cache 里拷贝到应用进程的缓存里，接着又从应用程序缓存里拷贝回操作系统的 Socket 缓存里。

而且为了进行这两次拷贝，中间还发生了好几次上下文切换，一会儿是应用程序在执行，一会儿上下文切换到操作系统来执行。

所以这种方式来读取数据是比较消耗性能的。Kafka 为了解决这个问题，在读数据的时候是引入零拷贝技术。

也就是说，直接让操作系统的 Cache 中的数据发送到网卡后传输给下游的消费者，中间跳过了两次拷贝数据的步骤，Socket 缓存中仅仅会拷贝一个描述符过去，不会拷贝数据到 Socket 缓存。

大家看下图，体会一下这个精妙的过程：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 8][]

通过零拷贝技术，就不需要把 OS Cache 里的数据拷贝到应用缓存，再从应用缓存拷贝到 Socket 缓存了，两次拷贝都省略了，所以叫做零拷贝。

对 Socket 缓存仅仅就是拷贝数据的描述符过去，然后数据就直接从 OS Cache 中发送到网卡上去了，这个过程大大的提升了数据消费时读取文件数据的性能。

而且大家会注意到，在从磁盘读数据的时候，会先看看 OS Cache 内存中是否有，如果有的话，其实读数据都是直接读内存的。

如果 Kafka 集群经过良好的调优，大家会发现大量的数据都是直接写入 OS Cache 中，然后读数据的时候也是从 OS Cache 中读。

相当于是 Kafka 完全基于内存提供数据的写和读了，所以这个整体性能会极其的高。

### 总结 ###

通过这篇文章对 Kafka 底层的页缓存技术的使用，磁盘顺序写的思路，以及零拷贝技术的运用，大家应该就明白 Kafka 每台机器在底层对数据进行写和读的时候采取的是什么样的思路，为什么它的性能可以那么高，做到每秒几十万的吞吐量。

这种设计思想对我们平时自己设计中间件的架构，或者是出去面试的时候，都有很大的帮助。

## 3.Kafka中的ISR(InSyncRepli)、OSR(OutSyncRepli)、AR(AllRepli)等分别代表什么？ ##

*  **ISR(In-Sync Replicas )**：与leader保持同步的follower集合
 *  **AR(Assigned Replicas)**：分区的所有副本

ISR是由leader维护，follower从leader同步数据有一些延迟（包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR，存入OSR（Outof-Sync Replicas）列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

## 4. Kafka中的HW、LEO、LSO、LW等分别代表什么？ ##

*  **LEO(LogEndOffset)**： 标识当前日志文件下一条待写入的 offset
 *  **HW(High Watermark)**：一个分区中所有副本最小的offset,取一个partition对应的ISR中最小的LEO作为HW，consumer最多只能消费到HW所在的位置上一条信息。

> HW/LEO这两个都是指**最后一条的下一条的位置而不是指最后一条的位置。**

*  **LSO(Last Stable Offset)**: 对未完成的事务而言，LSO 的值等于事务中第一条消息的位置(firstUnstableOffset)，对已完成的事务而言，它的值同 HW 相同
 *  **LW(Low Watermark)**: 低水位, 代表 AR 集合中最小的 logStartOffset 值

## 5. Kafka的用途有哪些？使用场景如何？ ##

总结下来就几个字:异步处理、日常系统解耦、削峰、提速、广播

如果再说具体一点例如:消息,网站活动追踪,监测指标,日志聚合,流处理,事件采集,提交日志等

## 6.Kafka中是怎么体现消息顺序性的？ ##

每个分区内，每条消息都有一个offset，故只能保证分区内有序。

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

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

## 7. Kafka中的分区器、序列化器、拦截器是否了解？它们之间的处理顺序是什么？ ##

> 见Producer API小节

*  **分区器**:根据键值确定消息应该处于哪个分区中，默认情况下使用轮询分区，可以自行实现分区器接口自定义分区逻辑
 *  **序列化器**:键序列化器和值序列化器，将键和值都转为二进制流 还有反序列化器 将二进制流转为指定类型数据
 *  **拦截器**:两个方法 doSend()方法会在序列化之前完成 onAcknowledgement()方法在消息确认或失败时调用可以添加多个拦截器按顺序执行

调用顺序: 拦截器doSend() -> 序列化器 -> 分区器

## 8.Kafka生产者客户端的整体结构是什么样子的？使用了几个线程来处理？分别是什么？ ##

2个线程，主线程和Sender线程。

*  **主线程**：负责创建消息，然后通过分区器、序列化器、拦截器作用之后缓存到累加器`RecordAccumulator`中。
 *  **Sender线程**：负责将`RecordAccumulator`中消息发送到kafka中.

![\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5o8breiA-1592708210034)(img/1568260833757.png)\]][img-5o8breiA-1592708210034_img_1568260833757.png]

## 9.“消费组中的消费者个数如果超过topic的分区，那么就会有消费者消费不到数据”这句话是否正确？ ##

正确,因为一个分区只能被同一个消费组中的一个消费者消费，如果消费者组中消费者个数超过分区数，那么肯定有一个没有办法消费到数据

## 10.消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1? ##

offset+1

## 11.有哪些情形会造成重复消费？（重点） ##

> 见4.2.2和3.3.3小节详解

两种情况可能出现重复消费

1.  当ack=-1时，如果在follower同步完成后，broker发送ack之前，leader发生故障，导致没有返回ack给Producer，由于失败重试机制，又会给新选举出来的leader发送数据，造成**数据重复**。
2.  （手动管理offset时，先消费后提交offset）消费者消费后没有commit offset(程序崩溃/强行kill/消费耗时/自动提交偏移情况下unscrible)

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 9][]

## 12.哪些情景会造成消息漏消费？（重点） ##

> 见4.2.2和3.3.3小节详解

1.  （**手动管理offset时，先提交offset后消费**）先提交offset，后消费，有可能造成数据的重复
    
    如果先提交offset，后消费，可能会出现数据漏消费问题。比如，要消费0,1,2,我先提交offset ，此时`__consumer_offsets`的值为4，但等我提交完offset之后，还没有消费之前，消费者挂掉了，这时等消费者重新活过来后，读取的`__consumer_offsets`值为4，就会从4开始消费，导致消息0,1,2出现漏消费问题。
2.  当**ack=0**时，producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能**丢失数据**；
3.  当**ack=1**时，producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，而由于已经返回了ack，系统默认新选举的leader已经有了数据，从而不会进行失败重试，那么将会**丢失数据**

## 13.当你使用kafka-topics.sh创建（删除）了一个topic之后，Kafka背后会执行什么逻辑？ ##

1.  会在zookeeper中的/brokers/topics节点下创建一个新的topic节点，如：/brokers/topics/first
2.  触发Kafka Controller的监听程序
3.  kafka Controller 负责topic的创建工作，并更新metadata cache

## 14.topic的分区数可不可以增加？如果可以怎么增加？如果不可以，那又是为什么？ ##

可以增加，可以通过以下命令增加，也可以通过Kafka Manager等图形化管理工具进行分区的添加

bin/kafka-topics.sh --zookeeper localhost:2181/kafka --alter --topic topic-config --partitions 3

## 15.topic的分区数可不可以减少？如果可以怎么减少？如果不可以，那又是为什么？ ##

不可以减少，被删除的分区数据难以处理

## 16.Kafka有内部的topic吗？如果有是什么？有什么所用？ ##

\_\_consumer\_offsets 以双下划线开头，保存消费组的偏移量

## 17.Kafka分区分配的概念？ ##

> 见3.5.2小节

一个topic多个分区，一个消费者组多个消费者，故需要将分区分配个消费者(roundrobin、range)

在 Kafka内部存在两种默认的分区分配策略：Range和 RoundRobin，最新还有sticky。

**Range**是默认策略。Range是对每个Topic而言的（即一个Topic一个Topic分），首先对同一个Topic里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。然后用Partitions分区的个数除以消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。

例如：我们有10个分区，两个消费者（C1，C2），3个消费者线程，10 / 3 = 3而且除不尽。

C1-0 将消费 0, 1, 2, 3 分区

C2-0 将消费 4, 5, 6 分区

C2-1 将消费 7, 8, 9 分区

**RoundRobin**：前提：同一个Consumer Group里面的所有消费者的num.streams（消费者消费线程数）必须相等；每个消费者订阅的主题必须相同。

第一步：将所有主题分区组成TopicAndPartition列表，然后对TopicAndPartition列表按照hashCode进行排序，最后按照轮询的方式发给每一个消费线程。

## 18.简述Kafka的日志目录结构？ ##

每个分区对应一个文件夹，文件夹的命名为topic-0，topic-1，内部为.log和.index文件

每个partition一个文件夹，包含四类文件

*  .index
 *  .log
 *  .timeindex
 *  leader-epoch-checkpoint

.index .log .timeindex 三个文件成对出现 前缀为上一个segment的最后一个消息的偏移 log文件中保存了所有的消息 index文件中保存了稀疏的相对偏移的索引 timeindex保存的则是时间索引

leader-epoch-checkpoint中保存了每一任leader开始写入消息时的offset 会定时更新,follower被选为leader时会根据这个确定哪些消息可用

## 19.如果我指定了一个offset，Kafka Controller怎么查找到对应的消息？ ##

1.  先**二分查找**获取对应index索引文件，获取到对应的物理offset
2.  拿着物理offset去log数据文件**顺序查找**对应消息
3.  返回查找到的消息

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 10][]

## 20. 聊一聊Kafka Controller的作用？ ##

> https://blog.csdn.net/u013256816/article/details/80865540

负责管理集群broker的上下线，所有topic的分区副本分配和leader选举等工作

在Kafka集群中会有一个或者多个broker，其中有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态。当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责分区的重新分配。

## 21. Kafka中有那些地方需要选举？这些地方的选举策略又有哪些？ ##

partition leader（ISR）

kafka controller（先到先得）

当broker启动时，会尝试会去创建/controller节点，创建成功即成为controller。如果该controller死亡，/controller节点会释放，由新的broker创建此节点成为新的controller

## 22. 失效副本是指什么？有那些应对措施？ ##

不能及时与leader同步，暂时踢出ISR，等其追上leader之后再重新加入

ISR是由leader维护，follower从leader同步数据有一些延迟（包括**延迟时间**replica.lag.time.max.ms和**延迟条数**replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度），任意一个超过阈值都会把follower剔除出ISR, 存入\*\*OSR（Outof-Sync Replicas）\*\*列表，新加入的follower也会先存放在OSR中。AR=ISR+OSR。

osr中的副本，如果与leader通信后，会尝试与leader同步，同步的策略是首先将当前记录的hw之后的消息删除，然后与leader同步，当与leader基本同步之后（存储的消息的offset大于当前isr中的hw），就重新回到isr之中

## 23.Kafka的那些设计让它有如此高的性能？ ##

分区，顺序写磁盘，0-copy

## 24.Kafka消息数据积压，Kafka消费能力不足怎么处理？ ##

1.  如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）
2.  如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。

## 25.Kafka中数据量计算 ##

每天总数据量100g，每天产生1亿条日志， 10000万/24/60/60=1150条/每秒钟

平均每秒钟：1150条

低谷每秒钟：400条

高峰每秒钟：1150条\*（2-20倍）=2300条-23000条

每条日志大小：0.5k-2k

每秒多少数据量：2.3M-20MB

## 26. Kafka的ISR副本同步队列 ##

ISR（In-Sync Replicas），副本同步队列。ISR中包括Leader和Follower。如果Leader进程挂掉，会在ISR队列中选择一个服务作为新的Leader。有replica.lag.max.messages（延迟条数）和replica.lag.time.max.ms（延迟时间）两个参数决定一台服务是否可以加入ISR副本队列，在0.10版本移除了replica.lag.max.messages参数，防止服务频繁的进去队列。

任意一个维度超过阈值都会把Follower剔除出ISR，存入OSR（Outof-Sync Replicas）列表，新加入的Follower也会先存放在OSR中。

## 27.Kafka丢不丢数据 ##

Ack=0，相当于异步发送，消息发送完毕即offset增加，继续生产。

Ack=1，leader收到leader replica 对一个消息的接受ack才增加offset，然后继续生产。

Ack=-1，leader收到所有replica 对一个消息的接受ack才增加offset，然后继续生产。

## 28.多少个Topic ##

通常情况：多少个日志类型就多少个Topic。也有对日志类型进行合并的。

## 29.Kakfa分区数 ##

分区数并不是越多越好，一般分区数不要超过集群机器数量。分区数越多占用内存越大（ISR等），一个节点集中的分区也就越多，当它宕机的时候，对系统的影响也就越大。

分区数一般设置为：3-10

## 30.Kafka监控 ##

公司自己开发的监控器；

开源的监控器：KafkaManager,KafkaMonitor,Kafka Eagle

## 31. Kafka的硬盘大小 ##

每天的数据量\*7天

## 32.Kafka的日志保存时间 ##

7天

## 33.Kafka的机器数量 ##

Kafka机器数量=2\*（峰值生产速度\*副本数/100）+1

## 34.Kafka压测 ##

Kafka官方自带压力测试脚本（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）。Kafka压测时，可以查看到哪个地方出现了瓶颈（CPU，内存，网络IO）。一般都是网络IO达到瓶颈。

[20200621105823311.png]: https://img-blog.csdnimg.cn/20200621105823311.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200621105832535.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200621105842710.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200621105852443.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/2020062110593749.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200621110027873.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20200621110036806.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20200621110048692.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20200621110058478.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 8]: https://img-blog.csdnimg.cn/20200621110113296.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70
[img-5o8breiA-1592708210034_img_1568260833757.png]: https://img-blog.csdnimg.cn/2020062111013838.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 9]: https://img-blog.csdnimg.cn/20200621110153547.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1_size_16_color_FFFFFF_t_70 10]: https://img-blog.csdnimg.cn/20200621110213987.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI2ODM4MzE1,size_16,color_FFFFFF,t_70