2024年最新面试题篇-13-Kafka相关面试题_kafka面试题，今天带你详细了解各组件原理

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

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

消息队列Message Queue，简称MQ。
是一种应用间的通信方式，主要由三个部分组成。

• 生产者：Producer
  消息的产生者与调用端
  主要负责消息所承载的业务信息的实例化是一个队列的发起方
• 代理：Broker
  主要的处理单元
  负责消息的存储、投递、及各种队列附加功能的实现
  是消息队列最核心的组成部分
• 消费者：Consumer
  一个消息队列的终端也是消息的调用端,具体是根据消息承载的信息，处理各种业务逻辑。

消息队列的应用场景较多，常用的可以分为三种：

• 异步处理
  主要应用于对实时性要求不严格的场景，
  比如：用户注册发送验证码、下单通知、发送优惠券等等。服务方只需要把协商好的消息发送到消息队列，剩下的由消费消息的服务去处理，不用等待消费服务返回结果
  
• 应用解耦
  应用解耦可以看作是把相关但耦合度不高的系统联系起来。比如订单系统与 WMS、EHR 系统，有关联但不哪么紧密，每个系统之间只需要把约定的消息发送到 MQ，另外的系统去消费即可。
  解决了各个系统可以采用不同的架构、语言来实现，从而大大增加了系统的灵活性。
  
• 流量削峰
  流量削峰一般应用在大流量入口且短时间内业务需求处理不完的服务中心，为了权衡高可用，把大量的并行任务发送到 MQ 中，依据MQ 的存储及分发功能，平稳的处理后续的业务，起到一个大流量缓冲的作用。
  
  目前市面上常见的消息队列中间件主要有
  ActiveMQ、RabbitMQ、Kafka、RocketMQ 这几种，

在架构技术选型的时候一般根据业务的需求选择合适的中间件：
比如中小型公司，低吞吐量的一般用 ActiveMQ、RabbitMQ 较为合适，大数据高吞吐量的大型公司一般选用 Kafka 和RocketMQ。

2. kafka 的零拷贝原理?

在实际应用中，如果我们需要把磁盘中的某个文件内容发送到远程服务器上，那么它必须要经过几个拷贝的过程，如图（贴图）。

• 从磁盘中读取目标文件内容拷贝到内核缓冲区
• CPU 控制器再把内核缓冲区的数据赋值到用户空间的缓冲区中
• 接着在应用程序中，调用 write()方法，把用户空间缓冲区中的数据拷贝到内核下的Socket Buffer 中。
• 最后，把在内核模式下的 SocketBuffer 中的数据赋值到网卡缓冲区（NIC Buffer)
• 网卡缓冲区再把数据传输到目标服务器上。

在这个过程中我们可以发现，数据从磁盘到最终发送出去，要经历 4 次拷贝，而在这四次拷贝过程中，有两次拷贝是浪费的，分别是：

• 从内核空间赋值到用户空间
• 从用户空间再次复制到内核空间

除此之外，由于用户空间和内核空间的切换会带来 CPU 的上线文切换，对于 CPU 性能也会造成性能影响。
而零拷贝，就是把这两次多于的拷贝省略掉，应用程序可以直接把磁盘中的数据从内核中直接传输给Socket，而不需要再经过应用程序所在的用户空间，如下图所示

零拷贝通过DMA（Direct Memory Access）技术把文件内容复制到内核空间中的Read Buffer，
接着把包含数据位置和长度信息的文件描述符加载到Socket Buffer 中，DMA 引擎直接可以把数据从内核空间中传递给网卡设备。
在这个流程中，数据只经历了两次拷贝就发送到了网卡中，并且减少了 2 次cpu 的上下文切换，对于效率有非常大的提高。

所以，所谓零拷贝，并不是完全没有数据赋值，只是相对于用户空间来说，不再需要进行数据拷贝。对于前面说的整个流程来说，零拷贝只是减少了不必要的拷贝次数而已。

