18道kafka高频面试题（附答案），2024新一波步调员跳槽季
注意这里的 IP 是 server.properties 中的 listeners 的配置。接下来每个新行就是输入一条新消息。消费者接受消息：
bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topicHello-Kafka --from-beginning
3、consumer 是推照旧拉？
Kafka 最初考虑的标题是，customer 应该从 brokes 拉取消息照旧 brokers 将消息推送到 consumer，也就是 pull 还 push。在这方面，Kafka 遵循了一种大部分消息系统共同的传统的计划：producer 将消息推送到 broker，consumer 从broker 拉取消息。
一些消息系统比如 Scribe 和 Apache Flume 采用了 push 模式，将消息推送到下游的 consumer。如许做有好处也有坏处：由 broker 决定消息推送的速率，对于差别消费速率的 consumer 就不太好处置惩罚了。消息系统都致力于让 consumer 以最大的速率最快速的消费消息，但不幸的是，push 模式下，当 broker 推送的速率远大于 consumer 消费的速率时，consumer 恐怕就要崩溃了。最终 Kafka 照旧选取了传统的 pull 模式。
Pull 模式的另外一个好处是 consumer 可以自主决定是否批量的从 broker 拉取数据 。Push 模式必须在不知道下游 consumer 消费本领和消费策略的情况下决定是立刻推送每条消息照旧缓存之后批量推送。如果为了克制 consumer 崩溃而采用较低的推送速率，将大概导致一次只推送较少的消息而造成浪费。Pull 模式下，consumer 就可以根据本身的消费本领去决定这些策略。
Pull 有个缺点是，如果 broker 没有可供消费的消息，将导致 consumer 不停在循环中轮询，直到新消息到 t 达。为了克制这点，Kafka 有个参数可以让 consumer壅闭知道新消息到达(固然也可以壅闭知道消息的数量到达某个特定的量如许就可以批量发送)。
4、讲讲 kafka 维护消费状态跟踪的方法
大部分消息系统在 broker 端的维护消息被消费的记录：一个消息被分发到consumer 后 broker 就马上进行标志大概等待 customer 的关照后进行标志。如许也可以在消息在消费后立马就删除以减少空间占用。
但是如许会不会有什么标题呢？如果一条消息发送出去之后就立刻被标志为消费过的，旦 consumer 处置惩罚消息时失败了（比如步调崩溃）消息就丢失了。为了办理这个标题，很多消息系统提供了另外一个个功能：当消息被发送出去之后仅仅被标志为已发送状态，当接到 consumer 已经消费成功的关照后才标志为已被消费的状态。这虽然办理了消息丢失的标题，但产生了新标题，首先如果 consumer处置惩罚消息成功了但是向 broker 发送响应时失败了，这条消息将被消费两次。第二个标题时，broker 必须维护每条消息的状态，而且每次都要先锁住消息然后更改状态然后释放锁。如许麻烦又来了，且不说要维护大量的状态数据，比如如果消息发送出去但没有收到消费成功的关照，这条消息将不停处于被锁定的状态，Kafka 采用了差别的策略。Topic 被分成了多少分区，每个分区在同一时间只被一个 consumer 消费。这意味着每个分区被消费的消息在日志中的位置仅仅是一个简单的整数：offset。如许就很轻易标志每个分区消费状态就很轻易了，仅仅需要一个整数而已。如许消费状态的跟踪就很简单了。
这带来了另外一个好处：consumer 可以把 offset 调成一个较老的值，去重新消费老的消息。这对传统的消息系统来说看起来有些不可思议，但确实黑白常有用的，谁规定了一条消息只能被消费一次呢？
5、讲一下主从同步
Kafka答应topic的分区拥有多少副本，这个数量是可以配置的，你可以为每个topci配置副本的数量。Kafka会主动在每个个副本上备份数据，所以当一个节点down掉时数据依然是可用的。
Kafka的副本功能不是必须的，你可以配置只有一个副本，如许其实就相当于只有一份数据。
6、为什么需要消息系统，mysql 不能满足需求吗？
（1）解耦：
答应你独立的扩展或修改两边的处置惩罚过程，只要确保它们服从同样的接口约束。
（2）冗余：
消息队列把数据进行恒久化直到它们已经被完全处置惩罚，通过这一方式规避了数据丢失风险。很多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处置惩罚系统明确的指出该消息已经被处置惩罚完毕，从而确保你的数据被安全的生存直到你使用完毕。
（3）扩展性：
因为消息队列解耦了你的处置惩罚过程，所以增大消息入队和处置惩罚的频率是很轻易的，只要另外增优点置惩罚过程即可。
（4）灵活性 & 峰值处置惩罚本领：
在访问量剧增的情况下，应用仍旧需要继续发挥作用，但是如许的突发流量并不常见。如果为以能处置惩罚这类峰值访问为尺度来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的哀求而完全崩溃。
（5）可规复性：
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以纵然一个处置惩罚消息的进程挂掉，加入队列中的消息仍旧可以在系统规复后被处置惩罚。
（6）顺序包管：
在大多使用场景下，数据处置惩罚的顺序都很重要。大部分消息队列本来就是排序的，而且能包管数据会按照特定的顺序来处置惩罚。（Kafka 包管一个 Partition 内的消息的有序性）
（7）缓冲：
有助于控制和优化数据流经过系统的速度，办理生产消息和消费消息的处置惩罚速度差别等的情况。
（8）异步通信：
很多时间，用户不想也不需要立刻处置惩罚消息。消息队列提供了异步处置惩罚机制，答应用户把一个消息放入队列，但并不立刻处置惩罚它。想向队列中放入多少消息就放多少，然后在需要的时间再去处置惩罚它们。
7、Zookeeper 对于 Kafka 的作用是什么？
Zookeeper 是一个开放源码的、高性能的协调服务，它用于 Kafka 的分布式应用。
Zookeeper 主要用于在集群中差别节点之间进行通信
在 Kafka 中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之条件交的偏移量中获取除此之外，它还实行其他运动，如: leader 检测、分布式同步、配置管理、识别新节点何时脱离或连接、集群、节点实时状态等等。
8、数据传输的事件界说有哪三种？
和 MQTT 的事件界说一样都是 3 种。
（1）最多一次: 消息不会被重复发送，最多被传输一次，但也有大概一次不传输
（2）最少一次: 消息不会被漏发送，最少被传输一次，但也有大概被重复传输.
（3）精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的
9、Kafka 判断一个节点是否还活着有那两个条件？
（1）节点必须可以维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连接
（2）如果节点是个 follower,他必须能及时的同步 leader 的写操作，延时不能太久
10、Kafka 与传统 MQ 消息系统之间有三个关键区别
(1).Kafka 恒久化日志，这些日志可以被重复读取和无限期保留
(2).Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提拔容错本领和高可用性
(3).Kafka 支持实时的流式处置惩罚
11、讲一讲 kafka 的 ack 的三种机制
request.required.acks 有三个值 0 1 -1(all)
0: 生产者不会等待 broker 的 ack，这个延迟最低但是存储的包管最弱当 server 挂掉的时间就会丢数据。
1： 服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader挂掉后他不确保是否复制完成新 leader 也会导致数据丢失。
-1(all)： 服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的ack，如许数据不会丢失
12、消费者怎样不主动提交偏移量，由应用提交？
将 auto.commit.offset 设为 false，然后在处置惩罚一批消息后
commitSync() 大概异步提交 commitAsync()
即：
ConsumerRecords<> records = consumer.poll();for (ConsumerRecord<> record : records){
。。。
tyr{
consumer.commitSync()
}
。。。
}
13、消费者故障，出现活锁标题怎样办理？
出现“活锁”的情况，是它持续的发送心跳，但是没有处置惩罚。为了预防消费者在这种情况下不停持有分区，我们使用 max.poll.interval.ms 活跃检测机制。 在此基础上，如果你调用的 poll 的频率大于最大隔断，则客户端将主动地脱离组，以便其他消费者接受该分区。 发生这种情况时，你会看到 offset 提交失败（调用commitSync（）引发的 CommitFailedException）。这是一种安全机制，保障只有运动成员能够提交 offset。所以要留在组中，你必须持续调用 poll。
消费者提供两个配置设置来控制 poll 循环：
max.poll.interval.ms：增大 poll 的隔断，可以为消费者提供更多的时间去处置惩罚返回的消息（调用 poll(long)返回的消息，通常返回的消息都是一批）。缺点是此值越大将会延迟组重新平衡。
max.poll.records：此设置限定每次调用 poll 返回的消息数，如许可以更轻易的预测每次 poll 隔断要处置惩罚的最大值。通过调整此值，可以减少 poll 隔断，减少重新平衡分组的
对于消息处置惩罚时间不可预测地的情况，这些选项是不够的。 处置惩罚这种情况的推荐方法是将消息处置惩罚移到另一个线程中，让消费者继续调用 poll。 但是必须注意确保已提交的 offset 不凌驾实际位置。另外，你必须禁用主动提交，并只有在线程完成处置惩罚后才为记录手动提交偏移量（取决于你）。 还要注意，你需要 pause 暂停分区，不会从 poll 接收到新消息，让线程处置惩罚完之前返回的消息（如果你的处置惩罚本领比拉取消息的慢，那创建新线程将导致你机器内存溢出）。
14、怎样控制消费的位置
kafka 使用 seek(TopicPartition, long)指定新的消费位置。用于查找服务器保留的最早和最新的 offset 的特殊的方法也可用（seekToBeginning(Collection) 和seekToEnd(Collection)）
15、kafka 分布式（不是单机）的情况下，怎样包管消息的顺序消费?
自我先容一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里不停到如今。
深知大多数Java工程师，想要提拔技能，往往是本身摸索发展大概是报班学习，但对于培训机构动则几千的学费，着实压力不小。本身不成体系的自学结果低效又漫长，而且极易遇到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够资助到想自学提拔又不知道该从何学起的朋友，同时减轻大家的负担。
https://i-blog.csdnimg.cn/blog_migrate/d767665753b401fd67d1e8bbd4ce0002.jpeg
https://i-blog.csdnimg.cn/blog_migrate/ae13e8e52a3dcde920d51cb59f3f10d2.png
https://i-blog.csdnimg.cn/blog_migrate/9baae1be7d7a4f6e4addf22a72915722.png
https://i-blog.csdnimg.cn/blog_migrate/94bd0a226aaa1b45468080dea144efdd.png
https://i-blog.csdnimg.cn/blog_migrate/1f177df9b6493656eff475055cf5fd74.png
https://i-blog.csdnimg.cn/blog_migrate/9ac013e1294a130994a6567d60bfa2c2.png
既有得当小白学习的零基础资料，也有得当3年以上经验的小同伴深入学习提拔的进阶课程，根本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点内里都包含大厂面经、学习条记、源码课本、实战项目、讲解视频，而且后续会持续更新
如果你觉得这些内容对你有资助，可以添加V获取：vip1024b （备注Java）
https://i-blog.csdnimg.cn/blog_migrate/47009db74a905ab6be72c509e9456cc9.jpeg
最后
https://i-blog.csdnimg.cn/blog_migrate/b262ffcb3a5657351d036cc82d477e65.png
https://i-blog.csdnimg.cn/blog_migrate/5d2fe87d5b4a807b4f7f98d8c2a7b3a0.png
https://i-blog.csdnimg.cn/blog_migrate/2a3462b647fd68c0d08a1b06bc0fb0ae.png
内容对你有资助，可以添加V获取：vip1024b （备注Java）**
[外链图片转存中…(img-beGejWaW-1711895372429)]
最后
[外链图片转存中…(img-uGtKIsAk-1711895372430)]
[外链图片转存中…(img-DBJNuno0-1711895372430)]
[外链图片转存中…(img-Xj2KeNr6-1711895372430)]
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]