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