Kafka核心技术与实战 02，2024年最新spring框架面试问题

2401_84434301

于 2024-04-21 02:03:58 发布

阅读量233

点赞数 5

分类专栏： 2024年程序员学习文章标签： kafka spring 面试

本文链接：https://blog.csdn.net/2401_84434301/article/details/138017667

版权

2024年程序员学习专栏收录该内容

29 篇文章 0 订阅

订阅专栏

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

第二、如你所说，Redis和MySQL都支持主从读写分离，我个人觉得这和它们的使用场景有关。对于那种读操作很多而写操作相对不频繁的负载类型而言，采用读写分离是非常不错的方案——我们可以添加很多follower横向扩展，提升读操作性能。反观Kafka，它的主要场景还是在消息引擎而不是以数据存储的方式对外提供读服务，通常涉及频繁地生产消息和消费消息，这不属于典型的读多写少场景，因此读写分离方案在这个场景下并不太适合。

第三、Kafka副本机制使用的是异步消息拉取，因此存在leader和follower之间的不一致性。如果要采用读写分离，必然要处理副本lag引入的一致性问题，比如如何实现read-your-writes、如何保证单调读（monotonic reads）以及处理消息因果顺序颠倒的问题。相反地，如果不采用读写分离，所有客户端读写请求都只在Leader上处理也就没有这些问题了——当然最后全局消息顺序颠倒的问题在Kafka中依然存在，常见的解决办法是使用单分区，其他的方案还有version vector，但是目前Kafka没有提供。

最后、社区正在考虑引入适度的读写分离方案，比如允许某些指定的follower副本（主要是为了考虑地理相近性）可以对外提供读服务。当然目前这个方案还在讨论中。

因为mysql一般部署在不同的机器上一台机器读写会遇到瓶颈，Kafka中的领导者副本一般均匀分布在不同的broker中，已经起到了负载的作用。即：同一个topic的已经通过分区的形式负载到不同的broker上了，读写的时候针对的领导者副本，但是量相比mysql一个还实例少太多，个人觉得没有必要在提供度读服务了。（如果量大还可以使用更多的副本，让每一个副本本身都不太大）

1，kafka的分区已经让读是从多个broker读从而负载均衡，不是MySQL的主从，压力都在主上；

2，kafka保存的数据和数据库的性质有实质的区别就是数据具有消费的概念，是流数据，kafka是消息队列，所以消费需要位移，而数据库是实体数据不存在这个概念，如果从kafka的follower读，消费端offset控制更复杂；

3，生产者来说，kafka可以通过配置来控制是否等待follower对消息确认的，如果从上面读，也需要所有的follower都确认了才可以回复生产者，造成性能下降，如果follower出问题了也不好处理

\1. 首先Partition已经承担了Master-Slave的“高性能”功效。

\2. Follower的设计和存在，是为了“高可用”的目的，所以“高性能”的重担不在它的肩上。

\3. Leader是source of truth，所以读写都应该在leader上。

\4. 由于有__consumer_offsets的机制，每次读写都应该是在leader上，如果replica也参与了read服务，那么consumer offet就乱了。

重平衡故事

整个故事是这样的：假设C1消费P0,P1, C2消费P2,P3。如果C1从未提交，C1挂掉，C2开始消费P0,P1，发现没有对应提交位移，那么按照C2的auto.offset.reset值决定从那里消费，如果是earliest，从P0，P1的最小位移值（可能不是0）开始消费，如果是latest，从P0, P1的最新位移值（分区高水位值）开始消费。但如果C1之前提交了位移，那么C1挂掉之后C2从C1最新一次提交的位移值开始消费。

所谓的重复消费是指，C1消费了一部分数据，还没来得及提交这部分数据的位移就挂了。C2承接过来之后会重新消费这部分数据。

问个分区的问题，比如一个topic分为0，1，2 个分区

写入0到9条消息，按照轮训分布:

0分区：0，1，2，9

1分区：3，4，5，

2分区：6，7，8

那对于消费端来说，不管是p2p点对点模式，还是push/sub模式来说，

如何保证消费端的读取顺序也是从0到9？因为0到9条消息是分布在3个

分区上的，同时消费者是主动轮训模式去读分区数据的，

有没有可能读到后面写的数据呢？比如先读到5在读到4？

目前Kafka的设计中多个分区的话无法保证全局的消息顺序。如果一定要实现全局的消息顺序，只能单分区

1、 kafka是按照什么规则将消息划分到各个分区的？

