【大数据】Kafka高频面试题（一）_kafka能接收到的最大消息是多少

其适应场景主要有：
**

1）**日志收集方向：**可以用 Kafka 来收集各种服务的 log，然后统一输出，比如日志系统 elk，用 Kafka 进行数据中转。
2）**消息系统方向：**Kafka 具备系统解耦、副本冗余、流量削峰、消息缓冲、可伸缩性、容错性等功能，同时还提供了消息顺序性保障以及消息回溯功能等。
3）**大数据实时计算方向：**Kafka 提供了一套完整的流式处理框架， 被广泛应用到大数据处理，如与 flink、spark、storm 等整合。

2. 什么是消费者组,有什么作用？

首先我们来看看什么是「消费者组」:
消费者组 Consumer Group，顾名思义就是由多个 Consumer 组成，且拥有一个公共且唯一的 Group ID。组内每个消费者负责消费不同分区的数据，**但一个分区只能由一个组内消费者消费，**消费者组之间互不影响。

为什么 Kafka 要设计 Consumer Group, 只有 Consumer 不可以吗？

我们知道 Kafka 是一款高吞吐量，低延迟，高并发, 高可扩展的消息队列产品， 那么如果某个 Topic 拥有数百万到数千万的数据量， 仅仅依靠 Consumer 进程消费， 消费速度可想而知， 所以需要一个扩展性较好的机制来保障消费进度， 这个时候 Consumer Group 应运而生， Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。

Kafka Consumer Group 特点如下:

1）每个 Consumer Group 有一个或者多个 Consumer。
2）每个 Consumer Group 拥有一个公共且唯一的 Group ID。
3) Consumer Group 在消费 Topic 的时候，Topic 的每个 Partition 只能分配给组内的某个 Consumer，只要被任何 Consumer 消费一次, 那么这条数据就可以认为被当前 Consumer Group 消费成功。

3. 在 Kafka 中，ZooKeeper 的作用是什么？

先说标准答案：目前，Kafka 使用 ZooKeeper 存放集群元数据、成员管理、Controller 选举，以及其他一些管理类任务。之后，等 KIP-500 提案完成后，Kafka 将完全不再依赖于 ZooKeeper。

记住，一定要突出“目前”，以彰显你非常了解社区的演进计划。“存放元数据”是指主题分区的所有数据都保存在 ZooKeeper 中，且以它保存的数据为权威，其他“人”都要与它保持对齐。“成员管理”是指 Broker 节点的注册、注销以及属性变更，等等。“Controller 选举”是指选举集群 Controller，而其他管理类任务包括但不限于主题删除、参数配置等。

不过，抛出 KIP-500 也可能是个双刃剑。碰到非常资深的面试官，他可能会进一步追问你 KIP-500 是做的。一言以蔽之：KIP-500 思想，是使用社区自研的基于 Raft 的共识算法，替代 ZooKeeper，实现 Controller 自选举。你可能会担心，如果他继续追问的话，该怎么办呢？别怕，在下一期“特别发送”，我会专门讨论这件事。
Kafka 集群能够正常工作，目前还是需要依赖于 ZooKeeper，主要用来「负责 Kafka集群元数据管理，集群协调工作」，在每个 Kafka 服务器启动的时候去连接并将自己注册到 Zookeeper，类似注册中心。

Kafka 使用 Zookeeper 存放「集群元数据」、「集群成员管理」、 「Controller 选举」、「其他管理类任务」等。待 KRaft 提案完成后，Kafka 将完全不依赖 Zookeeper。

1）**集群元数据：**Topic 对应 Partition 的所有数据都存放在 Zookeeper 中，且以 Zookeeper 保存的数据为准。
2）**集群成员管理：**Broker 节点的注册、删除以及属性变更操作等。主要包括两个方面：成员数量的管理，主要体现在新增成员和移除现有成员；单个成员的管理，如变更单个 Broker 的数据等。
3）Controller 选举：即选举 Broker 集群的控制器 Controller。其实它除了具有一般 Broker 的功能之外，还具有选举主题分区 Leader 节点的功能。在启动 Kafka系统时，其中一个 Broker 会被选举为控制器，负责管理主题分区和副本状态，还会执行分区重新分配的管理任务。如果在 Kafka 系统运行过程中，当前的控制器出现故障导致不可用，那么 Kafka 系统会从其他正常运行的 Broker 中重新选举出新的控制器。
4）**其他管理类任务：**包括但不限于 Topic 的管理、参数配置等等。

