kafka源码解析之八：Broker分析

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替换老的：