先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7
深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
如果你需要这些资料，可以添加V获取：vip1024b （备注Java）
正文
面试官：那合并之后的消息，什么时候会给broker？
我：合并的消息会在缓冲区内，如果缓冲区快满了或者一段时间内没有生产消息了，那么就会把消息发给broker。
面试官：那你知道消息压缩吗？
我：知道一点，压缩是利用cpu时间来节省带宽成本，压缩可以使数据包的体积变得更小，生产者负责将数据消息压缩，消费者拿到消息后自行解压。
面试官：所有只有生产者可以压缩？
我：不是的，broker也可以压缩，当生产者指定的压缩算法和broker指定压缩算法的不一样的时候，broker会先按照生产者的压缩算法解压缩一下，然后再按照自己的压缩算法压缩一下，这是需要注意的，如果出现这种情况会影响整体的吞吐。还有就是新老版本的问题，如果新老版本的压缩算法不兼容，比如broker版本比较老，不支持新的压缩算法，那么也会发生一样的事情。
面试官：我们知道kafka的消息是要写入磁盘的，磁盘IO会不会很慢？
我：是这样的，kafka的消息是磁盘顺序读写的，有关测试结果表明，一个由6块7200r/min的RAID-5阵列组成的磁盘簇的线性（顺序）写入速度可以达到 600MB/s，而随机写入速度只有 100KB/s，两者性能相差6000倍。操作系统可以针对线性读写做深层次的优化，比如预读（read-ahead，提前将一个比较大的磁盘块读入内存）和后写（write-behind，将很多小的逻辑写操作合并起来组成一个大的物理写操作）技术。顺序写盘的速度不仅比随机写盘的速度快，而且也比随机写内存的速度快。
面试官：顺序读写是为了解决了缓慢的磁盘问题，那在网络方面还有其他的优化吗？
我：有，零拷贝，在没有零拷贝的时候，消息是这样交互的：
-
切到内核态：内核把磁盘数据copy到内核缓冲区
-
切到用户态：把内核的数据copy到用户程序
-
切到内核态：用户数据copy到内核socket缓冲区
-
socket把数据copy给网卡
可以发现一份数据经过多次copy，最终兜兜转转又回到了内核态，实属浪费。
当有了零拷贝之后：
-
磁盘数据copy到内核缓冲
-
内核缓冲把描述符和长度发给socket，同时直接把数据发给网卡
可以发现通过零拷贝，减少了两次copy过程，大大降低了开销。
可靠篇
面试官：（关于性能方面的问的差不多了，接下来换换口味吧），kafka的多消费者模型是怎么做到的？
我：如果要支持多个消费者同时消费一个topic，最简单的方式就是把topic复制一份，但这无疑会浪费很多空间，尤其在消费者很多的情况下，
于是kafka设计出一套offset机制，即一份数据，不同的消费者根据位置来获取不同的消息即可。
面试官：那你知道消费者的offset存在哪吗？
我：很久以前，是存在zookeeper中的，但是offset需要频繁更新，zookeeper又不适合频繁更新，所以后来就把消费者位移存在了一个叫_consumer_offset的topic中，这个topic会在第一个消费者启动的时候自动创建，默认50个分区，3个副本。
面试官：那你说说这个_consumer_offset里面具体存了什么？
我：这里其实主要分为key和value，value可以简单的认为就是我们的消费者位移，关于key，这里要细说下，由于每个消费者都属于一个消费者组，并且每个消费者其实消费的是某个topic的分区，所以通过group-topic-partition就可以关联上对应的消费者了，这也就是key的组成。
面试官：那你能介绍下消费者提交位移的方式吗？
我：这里分为自动提交和手动提交。自动提交的话，就不需要我们干预，我们消费完消息后，kafka会自动帮我们提交，手动提交的话，就需要我们在消费到消息后自己主动commit。
面试官：自动提交会有什么问题？
我：自动提交的策略是consumer默认每隔5秒提交一次位移，如果consumer在接下来的很长时间内都没有数据消费，那么自动提交策略就会一直提交重复的位移，导致_consumer_offset有很多重复的消息。
面试官：那这有什么解决方案吗？
我：有，这种情况的核心问题就是可能会有大量的、重复的位移消息占用存储空间，只要把重复的去掉即可，kafka提供一种类似redis的aofrewrite的功能，叫compact策略，compact是由一个logCleaner线程来完成的，它会把重复的、并且较老的消息清除掉。
面试官：那如果consumer自动重启了，位移没来的及提交咋办？
我：这个会造成重复消费，一般业务上需要配合做幂等。
面试官：那手动提交能解决这个问题吗？
我：不能，如果我们在业务处理完之后手动提交，但是在还没得及提交的情况下，也发生了重启或者其他原因导致提交不上去，在消费者恢复后也会发生重复消费。
面试官：那如果我是先提交，后处理业务逻辑呢？
我：这种情况也不能保证100%没问题，如果提交成功，但是处理业务时出错，正常来说，这时希望重新消费这条数据是不行的，因为已经提交了，除非你重置offset。总之无论哪种方案都不能保证100%的完美，我们需要自己根据业务情况做幂等或者根据log来找到丢失的数据。
面试官：消费者提交消费位移时提交的是是当前消费到的最新消息的offset还是offset+1？
我：offset+1。
面试官：从生产者的角度谈谈消息不丢失的看法。
我：关于消息丢失问题，kafka的生产者提供了3种策略来供使用者选择，每种策略各有利弊，需要结合业务的实际状况来选择。
-
第一种就是生产者不关心消息的情况，只负责发，这种模式无疑速度是最快的，吞吐是最好的，但是可能造成大量的数据丢失，比如在borker出现问题的时候，生产者还不停的发，那么到broker恢复期间的数据都将丢失。
-
第二种就是生产者需要所有副本都写入成功，不管是Leader副本还是Follower副本，那么当Follower副本越多，吞吐理论就越差，但是这种模式下，消息是最安全的。
-
第三种就是生产者只需要收到Leader副本的ack即可，不用关心Follower副本的写入情况，它是个折中的做法，保证了一定的安全性的同时也不会太影响吞吐。
如果你不在意自己的数据丢失问题，追求吞吐，比如像log这种，可以采用第一种，如果你非常在意自己的数据安全性，那么就选第二种。如果你希望吞吐稍微好点，同时数据又能安全些，建议第三种，但是第三种在Follower副本出现的问题的时候对生产者来说是无法感知的。
面试官：那你说说一个Follower副本如何被选举成Leader的？
我：在kafka中有这样几个概念：
-
AR：所有副本集合
-
ISR：所有符合选举条件的副本集合
-
OSR：落后太多或者挂掉的副本集合
如何快速更新自己的技术积累？
- 在现有的项目里，深挖技术，比如用到netty可以把相关底层代码和要点都看起来。
- 如果不知道目前的努力方向，就看自己的领导或公司里技术强的人在学什么。
- 知道努力方向后不知道该怎么学，就到处去找相关资料然后练习。
- 学习以后不知道有没有学成，则可以通过面试去检验。
我个人觉得面试也像是一场全新的征程，失败和胜利都是平常之事。所以，劝各位不要因为面试失败而灰心、丧失斗志。也不要因为面试通过而沾沾自喜，等待你的将是更美好的未来，继续加油！
以上面试专题的答小编案整理成面试文档了，文档里有答案详解，以及其他一些大厂面试题目
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
。**
需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-j9uRjjOc-1713264441836)]
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
11万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
