图标不正常怎么办呢(图标出不来怎么回事)
727
2022-05-29
1 Broker分析
1.1 Broker internals视图
1.2 Network Layer
Kafka使用NIO自己实现了网络层的代码, 而不是采用netty, mina等第三方的网络框架。从性能上来讲,这一块的代码不是性能的瓶颈。
它采用IO多路复用和多线程下的Reactor模式,主要实现类包括SocketServer, Acceptor, Processor和RequestChannel。
Kafka的服务器由SocketServer实现,它是一个NIO的服务器,线程模型如下:
l 1个Acceptor线程负责处理新连接
l N个Processor线程, 每个processor都有自己的selector,负责从socket中读取请求和发送response
l M个Handler线程处理请求,并产生response给processor线程
可以从上面的图形中看到Acceptor, Processor和Handler的功能
1. Boker在启动的时候会调用SocketServer的startup方法如下。它为每个Processor生成一个线程并启动,然后启动一个Acceptor线程
2. Acceptor是一个典型NIO 处理新连接的方法类
3. 将新的连接均匀地分配给一个Processor。通过accept方法配置网络参数,并交给processor读写数据
4. Processor的accept方法将新连接加入它的新连接待处理队列中
5. Processor线程的主处理逻辑如下, 这是一个死循环,会一直处理这些连接的读写,这也是一个标准的NIO的处理代码
2.1 API Layer
API层的主要功能是由KafkaApis类实现的。
根据配置Kafka生成了一组KafkaRequestHandler线程,叫做KafkaRequestHandlerPool:
遗留问题: 多个线程并发处理请求,如何保证message的读写的顺序性。
KafkaRequestHandler不断的从requestChannel队列里面取出request交给apis处理
apis根据不同的请求类型调用不同的方法进行处理。
显然,此处处理的速度影响Kafka整体的消息处理的速度。
这里我们分析一个处理方法handleProducerRequest。
这里会调用replicaManager.appendMessages处理Kafka message的保存和备份,也就是leader和备份节点上。
这里会调用replicaManager.appendMessages处理Kafka message的保存和备份,也就是leader和备份节点上。
3.1 Replication Subsystem
顺藤摸瓜,我们进入replicaManager.appendMessages的代码。
这个方法会将消息放到leader分区上,并复制到备份分区上。在超时或者根据required acks的值及时返回response。
遗留问题: 对于同步Producer的写,是否阻塞 API 层的处理线程 ?
4.1 Log Subsystem
LogManager负责管理Kafka的Log(Kafka消息), 包括log/Log文件夹的创建,获取和清理。它也会通过定时器检查内存中的log是否要缓存到磁盘中。重要的类包括LogManager和Log。
5.1 OffsetManager
负责管理offset,提供offset的读写。
6.1 TopicConfigManager
它负责动态改变Topic的配置属性。
如果某个topic的配置属性改变了,Kafka会在ZooKeeper上创建一个类似/brokers/config_changes/config_change_13321的节点, topicConfigManager会监控这些节点, 获得属性改变的topics并处理,实际上以新的LogConfig替换老的:
任务调度 Kafka
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。