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

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

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

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

不过，抛出 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 机制的原理，推荐你赶紧去学习下。

6. Kafka服务器能接收到的最大信息是多少？如何设置 Kafka 能接收的最大消息的大小？

Kafka服务器可以接收到的消息的最大大小是1000000字节
这道题除了要回答消费者端的参数设置之外，一定要加上 Broker 端的设置，这样才算完整。毕竟，如果 Producer 都不能向 Broker 端发送数据很大的消息，又何来消费一说呢？因此，你需要同时设置 Broker 端参数和 Consumer 端参数。

• Broker 端参数：message.max.bytes、max.message.bytes（主题级别）和 replica.fetch.max.bytes。
• Consumer 端参数：fetch.message.max.bytes。

Broker 端的最后一个参数比较容易遗漏。我们必须调整 Follower 副本能够接收的最大消息的大小，否则，副本同步就会失败。因此，把这个答出来的话，就是一个加分项。

7. 监控 Kafka 的框架都有哪些？

其实，目前业界并没有公认的解决方案，各家都有各自的监控之道。所以，面试官其实是在考察你对监控框架的了解广度，或者说，你是否知道很多能监控 Kafka 的框架或方法。下面这些就是 Kafka 发展历程上比较有名气的监控系统。

• Kafka Manager：应该算是最有名的专属 Kafka 监控框架了，是独立的监控系统。
• Kafka Monitor：LinkedIn 开源的免费框架，支持对集群进行系统测试，并实时监控测试结果。
• CruiseControl：也是 LinkedIn 公司开源的监控框架，用于实时监测资源使用率，以及提供常用运维操作等。无 UI 界面，只提供 REST API。
• JMX 监控：由于 Kafka 提供的监控指标都是基于 JMX 的，因此，市面上任何能够集成 JMX 的框架都可以使用，比如 Zabbix 和 Prometheus。
• 已有大数据平台自己的监控体系：像 Cloudera 提供的 CDH 这类大数据平台，天然就提供 Kafka 监控方案。JMXTool：社区提供的命令行工具，能够实时监控 JMX 指标。答上这一条，属于绝对的加分项，因为知道的人很少，而且会给人一种你对 Kafka 工具非常熟悉的感觉。如果你暂时不了解它的用法，可以在命令行以无参数方式执行一下kafka-run-class.sh kafka.tools.JmxTool，学习下它的用法。

8.Broker 的 Heap Size 如何设置？

如何设置 Heap Size 的问题，其实和 Kafka 关系不大，它是一类非常通用的面试题目。一旦你应对不当，面试方向很有可能被引到 JVM 和 GC 上去，那样的话，你被问住的几率就会增大。因此，我建议你简单地介绍一下 Heap Size 的设置方法，并把重点放在 Kafka Broker 堆大小设置的最佳实践上。

比如，你可以这样回复：任何 Java 进程 JVM 堆大小的设置都需要仔细地进行考量和测试。一个常见的做法是，以默认的初始 JVM 堆大小运行程序，当系统达到稳定状态后，手动触发一次 Full GC，然后通过 JVM 工具查看 GC 后的存活对象大小。之后，将堆大小设置成存活对象总大小的 1.5~2 倍。对于 Kafka 而言，这个方法也是适用的。不过，业界有个最佳实践，那就是将 Broker 的 Heap Size 固定为 6GB。经过很多公司的验证，这个大小是足够且良好的。

9. 如何估算 Kafka 集群的机器数量？

这道题目考查的是机器数量和所用资源之间的关联关系。所谓资源，也就是 CPU、内存、磁盘和带宽。

通常来说，CPU 和内存资源的充足是比较容易保证的，因此，你需要从磁盘空间和带宽占用两个维度去评估机器数量。

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

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

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

(https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**

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