在程序中如何实现零拷贝呢？

• 在Linux 中，零拷贝技术依赖于底层的sendfile()方法实现
• 在Java 中，FileChannal.transferTo() 方法的底层实现就是 sendfile() 方法。

除此之外，还有一个 mmap 的文件映射机制;
它的原理是：将磁盘文件映射到内存, 用户通过修改内存就能修改磁盘文件。使用这种方式可以获取很大的 I/O 提升，省去了用户空间到内核空间复制的开销。

3. Kafka 如何保证消息不丢失？

kafka 是一个用来实现异步消息通信的中间件，它的整个架构由Producer、 Consumer、Broker 组成。

所以，对于kafka 如何保证消息不丢失这个问题，可以从三个方面来考虑和实现。

3.1 Producer 端

首先是Producer 端，需要确保消息能够到达 Broker 并实现消息存储，在这个层面，有可能出现网络问题，导致消息发送失败，所以，针对Producer 端，可以通过 2 种方式来避免消息丢失

• Producer 默认是异步发送消息，这种情况下要确保消息发送成功，有两个方法
  • a.把异步发送改成同步发送，这样producer 就能实时知道消息发送的结果。
  • b.添加异步回调函数来监听消息发送的结果，如果发送失败，可以在回调中重试。
• Producer 本身提供了一个重试参数retries，如果因为网络问题或者 Broker 故障导致发送失败，Producer 会自动重试。

3.2 Broker 端

然后是Broker 端，Broker 需要确保Producer 发送过来的消息不会丢失，也就是只需要把消息持久化到磁盘就可以了。
（如图）但是，Kafka 为了提升性能，采用了异步批量刷盘的实现机制，也就是说按照一定的消息量和时间间隔来刷盘，而最终刷新到磁盘的这个动作，是由操作系统来调度的，所以如果在刷盘之前系统崩溃，就会导致数据丢失。

Kafka 并没有提供同步刷盘的实现，所以针对这个问题，需要通过Partition的副本机制和acks 机制来一起解决。

• “我简单说一下 Partition 副本机制，它是针对每个数据分区的高可用策略，每个 partition 副本集包含唯一的一个 Leader 和多个 Follower，Leader 专门处理事务类的请求，Follower 负责同步Leader 的数据”。
• 在这样的一种机制的基础上，kafka 提供了一个acks 的参数，Producer 可以设置acks参数再结合Broker 的副本机制来个共同保障数据的可靠性。
• acks 有几个值的选择。
  • acks=0， 表示producer 不需要等Broker 的响应，就认为消息发送成功，这种情况会存在消息丢失。
  • acks=1，表示Broker 中的Leader Partition 收到消息以后，不等待其他 Follower Partition 同步完，就给Producer 返回确认，这种情况下Leader Partition 挂了，会存在数据丢失。
  • acks=-1，表示Broker 中的Leader Parititon 收到消息后，并且等待 ISR 列表中的follower 同步完成，再给 Producer 返回确认，这个配置可以保证数据的可靠性。

3.3 Consumer

最后，就是Consumer 必须要能消费到这个消息，实际上，我认为，只要producer和broker 的消息可靠的到了保障，那么消费端是不太可能出现消息无法消费的问题，除非是Consumer 没有消费完这个消息就直接提交了，但是即便是这个情况，也可以通过调整offset 的值来重新消费。

4. Kafka 怎么避免重复消费?

首先，（如图）Kafka Broker 上存储的消息，都有一个Offset 标记。然后kafka 的消费者是通过 offSet 标记来维护当前已经消费的数据，
每消费一批数据，Kafka Broker 就会更新OffSet 的值，避免重复消费。

