2024年大数据最全大数据面试题 —— Kafka(1)

• 监控不完善，需要安装插件；
• 由于是批量发送，数据并非真正的实时；
• 依赖zookeeper进行元数据管理。

你在哪些场景下会选择 Kafka

（1）在系统或应用程序之间构建可靠的用于传输实时数据的管道，消息队列功能

（2）构建实时的流数据处理程序来变换或处理数据流，数据处理功能

讲下 Kafka 的整体结构

（1）Producer：消息生产者，负责向Broker发送消息

（2）Consumer：消息消费者，从负责Broker读取并消费消息

（3）Consumer Group（CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

（4）Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

（5）Topic ：主题，使用Topic对消息进行分类，Kafka接收到的每条消息都会放入到一个Topic中。

（6）Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，对Topic的数据进行分布式存储的最小单位。

（7）Replica：副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个Follower。

（8）Leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。

（9）Follower：每个分区多个副本中的“从”，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个Follower会成为新的leader。

Kafka 工作原理 / 流程

Kafka中消息是以topic进行分类的，生产者生产消息，消费者消费消息，都是面向topic的。topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个log文件，该log文件中存储的就是producer生产的数据。Producer生产的数据会被不断追加到该log文件末端，且每条数据都有自己的offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个offset，以便出错恢复时，从上次的位置继续消费。

Kafka为什么那么快/高效读写的原因 / 实现高吞吐的原理

Kafka 的数据在log文件中，是保存在磁盘上。

（1）Kafka本身是分布式集群，并且采用分区技术，并行度高

（2）读数据采用稀疏索引，可以快速定位到要消费的数据

（3）写 log 文件的时候，一直是追加到文件末端，是顺序写的方式，官网中
说了，同样的磁盘，顺序写能达到 600M/s，而随机写只有 100K/s

（4）实现了零拷贝技术，只用将磁盘文件的数据复制到页面缓冲区一次，然后将数据从页面缓冲区直接发送到网络中，这样就避免了在内核空间和用户空间之间的拷贝

生产者如何提高吞吐量（调优）

（1）batch.size：批次大小，默认 16k，即一次发送消息的批次大小。增大批次大小可以减少单个请求的次数，提高吞吐量。

（2）linger.ms：等待时间，调整等待时间可以让生产者等待更多的消息一起发送，减少请求的频率。

（3）compression.type：压缩 snappy（解压缩速度快，压缩率也还行）

（4）RecordAccumulator：缓冲区大小，增大 RecordAccumulator 的缓冲区大小可以积累更多的消息，减少发送请求的频率。

kafka 消息数据积压，消费者如何提高吞吐量

（1）如果是 Kafka 消费能力不足，则可以考虑增加 Topic 的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。 ( 两者缺一不可)

（2）如果是下游的数据处理不及时，提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间 < 生产速度），使处理的数据小于生产的数据，也会造成数据积压。

• fetch.max.bytes：指定了每次拉取消息的最大字节数。增大这个值可以提高每批次拉取的数据量，加快数据的处理速度。
• max.poll.records：指定了每次拉取请求返回的最大消息数。增大这个值可以一次性获取更多的消息，从而提高每批次处理的数据量。

说一下Kafka生产者如何生产数据，消费者如何消费数据

Kafka生产者写入（生产）数据流程

• 生产者先从Zookeeper的 "/brokers/topics/主题名/partitions/分区名/state"节点找到该 partition 的Leader
• 生产者在Zookeeper中找到该ID找到对应的broker
• broker进程上的Leader将消息写入到本地log中
• Follower从Leader上拉取消息，写入到本地log，并向Leader发送ACK
• Leader接收到所有的ISR中的Replica的ACK后，并向生产者返回ACK

Kafka消费者消费数据流程

• 通过Zookeeper找partition对应的Leader位置以及offset，Leader是负责读的
• 找到该分区的Leader，拉取数据
• 然后开始从offset往后顺序从本地log中读取数据
• 消费者提交of