前言
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面试题 | juejin.cn/post/711014… |
| 2 | ZooKeeper | ZooKeeper面试题 | juejin.cn/post/711126… |
| 3 | Dubbo | Dubbo面试题 | juejin.cn/post/711355… |
| 4 | Elasticsearch | Elasticsearch 面试题 | juejin.cn/post/711540… |
| 5 | Memcached | Memcached面试题 | juejin.cn/post/711903… |
| 6 | Redis | Redis 面试题 | juejin.cn/post/711903… |
| 7 | MySQL | MySQL 面试题 | juejin.cn/post/711903… |
| 8 | Java并发编程 | Java并发编程面试题 | juejin.cn/post/711903… |
| 9 | Java基础 | Java基础面试题 | juejin.cn/post/711903… |
| 10 | Spring | Spring面试题 | juejin.cn/post/711904… |
| 11 | 微服务 | 微服务面试题 | juejin.cn/post/711904… |
| 12 | Linux | Linux面试题 | juejin.cn/post/711904… |
| 13 | Spring Boot | Spring Boot面试题 | juejin.cn/post/711904… |
| 14 | Spring Cloud | Spring Cloud面试题 | juejin.cn/post/711904… |
| 15 | RabbitMQ | RabbitMQ面试题 | juejin.cn/post/711904… |
| 16 | kafka | kafka面试题 | juejin.cn/post/711904… |
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 的关系，消息读写的顺序即可。