默认情况下，消息消费完以后，会自动提交 Offset 的值，避免重复消费。
Kafka 消费端的自动提交逻辑有一个默认的 5 秒间隔，也就是说在 5 秒之后的下一次向 Broker 拉取消息的时候提交。
所以在Consumer 消费的过程中，应用程序被强制 kill 掉或者宕机，可能会导致 Offset没提交，从而产生重复提交的问题。
除此之外，还有另外一种情况也会出现重复消费。

（如图）在Kafka 里面有一个Partition Balance 机制，就是把多个Partition 均衡的分配给多个消费者。

Consumer 端会从分配的Partition 里面去消费消息，如果 Consumer 在默认的 5 分钟内没办法处理完这一批消息。
就会触发Kafka 的Rebalance 机制，从而导致Offset 自动提交失败。
而在重新Rebalance 之后，Consumer 还是会从之前没提交的 Offset 位置开始消费，也会导致消息重复消费的问题。

基于这样的背景下，我认为解决重复消费消息问题的方法有几个:

• 提高消费端的处理性能避免触发Balance，比如可以用异步的方式来处理消息，缩短单个消息消费的市场。或者还可以调整消息处理的超时时间。还可以减少一次性从Broker 上拉取数据的条数。
• 可以针对消息生成md5 然后保存到 mysql 或者redis 里面，在处理消息之前先去 mysql 或者redis 里面判断是否已经消费过。这个方案其实就是利用幂等性的思想。

5. 什么是 ISR，为什么需要引入 ISR?

首先，发送到 Kafka Broker 上的消息，最终是以 Partition 的物理形态来存储到磁盘上的。
（如图）而Kafka 为了保证Parititon 的可靠性，提供了 Paritition 的副本机制，然后在这些Partition 副本集里面。存在Leader Partition 和Flollower Partition。
生产者发送过来的消息，会先存到 Leader Partition 里面，然后再把消息复制到 Follower Partition，
这样设计的好处就是一旦Leader Partition 所在的节点挂了，可以重新从剩余的 Partition 副本里面选举出新的 Leader。
然后消费者可以继续从新的 Leader Partition 里面获取未消费的数据。

在Partition 多副本设计的方案里面，有两个很关键的需求。

• 副本数据的同步
• 新Leader 的选举

这两个需求都需要涉及到网络通信，Kafka 为了避免网络通信延迟带来的性能问题，以及尽可能的保证新选举出来的Leader Partition 里面的数据是最新的，所以设计了 ISR 这样一个方案。

ISR 全称是 in-sync replica，它是一个集合列表，里面保存的是和 Leader Parition 节点数据最接近的 Follower Partition
如果某个Follower Partition 里面的数据落后 Leader 太多，就会被剔除 ISR 列表。
简单来说，ISR 列表里面的节点，同步的数据一定是最新的，所以后续的Leader 选举，只需要从ISR 列表里面筛选就行了。
所以，我认为引入ISR 这个方案的原因有两个:

• 尽可能的保证数据同步的效率，因为同步效率不高的节点都会被踢出 ISR 列表。
• 避免数据的丢失，因为 ISR 里面的节点数据是和 Leader 副本最接近的。以上就是我对这个问题的理解

6. Kafka 如何保证消息消费的顺序性？

首先，在 kafka 的架构里面，用到了 Partition 分区机制来实现消息的物理存储（如图），在同一个topic 下面，可以维护多个partition 来实现消息的分片。

生产者在发送消息的时候，会根据消息的 key 进行取模（如图），来决定把当前消息存储到哪个partition 里面。
并且消息是按照先后顺序有序存储到 partition 里面的。

在这种情况下，（如图），假设有一个topic 存在三个partition，而消息正好被路由到三个独立的partition 里面。
然后消费端有三个消费者通过 balance 机制分别指派了对应消费分区。因为消费者是完全独立的网络节点，
所有可能会出现，消息的消费顺序不是按照发送顺序来实现的，从而导致乱序的问题。

针对这个问题，一般的解决办法就是自定义消息分区路由的算法，然后把指定的key都发送到同一个 Partition 里面。（如图）
接着指定一个消费者专门来消费某个分区的数据，这样就能保证消息的顺序消费了。

