半同步-半異步模式,最早應該是由ACE的作者提出,原文在這里.

簡而言之,所謂的半同步半異步模式分為三個組成模塊:同步處理模塊,隊列模塊,異步處理模塊.三個模塊之間的交互關系如圖:


(注:上圖出自這里)
幾個模塊的之間的交互為:異步模塊接收可能會異步到來的各種事件(I/O,信號等),然后將它們放入隊列中,而同步模塊一般只有一種動作,就是不停的從隊列中取出消息進行處理.

半同步-半異步模式的出現(xiàn)是為了給服務器的功能進行劃分,盡可能將的可能阻塞的操作放在同步模塊中,這樣不會影響到異步模塊的處理.
舉個例子說明.
假設現(xiàn)在有一個服務器,在接收完客戶端請求之后會去數(shù)據庫查詢,這個查詢可能會很慢.這時,如果還是采用的把接收客戶端的連接和處理客戶端的請求(在這里這個處理就是查詢數(shù)據庫)放在一個模塊中來處理,很可能將會有很多連接的處理響應非常慢.
此時,考慮使用半同步半異步的模式,開一個進程,使用多路復用IO(如epoll/select)等監(jiān)聽客戶端的連接,接收到新的連接請求之后就將這些請求存放到通過某種IPC方式實現(xiàn)的消息隊列中,同時,還有N個處理進程,它們所做的工作就是不停的從消息隊列中取出消息進行處理.這樣的劃分,將接收客戶端請求和處理客戶端請求劃分為不同的模塊,相互之間的通過IPC進行通訊,將對彼此功能的影響限制到最小.

然后,不是每種請求下都適合使用半同步半異步模式的.

我之前深入閱讀過ligty的代碼,它的設計是monitor+worker多進程 + 多路復用IO + 狀態(tài)機的架構.也就是說,每個worker進程負責接收客戶端連接和處理客戶端連接的全過程,每個過程都會記錄一個狀態(tài),比如現(xiàn)在在接收包頭,如果這次的接收不是因為連接關閉的原因導致的接收錯誤,那么就將這個客戶端的fd放入多路復用IO中,等待著下一次根據這次保存的狀態(tài)進入狀態(tài)機中進行處理.

簡單的說,在ligty中,一個worker子進程全權負責了接收和處理的全過程,并沒有按照上面半同步半異步的劃分來設計.

再后來,我大概看過一些nginx的代碼,細節(jié)之處可能不一樣,但是就服務器總體的架構而言,是與ligty的設計差不多的.

這兩個服務器是目前比較快的web服務器了,沒有采用多么復雜的模式.

那么為什么對于web服務器而言,不需要使用半同步半異步也可以達到非常高的效率呢?我想,這與服務器的業(yè)務有關.對于web服務器而言,大部分的時間都花在了IO處理上,比如監(jiān)聽服務器端口,接收客戶端連接,根據客戶端的請求發(fā)送文本文件內容到客戶端去,這里的操作,基本上沒有太可能會造成阻塞的地方,也就是說,處理完成一個客戶端請求的全過程對web服務器而言是非常快的.

所以,要回答這個問題,需要看具體的業(yè)務需求.打個比方,如果處理一個客戶端請求需要10s,那么完全有一個模塊全部處理不是一個很好的設計;反之,如果處理一個請求只需要10ms,而進程/線程間的切換就需要1s了,還將模塊進行劃分就不必了.

另外,回到半同步半異步模式的具體實現(xiàn)上,可以使用線程或者進程,而隊列層則可以使用不同的IPC方式,有很多關于多線程多進程孰優(yōu)孰劣的爭論,由于我沒有太多多線程的編程經驗,也就不在這里進一步說明了.