2、既然同一个topic下的消息分布在不同的分区，那是什么机制将topic、partition、record关联或者说管理起来的？

\1. 如果producer指定了要发送的目标分区，消息自然是去到那个分区；否则就按照producer端参数partitioner.class指定的分区策略来定；如果你没有指定过partitioner.class，那么默认的规则是：看消息是否有key，如果有则计算key的murmur2哈希值%topic分区数；如果没有key，按照轮询的方式确定分区。

\2. 这个层级其实是逻辑概念。在物理上还是以日志段（log segment）文件的方式保存，日志段文件在内存中有对应的Java对象，里面关联了你说的这些。

1个分区只能同时被1个消费者消费，但是1个消费者能同时消费多个分区是吗？那1个消费者里面就会有多个消费者位移变量？

如果1个主题有2个分区，消费者组有3个消费者，那至少有1个消费者闲置？

在一个消费者组下，一个分区只能被一个消费者消费，但一个消费者可能被分配多个分区，因而在提交位移时也就能提交多个分区的位移。

针对你说的第二种情况，答案是：是的。有一个消费者将无法分配到任何分区，处于idle状态。

假如只有一个Producer进程，Kafka只有一分区。Producer按照1，2，3，4，5的顺序发送消息，Kafka这个唯一分区收到消息一定是1，2，3，4，5么？ Producer端，网络，数据格式等因素，会不会导致Kafka只有一个分区接收到数据顺序跟Producer发送数据顺序不一致

如果retries>0并且max.in.flight.requests.per.connection>1有可能出现消息乱序的情况

分区数量一开始定义后，后面可以增加分区后，原来分区的数据应该不会迁移吧？分区数量可以减少吗？

不会自动迁移，需要你手动迁移。分区数不可以减少

Kafka可以关闭重平衡吗？

使用standalone consumer就完全避免rebalance了。事实上很多主流大数据流处理框架（Spark、Flink）都是这么使用的

一个分区的N个副本是在同个Broker中的吗，还是在不同的Broker中，还是说是随机的？

一个分区的N个副本一定在N个不同的Broker上。

\1. leader 副本分布在哪个broker上随机的吗？还是有什么机制

\2. 如文中最后一个图所示，假如broker1挂掉，broker2上的follower副本会变为leader副本吗？假如不止一个follower副本，是不是有某种选举方式来决定哪个follower副本会升级为leader副本？

\1. 有算法，不是随机的。其实不只是leader，整个副本在broker上的分配策略大体上都遵循轮询的公平法则。

\2. 从follower中选择leader的算法如下：

2.1 从ISR中选择存活的第一个副本为新leader

2.2 如果ISR为空，看是否开启了unclean leader选举，如果没有开启，那么Kafka干脆就不选leader了，直接将分区置于不可用状态；否则Kafka就从剩下的存活副本中选第一个副本作为leader（这里的顺序就是ZooKeeper中保存的副本集合顺序，即assigned_replicas项）

客户端会首先请求topic分区的leader副本在哪个broker上，

客户端发送Metadata请求获取每个topic分区的leader，之后再发送真实的数据请求（Produce请求或Fetch请求）

Kafka不能推送消息给consumer。Consumer只能不断地轮训去获取消息。从Kafka流向consumer的唯一方式就是通过poll。另外维持一个长连接去轮训的开销通常也没有你想的那么大，特别是Kafka用的是Linux上的epoll，性能还不错，至少比select好。
怎么使用自带带shell脚本获取到某个topic的当前最新的offset位置

bin/kafka-run-class.sh kafka.tools.GetOffsetShell

offset保存在broker端的内部topic中，不是在clients中保存
replica的leader和follower之间如何复制数据保证消息的持久化的问题

1.生产者消息发过来以后，写leader成功后即告知生产者成功，然后异步的将消息同步给其他follower，这种方式效率最高，但可能丢数据；2.同步等待所有follower都复制成功后通知生产者消息发送成功，这样不会丢数据，但效率不高；3.折中的办法，同步等待部分follower复制成功，如1个follower复制成功再返回，这样兼顾效率和消息的持久化。具体选择哪种要根据业务情况进行选择。说的不对的地方请老师斧正。

目前Kafka不支持第三种“折中”办法。。。要么只写leader，要么所有follower全部同步。但是，我同意很多分布式系统是可以配置同步follower和异步follower共存的，比如一个同步follower+N-1个异步follower的伪同步。Facebook的MySQL就是这个原理，参见http://yoshinorimatsunobu.blogspot.com/2014/04/semi-synchronous-replication-at-facebook.html