另外，有些设计方案里面，在消费端会采用异步线程的方式来消费数据来提高消息的处理效率，那这种情况下，因为每个线程的消息处理效率是不同的，所以即便是采用单个分区的存储和消费也可能会出现无序问题，针对这个问题的解决办法就是在消费者这边使用一个阻塞队列，把获取到的消息先保存到阻塞队列里面，然后异步线程从阻塞队列里面去获取消息来消费。

在Java中，可以使用Kafka的消费者API来实现消息的顺序消费。以下是几种可以考虑的方法：

• 单个分区消费：创建一个单独的消费者实例来消费一个分区的消息。这样可以确保在单个分区内的消息按顺序消费。但是需要注意，如果有多个分区，不同分区的消息仍可能以并发方式进行消费。
• 指定分区消费：通过指定消费者订阅的特定分区，可以确保只消费指定分区的消息。这样，可以通过将相关消息发送到同一个分区来保证消息的顺序消费。
• 按键分区：Kafka允许根据消息的键（key）来决定将消息发送到哪个分区。如果消息的键是相同的，Kafka会将它们发送到同一个分区。因此，可以根据消息的键来保证消息的顺序消费。

无论选择哪种方法，都应该注意以下几点：

• 设置消费者的 max.poll.records 参数，确保每次拉取的消息数量合适，以避免因一次拉取的消息过多而导致处理速度过慢。
• 在消费者处理消息时，确保消息处理的逻辑是线程安全的。
• 监听消费者的 onPartitionsRevoked 事件，以便在重新分配分区时进行必要的清理和准备工作。
  使用 auto.offset.reset 参数设置消费者的offset重置策略，以决定当消费者启动时从哪个offset开始消费。

7. Kafka 消息队列怎么保证 exactlyOnce，怎么实现顺序消费?

当我们向某个Topic 发送消息的时候，在 Kafka 的Broker 上，会通过Partition 分区的机制来实现消息的物理存储。
一个Topic 可以有多个Partition，相当于把一个 Topic 里面的N 个消息数据进行分片存储。
消费端去消费消息的时候，会从指定的Partition 中去获取。
在同一个消费组中，一个消费者可以消费多个Partition 中的数据。但是消费者的数量只能小于或者等于Partition 分区数量。

理解了Kafka 的工作机制以后，再来理解一下exactlyOnce 的意思，在MQ 的消息投递的语义有三种：

• At Most Once: 消息投递至多一次，可能会丢但不会出现重复。
• At Least Once: 消息投递至少一次，可能会出现重复但不会丢。
• Exactly Once: 消息投递正好一次，不会出现重复也不会丢。

准确来说，目前市面上的MQ 产品，基本上都没有提供Exactly Once 语义的实现。我们只能通过一些其他手段来达到 Exactly Once 的效果。也就是确保生产者只发送一次，消费端只接受一次

• 生产者可以采用事物消息的方式，事务可以支持多分区的数据完整性，原子性。并且支持跨会话的exactly once 处理语义，即使 producer 宕机重启，依旧能保证数据只处理一次
  开启事务首先需要开启幂等性，即设置 enable.idempotence 为true。然后对producer消息发送做事务控制。
  如果出现导致生产者重试的错误，同样的消息，仍由同样的生产者发送多次，这个消息只被写到 Kafka broker 的日志中一次;
• 虽然生产者能保证在 Kafka broker 上只记录唯一一条消息，但是由于网络延迟的存在，有可能会导致 Broker 在投递消息给消费者的时候，触发重试导致投递多次。
  所以消费端，可以采用幂等性的机制来避免重试带来的重复消费问题。
• 其次，关于实现顺序消费问题。
  在Kafka 里面，每个Partition 分区的消息本身就是按照顺序存储的。
  所以只需要针对 Topic 设置一个Partition，这样就保证了所有消息都写入到这一个 Partition 中。
  而消费者这边只需要消费这个分区，就可以实现消息的顺序消费处理。

