基础题，高频面试题，这个问题可以看做是面试官准备和你深入讨论 Kafka 相关内容的开场白。
回答这个问题的基本思路就是列举自己平时使用 Kafka 的场景。但是如果你只是列举一些简单的、没啥心意的 Kafka 使用场景，那么你很难赢得竞争优势，并且打开话题。所以最好是在面试之前准备一些高级的 Kafka 使用场景，并且是某个复杂解决方案中的一部分，这样就可以将话题引导到你精心准备的高级方案下，从而拖过面试时间，并且赢得竞争优势。
略难的题，如果你之前只是遵循公司传统使用 Kafka 而没有思考为什么要优先考虑 Kafka，那么这个问题你很可能回答不出来。
回答这个问题，要从解耦、削峰、性能、可用性这些角度去论证 Kafka 这种机制要比同步调用好，并且进一步推导出一个结论：就是在设计系统的时候，应该并且总是应该优先考虑使用 Kafka 或者说异步操作的。
略难的题，高频面试题。Kafka 的设计者使用了非常多的技巧来提高 Kafka 的性能，而这些性能优化手段互相之间也没太多逻辑上的联系，所以你记忆起来会比较困难。
但是从面试的角度来说，这个问题又是一个非常好的打开话题，引导面试方向的问题。所以你在回答这个问题的时候，就要尽量提及你记得的所有的能够提高 Kafka 性能的点，而后等待面试官进一步追问。
基础题。如果你是科班出身，那么你在学习操作系统的时候几乎肯定会学习到这个概念。
要想回答好这个问题，一定要讲清楚零拷贝的原理，而后引申到零拷贝在不同中间件中的应用。
基础题。相信你肯定听说过顺序写的性能极好，但是一旦让你分析为什么顺序写的性能好，你就回答不出来了。
所以只要你能从操作系统的角度去解释清楚顺序写的特点，就能赢得竞争优势。
基础题，Kafka 面试里面有时候会问到，不算很高频。
你要在这个问题里面刷好亮点，有两个关键点：一个是指出端到端压缩和非端到端压缩的区别；另外一个则是指出你平时使用压缩技术解决性能问题的案例，最好是类似的端到端压缩技术的案例。两者结合就能赢得非常强的竞争优势。
简单的题，不太常问，并且是典型的难者不会会者不难的问题。大多数人都知道 Kafka 是有很多分区的，但是很少有人会深入思考为什么要搞分区，毕竟我们已经有了 Topic 这个逻辑上和业务一一对应的东西了。
要在这个问题底下回答好，就要从为什么引入分区进一步讨论到合理的分区数量，而后又可以进一步打开话题讨论分区数量不足引起的消息积压之类的问题。总之这个问题问得非常好，抓住机会你就能装一波大的。
简单题，很常见，尤其是在校招或者初级工程师的招聘里面。
这个问题的回答要点在于两个：一是介绍 Kafka 的基本概念，提及尽可能多的关键字，从而引导面试方向；另外一个则是要简单介绍一下自己使用 Kafka 解决过什么问题，最好就是用一个复杂方案中的 Kafka 来介绍，从而将话题引导到那个复杂的解决方案上。
略难的题。其实这个题有歧义，有些面试官可能指的是 Kafka 自身有什么缺点，有些面试官可能是指你用 Kafka 来解决问题有什么缺点。
这个问题回答起来也不是特别难的，而且根据你回答的点，可以将话题引导过去不同的点上，从而刷出亮点。
简单的题，高频考题。之所以说这个是简单的题，是因为问得太多以至于差不多人人都会了。
回答这个问题的要点在于区分清楚全局有序和单一业务内部有序这两种情况，而要刷出亮点，则要在顺序消息的基础上进一步讨论顺序消息积压的问题，或者说引出我给你准备的顺序消息积压的解决方案。
略难的题，不太常问。
回答这个问题的最大的关键点就是要指出 Kafka 同一个分区的消息是有序的，但是不同的分区的消息是无序的，从而将话题引导过去如何保证消息有序上，进一步引出你的解决方案。
略难的题。不过这个问题很少面到，因为很少有面试官会用全局有序的消息模型。
记住，回答所有的有序消息的怎么解决的问题，你就从这个问题 Kafka 中消息积压了怎么办？ (meoying.com) 的解决方案里面挑选。
略难的题，高频题目。
大部分人就只会回答异步消费什么的，但是这个方案属实有点烂大街了，毫无竞争力。你需要的做的是先区分是临时积压还是永久性积压。
回答这个问题的关键有两个，一个是要把你能记得的各种方案都讲一下；另外一个关键点是你要把话题引导过去顺序消息的消息积压解决方案上。
略难的题。一般来说面试官至多问到如何解决消息积压，但是很少会问顺序消息积压。
解决的顺序消息积压的思路也解决一般消息积压的思路差不多，只不过其中有些手段不能用到顺序消息上。
略难的题。大部分情况下，面试官都发现不了这个问题。
回答这个问题的思路也很简单，刷亮点则是要和哈希类的再平衡过程扯一起，并且结合 Redis 的策略来进行分析。
略难的题，高频问题。
要刷亮点你就需要综合比较不同中间件的高可用方案，当然也没什么好比的，毕竟能够做到高可用的解决思路就那么几个。
略难的题，不太常问。这个问题是指一个逻辑分区的主分区和从分区是怎么进行数据同步的。
说白了就是大部分的主从同步都是类似的，但是 Kafka 里面有一个特殊之处就是它引入了 ISR 的概念。所以你在回答的时候带出 ISR 这个概念，等待面试官追问就可以了。
此外还有一个可以引导的话题，就是数据同步对 acks=all 这个设置的影响。
简单的题，不算高频题目。
不同的中间件在 push 和 pull 模型中会做不同的决策，核心就是以谁为主。在这个问题之下，你要刷亮点就可以系统讨论 push 模型和 pull 模型在不同的中间件中的应用。而如果你要是设计过一些的复杂的中间件，也可以讨论自己设计的中间件使用的是 pull 模型还是 push 模型。
简单题，你要是用过 Kafka 就差不多会知道这个东西。
在这个题目之下刷亮点，就是要把话题引导过去写入语义上。也就是当你写入数据到一个分布式中间件的时候，你是希望写入到主节点，还是也要写入到从节点。而这一类的机制，是很常见的，基本上涉及到主从结构的中间件都有这个问题。
另外一个刷亮点的，就是你要讨论 acks 这个参数虽然定义了分布式下的写入语义，但是并没有定义怎么刷盘，所以即便是在 acks=all 的场景下依旧有数据丢失的可能，只不过非常罕见而已。
简单的题，在初中级工程师和校招面试中比较常见。
在这个题里面，你可以稍微提及消费者加入到消费者组中会引起 rebalance 的问题，但是不需要详细说，等着后续面试官追问。
略难的题，这个题目在 Kafka 里面不太常问。
可以先回答 rebalance 的基本定义，而后指出常见的触发 rebalance 的场景，并且指出常规的避免方案，而后可以谈及自己处理 rebalance 的经历。
略难的题，有些面试官为了恶心人会故意这么问。
当然如果你已经很熟悉我几次强调的写入语义的问题，也很熟悉 acks 参数的意义，那么这就是送分题。刷亮点，还是要立足在讨论分布式环境下的写入语义。
略难的题。如果你实践中没有真的落地过这个解决方案的话，你这里大概都不懂面试官问的是什么意思。
这个问题归根节点就是一句话，处理消息可能失败，所以就要考虑到如果异步消费偏移量较小的消息失败了，那么即便偏移量较大的消息即便消费成功了也不能提交，否则后面就没办法再次重新消费失败的消息。
略难的题。还是那句话，如果你要是实践中没有落地过，就有可能寄了。
这个问题有一个非常好的地方，就是你可以借助它将话题引导过去单个转批量这种常规的性能优化方案上。也就是说你在解决消息积压的时候要考虑凑不够一批的问题，那么你在设计单个转批量的性能优化方案的时候，同样要考虑凑不够一批怎么办。
略难的题。
回答这个问题你要刷亮点，可以先讨论在分区设置不同延迟消息的解决方案下，如何解决 rebalance 问题，而后进一步阐述常规的一般的规避 rebalance 的解决思路。
分区方案的衍生问题，在分区方案中最后睡眠完了，怎么处理消息。是先提交消息呢，还是先转发呢？
你记住一个原则，就是在 Kafka 里面，但凡涉及到什么消息丢失，一致性之类的问题，最终都是要靠消费者幂等来解决的。
略难的题，Kafka 中的高频面试题，校招和初级都不太常见，中级比较常见。
这个问题之所以常见，核心就在于延迟消息作为业务场景很常见，偏偏 Kafka 却不支持，然而很多公司的消息中间件都是 Kafka，在这种情况下他们就会考察你相应的解决方案。
这里提及的主要的两个解决方案，从技术含量上来说应该是随机延迟消息含量高，所以你可以用这个方案来作为亮点，并且进一步引导话题。
难题，校招、初中级岗位基本不会遇到，遇到了答不出来也无所谓。
坦白来说你遇到的 1000 个面试官里面可能只有 1 个真的解决过这个问题，剩下的都是在装逼。你只要把方案说出来，以及对应的各种变种说出来就能赢得极大的竞争优势了。
简单题，Kafka 支持延迟消息的解决方案中你必须要掌握的一种。
在这个问题之下，你要刷亮点就可以深入讨论 rebalance 的问题和一致性问题，更进一步则可以讨论极端情况下分区消息积压的问题，而消息积压本身也是一个非常热门的面试话题，所以效果会很好。
简单题。
一句话来说，就是你的业务需要多长就多长，没别的花招。
略难的题，校招和初级研发岗位不太常见，更高级别的岗位面试中会比较常见。
在这个问题之下，可以通过重复消息问题、性能优化、高并发大数据下怎么支持随机延迟时间来刷亮点。
略难的题。校招不常见，在社招中如果回答消息积压之类的问题提到了异步消费之后，就很容易遇到这个问题。
在这个问题之下，你可以想到，大部分人只能回答出来重试。所以如果你要是能够回答出来部分提交、转储、以及在重试的时候去重就可以刷出亮点，赢得竞争优势。
简答题，校招和初级岗位面试中常见。
简答题，校招和初中级岗位面试中常见。
