前言

Kafka 是一个分布式的、发布-订阅式音讯中间件。最初是由 Linkedin 领英公司根据 Scala 和 Java 语言开发的分布式音讯体系，现已捐献给 Apache 软件基金会。事实上 Kafka 不仅仅是一个音讯行列（MQ），其已然成为一个开源的分布式流处理渠道。Kafka 具有高吞吐、低推迟的特性，许多大数据处理体系比如 Storm、Spark、Flink 等都能很好地与之集成。

小编共享的这份2022年Java秋招备战面试题总计有1000多道面试题，包含了MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Java 并发编程、Java根底、Spring、微服务、Linux、Spring Boot 、Spring Cloud、RabbitMQ、kafka等16个专题技术点，都是小编在今年金三银四总结出来的面试真题，现已有许多粉丝靠这份PDF拿下许多大厂的offer，今日在这里总结共享给到咱们！【已结束】

序号	专题技术	内容	地址
1	MyBatis	Mybatis面试题
2	ZooKeeper	ZooKeeper面试题
3	Dubbo	Dubbo面试题
4	Elasticsearch	Elasticsearch 面试题
5	Memcached	Memcached面试题
6	Redis	Redis 面试题
7	MySQL	MySQL 面试题
8	Java并发编程	Java并发编程面试题
9	Java根底	Java根底面试题
10	Spring	Spring面试题
11	微服务	微服务面试题
12	Linux	Linux面试题
13	Spring Boot	Spring Boot面试题
14	Spring Cloud	Spring Cloud面试题
15	RabbitMQ	RabbitMQ面试题
16	kafka	kafka面试题

1、怎么获取topic主题的列表

bin/kafka-topics.sh --list --zookeeper localhost:2181

2、生产者和顾客的命令行是什么？

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保护消费状况跟踪的办法

5、讲一下主从同步

6、为什么需求音讯体系，mysql不能满意需求吗？

1.解耦：

答应你独立的扩展或修正两头的处理进程，只需确保它们遵守同样的接口约束。

2.冗余：

音讯行列把数据进行持久化直到它们现已被完全处理，通过这一办法规避了数据丢失危险。许多音讯行列所选用的”插入-获取-删去”范式中，在把一个音讯从行列中删去之前，需求你的处理体系清晰的指出该音讯现已被处理结束，从而确保你的数据被安全的保存直到你运用结束。

3.扩展性：

由于音讯行列解耦了你的处理进程，所以增大音讯入队和处理的频率是很容易的，只需别的添加处理进程即可。

4.灵活性 & 峰值处理能力：

在拜访量剧增的状况下，应用依然需求继续发挥作用，但是这样的突发流量并不常见。假如为以能处理这类峰值拜访为规范来投入资源随时待命无疑是巨大的糟蹋。运用音讯行列能够使关键组件顶住突发的拜访压力，而不会由于突发的超负荷的请求而完全溃散。

5.可康复性：

体系的一部分组件失效时，不会影响到整个体系。音讯行列降低了进程间的耦合度，所以即便一个处理音讯的进程挂掉，参加行列中的音讯依然能够在体系康复后被处理。

6.次序确保：

在大多运用场景下，数据处理的次序都很重要。大部分音讯行列原本便是排序的，并且能确保数据会按照特定的次序来处理。（Kafka 确保一个 Partition 内的音讯的有序性）

7.缓冲：

有助于操控和优化数据流通过体系的速度，处理生产音讯和消费音讯的处理速度不一致的状况。

8.异步通讯：

许多时分，用户不想也不需求当即处理音讯。音讯行列供给了异步处理机制，答应用户把一个音讯放入行列，但并不当即处理它。想向行列中放入多少音讯就放多少，然后在需求的时分再去处理它们。

7、Zookeeper对于Kafka的作用是什么？

8、数据传输的事务界说有哪三种？

9、Kafka判断一个节点是否还活着有那两个条件？

10、Kafka 与传统MQ音讯体系之间有三个关键差异

11、讲一讲kafka的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 循环：

14、怎么操控消费的位置

kafka 运用 seek(TopicPartition, long)指定新的消费位置。用于查找服务器保存的最早和最新的 offset 的特别的办法也可用（seekToBeginning(Collection) 和seekToEnd(Collection)）

15、kafka分布式（不是单机）的状况下，怎么确保音讯的次序消费?

16、kafka的高可用机制是什么？

这个问题比较体系，回答出 kafka 的体系特点，leader 和 follower 的关系，音讯读写的次序即可。

17、kafka怎么减少数据丢失

18、kafka怎么不消费重复数据？比如扣款，咱们不能重复的扣。