8. kafka 为啥是拉取消息而不是推送消息

Kafka是-种分布式流数据平台…被广泛应用王太规模的实时数据处理和消息传递系统中。作为一种高吞吐量、低延迟的消息系统，Kafka的消息拉取机制是其核心原理之一。

8.1 Kafka的消息拉取机制简介

Kafka的消息拉取机制是指消费者从Kafka集群中主动拉取消息的过程。相比于传统的发布-订阅模式中，由消息中间件主动推送消息给消费者，Kafka的消息拉取机制具有更高的灵活性和可控性。消费者可以根据自身的处理能力和需求主动拉取消息，从而实现更加高效的消息处理。

8.2 消息拉取的工作流程

8.2.1 消费者订阅主题

在使用Kafka的消息拉取机制之前，消费者需要先订阅一个或多个主题。主题是Kafka中消息的分类单位，可以看作是消息的容器。消费者通过指定主题来获取相应的消息。

8.2.2 拉取消息的偏移量

在拉取消息之前，消费者需要指定拉取消息的偏移量。偏移量可以理解为消息在主题中的位置信息，通过指定偏移量，消费者可以准确地获取指定位置的消息。Kafka提供了两种偏移量的管理方式：手动管理和自动管理。消费者可以根据需要选择适合的偏移量管理方式。

8.2.3 拉取消息

一旦订阅了主题并指定了偏移量，消费者就可以开始拉取消息了。消费者向Kafka集群发送拉取消息请求，Kafka集群根据请求返回相应的消息。Kafka支持按照时间戳、偏移量范围等方式进行消息拉取，消费者可以根据自身的需求选择合适的拉取方式。

8.2.4 处理消息

消费者获取到消息后，可以进行相应的处理。处理方式可以根据实际业务需求而定，例如存储到数据库、进行实时计算等。

8.2.5 提交偏移量

在消息处理完成后，消费者需要提交偏移量。偏移量的提交是为了记录消费者已经处理过的消息位置，以便下次拉取消息时能够继续从上次的位置开始。消费者可以选择手动提交偏移量或自动提交偏移量，具体方式根据实际情况而定。

8.3 消息拉取的优势和适用场景

Kafka的消息拉取机制相比于消息推送机制具有以下优势：

• 灵活性高：消费者可以根据自身的处理能力和需求主动拉取消息，灵活控制消息的获取速度和频率。
• 节约资源：由于消费者主动拉取消息，可以避免消息的重复推送，节约了网络带宽和系统资源。
• 异步处理：消费者可以将消息拉取和消息处理过程进行解耦，实现异步处理，提高系统的响应速度和吞吐量。

Kafka的消息拉取机制适用于以下场景：

• 实时数据处理：Kafka可以实时地处理大规模的数据流，通过消息拉取机制，消费者可以根据实际需求灵活地获取消息，进行实时的数据处理和分析。
• .分布式系统集成：Kafka作为一种分布式流数据平台，广泛应用于分布式系统中。通过消息拉取机制，各个节点可以实时地获取和处理消息，实现分布式系统之间的数据交换和集成。

8.4 小总结

Kafka的消息拉取机制是其核心原理之一，通过消费者主动拉取消息的方式，实现了高吞吐量、低延迟的消息处理。消息拉取机制具有灵活性高、节约资源、异步处理等优势，并适用于实时数据处理和分布式系统集成等场景。通过深入理解和灵活运用Kafka的消息拉取原理，可以更好地实现大规模实时数据处理和消息传递的需求。

9. rocketMq和kafka对比

在单机同步发送的场景下，Kafka>RocketMQ，Kafka的吞吐量高达17.3w/s，RocketMQ吞吐量在11.6w/s。

9.1 kafka高性能原因

9.1.1 生产者

