【kafka】——分分钟看懂什么是kafka及其原理_kakfa是什么

最新推荐文章于 2024-07-17 17:05:03 发布

2401_84002803

最新推荐文章于 2024-07-17 17:05:03 发布

阅读量449

点赞数 18

分类专栏：程序员文章标签： kafka linq 分布式

本文链接：https://blog.csdn.net/2401_84002803/article/details/138364331

版权

程序员专栏收录该内容

207 篇文章 0 订阅

订阅专栏

本文详细介绍了Kafka架构中的Producer、Broker、Consumer之间的交互，包括消息发送、分区分配、Leader选举、消费模型、Offset管理和Rebalance流程。同时提及了与Java面试相关的内容，如各种技术专题和面试题库。

摘要由CSDN通过智能技术生成

对应关系

Kafka 架构中有多个 Producer，多个 Broker，多个 Consumer，每个 Producer 可以对应多个 Topic
Message是以topic为基本单位组织的，不同的topic之间是相互独立的，每个topic又可以分成不同的partition每个partition储存一部分

生产

创建一条记录，记录中一个要指定对应的topic和value，key和partition可选。先序列化，然后按照topic和partition，放进对应的发送队列中。kafka produce都是批量请求，会积攒一批，然后一起发送，不是调send()就进行立刻进行网络发包。(异步发送：将多条消息暂且在客户端buffer起来，并将他们批量的发送到broker，小数据IO太多，会拖慢整体的网络延迟，批量延迟发送事实上提升了网络效率。不过这也有一定的隐患，比如说当producer失效时，那些尚未发送的消息将会丢失)

kafka消息保存

根据Topic进行归类，发送消息者成为Producer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成，每个实例(server)都会成为broker。无论是kafka集群，还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。

partition的分配

将所有Broker（假设共n个Broker）和待分配的Partition排序
将第i个Partition分配到第（i mod n）个Broker上（这个就是leader）
将第i个Partition的第j个Replica分配到第（(i + j) mode n）个Broker上

Broker Controller(Leader)的选举

Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。（这个过程叫Controller在ZooKeeper注册Watch）。

这个Controller会监听其他的Kafka Broker的所有信息，如果这个kafka broker controller宕机了，在zookeeper上面的那个临时节点就会消失，此时所有的kafka broker又会一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。

例如：一旦有一个broker宕机了，这个kafka broker controller会读取该宕机broker上所有的partition在zookeeper上的状态，并选取ISR列表中的一个replica作为partition leader（如果ISR列表中的replica全挂，选一个幸存的replica作为leader; 如果该partition的所有的replica都宕机了，则将新的leader设置为-1，等待恢复，等待ISR中的任一个Replica“活”过来，并且选它作为Leader；或选择第一个“活”过来的Replica（不一定是ISR中的）作为Leader），这个broker宕机的事情，kafka controller也会通知zookeeper，zookeeper就会通知其他的kafka broker。

消费

消息由生产者发送到kafka集群后，会被消费者消费。一般来说我们的消费模型有两种:推送模型(psuh)和拉取模型(pull)。Kafka采取拉取模型(poll)，由自己控制消费速度，以及消费的进度，消费者可以按照任意的偏移量进行消费。比方消费者可以消费已经消费过的消息进行重新解决，或者者消费最近的消息等等。

订阅topic是以一个消费组来订阅的，一个消费组里面可以有多个消费者。同一个消费组中的两个消费者，不会同时消费一个partition。换句话来说，就是一个partition，只能被消费组里的一个消费者消费，但是可以同时被多个消费组消费。因此，如果消费组内的消费者如果比partition多的话，那么就会有个别消费者一直空闲。

Consumer处理partition里面的message的时候是顺序读取的。所以必须维护着上一次读到哪里的offset信息

offset的保存

一个消费组消费partition，需要保存offset记录消费到哪，以前保存在zk中，由于zk的写性能不好，以前的解决方法都是consumer每隔一分钟上报一次。这里zk的性能严重影响了消费的速度，而且很容易出现重复消费。
在0.10版本后，kafka把这个offset的保存，从zk总剥离，保存在一个名叫__consumeroffsets topic的topic中。写进消息的key由groupid、topic、partition组成，value是偏移量offset。topic配置的清理策略是compact。总是保留最新的key，其余删掉。一般情况下，每个key的offset都是缓存在内存中，查询的时候不用遍历partition，如果没有缓存，第一次就会遍历partition建立缓存，然后查询返回。

Broker coordinator的选举

生产过程中broker要分配partition，**消费过程这里，也要分配partition给消费者。类似broker中选了一个controller出来，消费也要从broker中选一个coordinator，用于分配partition。**每个Broker上都有一个GroupCoordinator的实例

看offset保存在那个partition
该partition leader所在的broker就是被选定的coordinator

reblance(均衡)流程

当partition或者消费者的数量发生变化时，都得进行reblance。列举一下会reblance的情况：

增加partition
增加消费者
消费者主动关闭
消费者宕机了
coordinator自己也宕机了

reblance流程：

consumer给coordinator发送JoinGroupRequest请求。
这时其他consumer发heartbeat请求过来时，coordinator会告诉他们，要reblance了。
其他consumer发送JoinGroupRequest请求。
所有记录在册的consumer都发了JoinGroupRequest请求之后，coordinator就会在这里consumer中随便选一个leader。然后回JoinGroupRespone，这会告诉consumer你是follower还是leader，对于leader，还会把follower的信息带给它，让它根据这些信息去分配partition
consumer向coordinator发送SyncGroupRequest，其中leader的SyncGroupRequest会包含分配的情况。
coordinator回包，把分配的情况告诉consumer，包括leader。

最后

即使是面试跳槽，那也是一个学习的过程。只有全面的复习，才能让我们更好的充实自己，武装自己，为自己的面试之路不再坎坷！今天就给大家分享一个Github上全面的Java面试题大全，就是这份面试大全助我拿下大厂Offer，月薪提至30K！

我也是第一时间分享出来给大家，希望可以帮助大家都能去往自己心仪的大厂！为金三银四做准备！
一共有20个知识点专题，分别是：