版權(quán)聲明：本文為博主原創(chuàng)文章唠摹，未經(jīng)博主允許不得轉(zhuǎn)載赌莺。
摘要
Kafka作為一個高性能的消息中間件赃绊，其高效的原因可以歸納為以下這幾個方面：
- 高性能服務(wù)器模型
- PageCache
- Zero－Copy
本文將從源碼層面（基于0.8.2.X）介紹Broker的高性能服務(wù)器模型是如何實(shí)現(xiàn)的胸梆。
高性能服務(wù)器模型
Kafka并沒有采用netty或mina等第三方網(wǎng)絡(luò)應(yīng)用框架悔常，而是直接了當(dāng)?shù)氖褂昧薔IO來實(shí)現(xiàn)服務(wù)器，并在使用了IO多路復(fù)用以及多線程Reactor模式旋讹，這種設(shè)計(jì)的優(yōu)勢是很容易實(shí)現(xiàn)瑰钮，同時也很快冒滩。
官方并沒有在服務(wù)器設(shè)計(jì)上詳細(xì)展開，因此本文將從邏輯結(jié)構(gòu)和源碼方面來分析這個方面的設(shè)計(jì)浪谴，借此了解一下NIO服務(wù)器設(shè)計(jì)的方法及一些細(xì)節(jié)旦部。
SocketServer作為Kafka的NIO服務(wù)器實(shí)現(xiàn)祈搜，其邏輯結(jié)構(gòu)圖如下：
重要組件
Acceptor線程：主要負(fù)責(zé)監(jiān)聽并接受客戶端（包括但不限于Producer，Consumer士八，Broker，Controller梁呈，AdminTool）的連接請求婚度，新連接建立以后指定某個Processor去處理。
-
Processor線程：負(fù)責(zé)數(shù)據(jù)讀寫官卡，連接關(guān)閉的處理線程蝗茁，其數(shù)目由配置num.network.threads決定，默認(rèn)是3個寻咒。每個Processor內(nèi)部都有自己的newConnections隊(duì)列和selector哮翘。
- newConnections：一個無界的SocketChannel隊(duì)列，存放新建立的連接毛秘，將Acceptor與Processor的功能解藕饭寺。
- selector：只使用一個selector來支撐大量連接的事件管理很容易遇到瓶頸，而多個selector并存的結(jié)構(gòu)可以均衡的管理大量連接叫挟。
-
RequestChannel：包含一個RequestQueue和多個ResponseQueue艰匙。它是網(wǎng)絡(luò)層與API層交換數(shù)據(jù)的地方，同時也使得兩者邏輯解藕和異步化抹恳。
- RequestQueue：所有的請求都會被封裝成Request并放入RequestQueue中员凝，隊(duì)列大小默認(rèn)500。
- ResponseQueue：每個Processor都會有對應(yīng)ResponseQueue奋献，KafkaApis業(yè)務(wù)邏輯處理完成后健霹，會將返回結(jié)果封裝成Response，接著由相應(yīng)的Processor來處理該response瓶蚂。而且設(shè)計(jì)上必須保證一對Request和Response都要由同一個Processor來處理糖埋，因?yàn)橹挥羞@個Processor擁有該通信連接。
KafkaRequestHandler線程：這是真正的業(yè)務(wù)邏輯處理線程扬跋，其數(shù)目由配置num.io.threads決定阶捆，默認(rèn)是8個。每個Handler線程都在不斷的從RequestChannel.RequestQueue中獲取新的請求钦听，那些負(fù)載輕的線程才有可能搶到新的請求洒试，因?yàn)樨?fù)載重的線程（也許正在進(jìn)行IO）還沒有空閑來接受下一個新的請求，所以這也算一個潛在的負(fù)載均衡策略吧朴上。
KafkaApis：Broker的所有業(yè)務(wù)邏輯都定義在這里垒棋，其handle方法會根據(jù)Request對象的requestId（對應(yīng)各種業(yè)務(wù)邏輯，其定義可以在類RequestKeys中看到）痪宰，將請求分發(fā)給對應(yīng)的業(yè)務(wù)邏輯處理方法叼架。當(dāng)處理完成以后畔裕，可能會將處理結(jié)果封裝成Response返回給對應(yīng)的RequestChannel.ResponseQueue。
總結(jié)
這一節(jié)主要是從總體上介紹了Broker服務(wù)器模型的各種重要的組件乖订，下一節(jié)我們將結(jié)合源碼分析一下請求處理的流程:
深入理解Kafka設(shè)計(jì):高性能服務(wù)器模型（2）