Kafka会把收到的消息都写入到硬盘中，它绝对不会丢失数据。为了优化写入速度Kafak采用了两个技术，顺序写入和MMFile。

顺序写入

因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是最耗时的。所以硬盘最“讨厌”随机I/O，最喜欢顺序I/O。为了提高读写硬盘的速度，Kafka就是使用顺序I/O。

收到消息后Kafka会把数据插入到文件末尾。这种方法有一个缺陷——没有办法删除数据，所以Kafka是不会删除数据的，它会把所有的数据都保留下来，每个消费者（Consumer）对每个Topic都有一个offset用来表示读取到了第几条数据。

Memory Mapped Files

Kafka的数据并不是实时的写入硬盘，它充分利用了现代操作系统分页存储来利用内存提高I/O效率。

Memory Mapped Files也被翻译成内存映射文件，在64位操作系统中一般可以表示20G的数据文件，它的工作原理是直接利用操作系统的Page来实现文件到物理内存的直接映射。完成映射之后你对物理内存的操作会被同步到硬盘上（操作系统在适当的时候）。

这种方法也有一个很明显的缺陷——不可靠，写到mmap中的数据并没有被真正的写到硬盘，操作系统会在程序主动调用flush的时候才把数据真正的写到硬盘。Kafka提供了一个参数——producer.type来控制是不是主动flush，如果Kafka写入到mmap之后就立即flush然后再返回Producer叫同步(sync)；写入mmap之后立即返回Producer不调用flush叫异步(async)。

9.1.2 消费者

零拷贝(不经过Cpu的拷贝)

传统read/write方式进行网络文件传输的方式，文件数据实际上是经过了四次copy操作：

• 硬盘—>内核buf—>用户buf—>socket相关缓冲区—>协议引擎
• kafka基于sendfile实现Zero Copy，直接从内核空间（DMA的）到内核空间（Socket的），然后发送网卡。

批量压缩

在很多情况下，系统的瓶颈不是CPU或磁盘，而是网络IO。进行数据压缩会消耗少量的CPU资源，不过对于kafka而言，网络IO更应该需要考虑。

• Kafka使用了批量压缩，即将多个消息一起压缩而不是单个消息压缩。
• Kafka允许使用递归的消息集合，批量的消息可以通过压缩的形式传输并且在日志中也可以保持压缩格式，直到被消费者解压缩。
• Kafka支持多种压缩协议，包括Gzip和Snappy压缩协议。

9.2 rocketMq高性能原因

9.2.1 生产者

顺序写入

• 消息存储是由ConsumeQueue和CommitLog配合完成的。一个Topic里面有多个MessageQueue，每个MessageQueue对应一个ConsumeQueue。
• ConsumeQueue里记录着消息物理存储地址。
• CommitLog就存储文件具体的字节信息。文件大小默认1g，文件名称20位数，左边补0右边为偏移量。消息顺序写入文件，文件满了则写入下一个文件。

9.2.2 消费者

随机读

每次读消息时先读逻辑队列consumQue中的元数据，再从commitlog中找到消息体。但是入口处rocketmq采用package机制，可以批量地从磁盘读取，作为cache存到内存中，加速后续的读取速度。

随机读具体流程

• Consumer每20s重新做一次负载均衡更新，根据从Broker存储的ConsumerGroup和Topic信息，把MessageQueue分发给不同的Consumer，负载策略默认是分页
• 每个MessageQueue对应一个pullRequest，全部存储到该Consumer的pullRequestQueue队列里面
• Consumer启动独立后台PullMessageService线程，不停的尝试从pullRequestQueue.take()获取PullRequest

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

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

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

questQueue队列里面

• Consumer启动独立后台PullMessageService线程，不停的尝试从pullRequestQueue.take()获取PullRequest

[外链图片转存中…(img-y9zIw9Y6-1714921646392)]
[外链图片转存中…(img-kcg0u2cT-1714921646392)]

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

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

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