4. 解释下 Kafka 中位移（offset）的作用

在 Kafka 中每个 Topic 分区下面的每条消息都被赋予了一个唯一的ID值，用来标识它在分区中的位置。这个ID值就被称为位移「Offset」或者叫偏移量，一旦消息被写入到日志分区中，它的位移值将不能被修改。

01

位移 Offset 管理方式

Kafka 旧版本（0.9版本之前）是把位移保存在 ZooKeeper 中，减少 Broker 端状态存储开销。

鉴于 Zookeeper 不适合频繁写更新，而 Consumer Group 的位移提交又是高频写操作，这样会拖慢 ZooKeeper 集群的性能， 于是在新版 Kafka 中， 社区采用了将位移保存在 Kafka 内部「Kafka Topic 天然支持高频写且持久化」，这就是所谓大名鼎鼎的__consumer_offsets。

**__consumer_offsets：**用来保存 Kafka Consumer 提交的位移信息，另外它是由 Kafka 自动创建的，和普通的 Topic 相同，它的消息格式也是 Kafka 自己定义的，我们无法进行修改。

__consumer_offsets 有3种消息格式：

1）用来保存 Consumer Group 信息的消息。
2）用来删除 Group 过期位移甚至是删除 Group 的消息，也可以称为 tombstone 消息，即墓碑消息，它的主要特点是空消息体，一旦某个 Consumer Group 下的所有Consumer 位移数据都已被删除时，Kafka会向 __consumer_offsets 主题的对应分区写入 tombstone 消息，表明要彻底删除这个 Group 的信息。
3) 用来保存位移值。
__consumer_offsets 消息格式分析揭秘：

1. 消息格式我们可以简单理解为是一个 KV 对。Key 和 Value 分别表示消息的键值和消息体。
2. 那么 Key 存什么呢？既然是存储 Consumer 的位移信息，在 Kafka 中，Consumer 数量会很多，必须有字段来标识位移数据是属于哪个 Consumer 的，怎么来标识 Consumer 字段呢？我们知道 Consumer Group 会共享一个公共且唯一的 Group ID，那么只保存它就可以了吗？我们知道 Consumer 提交位移是在分区的维度进行的，很显然，key中还应该保存 Consumer 要提交位移的分区。
3. 总结：位移主题的 Key 中应该保存 3 部分内容：<Group ID，主题名，分区号>
4. value 可以简单认为存储的是 offset 值，当然底层还存储其他一些元数据，帮助 Kafka 来完成一些其他操作，比如删除过期位移数据等。

__consumer_offsets 消息格式示意图：

**

**

**

02

__consumer_offsets 创建
**

__consumer_offsets 是怎么被创建出来的呢？ 当 Kafka 集群中的第一个 Consumer 启动时，Kafka 会自动创建__consumer_offsets。

它就是普通的 Topic，也有对应的分区数，如果由 Kafka 自动创建的，那么分区数又是怎么设置的呢？

这个依赖 Broker 端参数主题分区位移个数即「offsets.topic.num.partitions」 默认值是50，因此 Kafka 会自动创建一个有 50 个分区的 __consumer_offsets 。既然有分区数，必然就会有分区对应的副本个数，这个是依赖Broker 端另外一个参数来完成的，即 「offsets.topic.replication.factor」默认值为3。

总结一下， __consumer_offsets 由 Kafka 自动创建的，那么该 Topic 的分区数是 50，副本数是 3，而具体 Consumer Group 的消费情况要存储到哪个 Partition ，根据**abs(GroupId.hashCode()) % NumPartitions **来计算的，这样就可以保证 Consumer Offset 信息与 Consumer Group 对应的 Coordinator 处于同一个 Broker 节点上。如下图所示：

5. 阐述下 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 机制”，国内的资料不是很多，它的普及度远不如高水位，不妨大胆地把这个概念秀出来，力求惊艳一把。上一季专栏的第 27 节课讲的就是 Leader Epoch 机制的原理，推荐你赶紧去学习下。

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

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

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

朋友，可以戳这里获取](https://bbs.csdn.net/topics/618545628)**

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