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