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替換老的：
任務調度 Kafka
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
