|
|
memcached采用的網(wǎng)絡(luò)模型是早前提到的半同步半異步的網(wǎng)絡(luò)模型.
簡單的說,大致流程就是:主線程負(fù)責(zé)接收新的連接,接收到新的連接之后,選擇一個(gè)worker副線程,將該新連接push到副線程的連接隊(duì)列中.主副線程之間通過管道進(jìn)行通訊,因此主線程將新的連接push到工作線程之后,主線程要向該副線程的管道中寫一個(gè)字符,而每個(gè)副線程也都有自己的poll set, 其中會包含自己的管道fd, 副線程也會通過多路復(fù)用I/O來監(jiān)控管道的情況,一旦可讀,說明有新的連接到來,此時(shí)從連接隊(duì)列中取出新連接,將其fd加入到自身的poll set中,最后對該連接的業(yè)務(wù)邏輯處理也全都在該副線程中進(jìn)行(讀數(shù)據(jù),處理,發(fā)送回應(yīng)等).
這個(gè)模型有以下的好處:
1) 接收操作只在主循環(huán)中處理,因此不會出現(xiàn)驚群現(xiàn)象.
2) 主副線程分工明確, 主線程僅負(fù)責(zé)I/O, 副線程負(fù)責(zé)業(yè)務(wù)邏輯處理.我認(rèn)為這個(gè)可以抽象出來作為一般服務(wù)器的網(wǎng)絡(luò)I/O架構(gòu), 以后要使用的時(shí)候只需要將業(yè)務(wù)邏輯處理函數(shù)傳遞進(jìn)行就好了.簡單的說,就是主線程負(fù)責(zé)接客,副線程負(fù)責(zé)服務(wù).
3) 多個(gè)副線程之間不會有影響.因?yàn)榇蠹叶加懈髯元?dú)立的連接隊(duì)列.主線程在新連接到來的時(shí)候是如何選擇處理副線程的呢?很簡單,有一個(gè)計(jì)數(shù)器last_thread, 每次將last_thread加一,再模線程數(shù)來選擇線程ID.
缺點(diǎn)是:
假如業(yè)務(wù)邏輯是類似于web服務(wù)器之類的, 那么一個(gè)簡單的請求也需要這個(gè)比較繁瑣的操作的話(最重要的是,很可能一個(gè)進(jìn)程就能處理完的事情,非得從一個(gè)線程接收再到另一個(gè)線程去處理), 那么顯然代價(jià)是不值得的.所以說,所謂的服務(wù)器網(wǎng)絡(luò)模型的選擇, 其實(shí)沒有一套通吃的方案, 還是按照具體的業(yè)務(wù)邏輯具體來分析吧.
需要補(bǔ)充的是,主副線程之間相互通信采用的管道,現(xiàn)在新版的linux內(nèi)核已經(jīng)提供一種新的API:eventfd(),簡單的說,有以下好處:1)管道需要分配兩個(gè)fd,一個(gè)讀一個(gè)寫,而eventfd一個(gè)fd就搞定了. 2) 管道需要不定長的緩沖區(qū),往里面寫數(shù)據(jù)才能通知讀一端有數(shù)據(jù)到來,而eventfd現(xiàn)在可以使用定長的數(shù)據(jù)了. 3) 最后,聽說eventfd性能上比管道要好,這個(gè)沒有做過測試了.反正, 對于簡單的類似上面分析的那樣通知機(jī)制, 用管道似乎太"重量級"了一點(diǎn).
eventfd的man page在此.
|