Broker主要由SocketServer(Socket服务层),KafkaRequestHandlerPool(请求转发层),Kafka api(业务逻辑层),Control(集群状态控制层),KafkaHealthcheck Broker (Broker健康检测层),TopicConfigManager(topic配置信息监控层)组成。见下图:
● SocketServer内部开启1个Acceptor线程接受对外的sock链接,然后转发给N个处理线程Processor,其中N=num.network.threads
● N个Processor将接受到的request存放至阻塞队列requestQueue
● M个处理线程 IO Thread从RequestChannel的请求阻塞队列requestQueue获取请求,调用kafkaApis处理不同的请求,M=num.io.threads
● Broker共处理10种不同的request,分别为RequestKeys.ProduceKey、RequestKeys.FetchKey、RequestKeys.OffsetsKey、RequestKeys.MetadataKey 、RequestKeys.LeaderAndIsrKey、RequestKeys.StopReplicaKey、
RequestKeys.UpdateMetadataKey、RequestKeys.ControlledShutdownKey、RequestKeys.OffsetCommitKey、RequestKeys.OffsetFetchKey。
● KafkaApis(业务逻辑处理层)通过ReplicaManager(副本管理模块),logManager(日志模块),OffsetManager(偏移量管理模块)共同实现正常的业务逻辑
● IO Thread将request处理过的response存放进RequestChannel的响应阻塞队列responseQueues[i]
● Processor Thread从对应的RequestChannel的响应阻塞队列responseQueues[i]获取之前自己发送的request,然后发送给客户端
● Control(集群状态控制层)通过ZK选举改变自身的状态,集群中只有1台broker成为leader,主要负责应对topic的创建和删除,topic的分区变化,topic的分区内部的复本变化,broker的上下线。
● KafkaHealthcheck(Broker 健康状态监测层)通过在ZK上注册EphemeralPath来实现
● TopicConfigManager(topic配置信息监控层)主要响应topic的配置信息的变化
原创文章,作者:Maggie-Hunter,如若转载,请注明出处:https://blog.ytso.com/tech/pnotes/11824.html