2024年大数据最全【大数据】Kafka高频面试题（二）_kafka能手动删除消息吗(1)，你还在把大数据开发当成大数据开发官方开发语言吗

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

1）**普通消息：**我们可以使用 Kafka-delete-records 命令或者通过程序调用 Admin.deleteRecords 方法来删除消息。两者底层都是调用 Admin 的 deleteRecords 的方法，通过将分区的 LEO 值抬高来间接删除消息。
2）**设置key且参数 cleanup.policy=delete/campact 的消息：**可以依靠 Log Cleaner 组件提供的功能删除该 Key 的消息。
**日志删除（Log Retention）：**按照一定的保留策略直接删除不符合条件的日志分段（LogSegment）。
**日志压缩（Log Compaction）：**针对每个消息的key进行整合，对于有相同key的不同value值，只保留最后一个版本。

01

日志删除

Kafka 的日志管理器（LogManager）中有一个专门的日志清理任务通过周期性检测和删除不符合条件的日志分段文件（LogSegment），这里我们可以通过设置 Kafka Broker 端的参数「** log.retention.check.interval.ms**」，默认值为300000，即5分钟。

在 Kafka 中一共有3种保留策略：

基于时间策略
日志删除任务会周期检查当前日志文件中是否有保留时间超过设定的阈值**(retentionMs) 来寻找可删除的日志段文件集合(deletableSegments)**。

其中 **retentionMs **可以通过 Kafka Broker 端的这几个参数的大小判断的
log.retention.ms > log.retention.minutes > log.retention.hours优先级来设置，默认情况只会配置 log.retention.hours 参数，值为168即为7天。
**

这里需要注意：删除过期的日志段文件，并不是简单的根据该日志段文件的修改时间计算的，而是要根据该日志段中最大的时间戳 largestTimeStamp 来计算的，首先要查询该日志分段所对应的时间戳索引文件，查找该时间戳索引文件的最后一条索引数据，如果时间戳值大于0，则取值，否则才会使用最近修改时间（lastModifiedTime）。

【删除步骤】：

1. 首先从 Log 对象所维护的日志段的跳跃表中移除要删除的日志段，用来确保已经没有线程来读取这些日志段。
2. 将日志段所对应的所有文件，包括索引文件都添加上“.deleted”的后缀。
3. 最后交给一个以“delete-file”命名的延迟任务来删除这些以“ .deleted ”为后缀的文件。默认1分钟执行一次， 可以通过 file.delete.delay.ms 来配置。
   

基于日志大小策略

日志删除任务会周期检查当前日志大小是否超过设定的阈值**(retentionSize)** 来寻找可删除的日志段文件集合**(deletableSegments)**。

其中retentionSize这里我们可以通过 Kafka Broker 端的参数log.retention.bytes 来设置， 默认值为-1，即无穷大。

这里需要注意的是 log.retention.bytes 设置的是Log中所有日志文件的大小，而不是单个日志段的大小。单个日志段可以通过参数 log.segment.bytes 来设置，默认大小为1G。

【删除步骤】：

1. 首先计算日志文件的总大小Size和 retentionSize 的差值，即需要删除的日志总大小。
2. 然后从日志文件中的第一个日志段开始进行查找可删除的日志段的文件集合(deletableSegments)
3. 找到后就可以进行删除操作了。
   
   基于日志起始偏移量
   
   该策略判断依据是日志段的下一个日志段的起始偏移量 baseOffset 是否小于等于 logStartOffset，如果是，则可以删除此日志分段。

【如下图所示 删除步骤】：

1. 首先从头开始遍历每个日志段，日志段 1 的下一个日志分段的起始偏移量为20，小于 logStartOffset 的大小，将日志段1加入deletableSegments。
2. 日志段2的下一个日志偏移量的起始偏移量为35，也小于 logStartOffset 的大小，将日志分段2页加入 deletableSegments。
3. 日志段3的下一个日志偏移量的起始偏移量为50，也小于 logStartOffset 的大小，将日志分段3页加入 deletableSegments。
4. 日志段4的下一个日志偏移量通过对比后，在 logStartOffset 的右侧，那么从日志段4开始的所有日志段都不会加入 deletableSegments。
5. 待收集完所有的可删除的日志集合后就可以直接删除了。
   

02

日志压缩

**日志压缩 Log Compaction 对于有相同key的不同value值，只保留最后一个版本。**如果应用只关心 key 对应的最新 value 值，则可以开启 Kafka 相应的日志清理功能，Kafka 会定期将相同 key 的消息进行合并，只保留最新的 value 值。

Log Compaction 可以类比 Redis 中的 RDB 的持久化模式。我们可以想象下，如果每次消息变更都存 Kafka，在某一时刻， Kafka 异常崩溃后，如果想快速恢复，可以直接使用日志压缩策略， 这样在恢复的时候只需要恢复最新的数据即可，这样可以加快恢复速度。

13.__consumer_offsets 是做什么用的？

这是一个内部主题，公开的官网资料很少涉及到。因此，我认为，此题属于面试官炫技一类的题目。你要小心这里的考点：该主题有 3 个重要的知识点，你一定要全部答出来，才会显得对这块知识非常熟悉。

• 它是一个内部主题，无需手动干预，由 Kafka 自行管理。当然，我们可以创建该主题。
• 它的主要作用是负责注册消费者以及保存位移值。可能你对保存位移值的功能很熟悉，但其实该主题也是保存消费者元数据的地方。千万记得把这一点也回答上。另外，这里的消费者泛指消费者组和独立消费者，而不仅仅是消费者组。
• Kafka 的 GroupCoordinator 组件提供对该主题完整的管理功能，包括该主题的创建、写入、读取和 Leader 维护等。

14. 生产者发送消息时如何选择分区的？

15.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 特性了。

16.Kafka 为什么不支持读写分离？

在 Kafka 中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，从 而实现的是一种主写主读的生产消费模型。 Kafka 并不支持主写从读，因为主写从读有 2 个很明显的缺点:

1.数据一致性问题: 数据从主节点转到从节点必然会有一个延时的时间窗口,这个时间 窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X，之后将主节点中 A 的值修改为 Y那么在这个变更通知到从节点之前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题。读写分离适用于那种读负载很大，而写操作相对不频繁的场景，可 Kafka 不属于这样的场景。

2.延时问题: 类似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程需要经历 网络一主节点内存一网络一从节点内存 这几个阶段,整个过程会耗费一定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时,它需要经历 网络一主节点内存一主节点磁盘一网络一从节 点内存一从节点磁盘 这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用，

而 kafka 的主写主读的优点就很多了

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

里获取](https://bbs.csdn.net/topics/618545628)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！