nginx併發模型與traffic_server併發模型簡單比較

ginx併發模型：
nginx 的進程模型採用的是prefork方式，預先分配的worker子進程數量由配置文件指定，默認爲1，不超過1024。master主進程建立監聽套接口，fork子進程之後，由worker進程監聽客戶鏈接，每一個worker子進程獨自嘗試accept已鏈接套接口，accept是否上鎖能夠配置，默認會上鎖，若是操做系統支持原子整型，纔會使用共享內存實現原子上鎖，不然使用文件上鎖。不使用鎖的時候，當多個進程同時accept，當一個鏈接來的時候多個進程同時被喚起，會致使驚羣問題。使用鎖的時候，只會有一個worker阻塞在accept上，其餘的進程則會不能獲取鎖而阻塞，這樣就解決了驚羣的問題。master進程經過socketpair向worker子進程發送命令，終端也能夠向master發送各類命令，子進程經過發送信號給master進程的方式與其通訊，worker之間經過unix套接口通訊。

模型以下圖：

 

Traffic server併發模型：多線程異步事件處理
traffic_cop和traffic_manager做爲管理進程，工做進程爲traffic_server，traffic_server負責listen和accept，爲提升性能，traffic_server使用了異步I/O和多線程技術。Traffic Server並非爲每一個鏈接都創建一個線程，而是事先建立一組數量可配置的工做線程，每個工做線程上都運行着獨立的異步事件處理程序。traffic_server建立若干組Thread，並將Event按類型調度到相應的Thread的Event隊列上，Thread經過執行Event對應的Continuation中的回調函數，來完成狀態的遷移。從初始態到終止態的遷移表明了整個事件的執行過程，而Thread是永不退出的，等待着下一個事件的到來。模型以下圖：

 

兩種服務器都涉及到網絡I/O操做，nginx使用的是linux的epoll模型，traffic server使用異步I/O，因爲對於I/O不熟悉，這份就不作深刻對比。都使用預分配機制，nginx預分配worker進程，traffic server 預分配工做線程。

對比分析：

 

1.併發度：

nginx使用的多進程併發模型，採用多進程監聽新鏈接，爲此它不須要分發操做，可是引入鎖來保持同步，捨去了分發的開銷，可是引入了鎖的開銷。實際中鎖的開銷比較小，若是系統支持原子整形，那麼鎖的開銷會進一步下降；經過worker進程本身主動去accept，這也會讓各個worker進程的負載量比較均衡，這依賴於系統內核對進程的公平的調度。worker進程也能夠配置成使用線程進行事件處理工做，但模型上仍是屬於多進程併發，由於線程須要從進程這裏取到事件。這種設計有一個缺陷，worker進程的數量不能太多，nginx設計的worker進程數量的最大值爲1024，太多的worker進程會致使進程之間競爭資源頻繁，使系統運行緩慢。可見nginx被設計成輕量級的web服務器，可是做爲輕量級的web服務器，它有着很是好的性能表現，有報告代表能支持高達 50,000個併發鏈接數。nginx不愧是輕量級web反向代理服務器的首選。

而traffic server使用多線程異步事件處理模型:將多線程技術與異步事件處理技術結合在一塊兒來提升併發和性能。多線程程序能夠充分利用現代處理器多核的處理能力，使一個進程的多個任務能夠並行執行，提升程序執行的效率。這種多線程的設計也讓traffic server的性能與處理器的性能一直成正比，不會像nginx收到worker進程數目的約束。它不是做爲輕量級的web服務器而設計的，它支持集羣，Apache Traffic Server v.3.0.0基準測試的結果是每秒鐘能夠處理200,000多個請求，可見traffic server不愧是高性能的web服務器，我的認爲這款服務器將會是之後的發展趨勢。

2.響應時間

nginx採用的是worker進程獨立accept而直接進行處理的方式處理客戶請求，所以nginx的響應速度應該是很快的，我的以爲應該比traffic server服務器要更快。

traffic server是server進程接受請求，而後分發到請求隊列中，再由處理線程進行處理，因此理論上響應時間沒有nginx快。

網絡上的測試文檔有代表在請求靜態網頁的時候，響應速度時間約爲5:7，（網上數據，本人沒有測試），和分析相符。

3.穩定性

nginx因爲是不少可以獨立工做的worker進程在工做，當其中的某個或一些worker進程異常時不影響系統的正常工做。master進程在初始化worker進程之後就在循環體中檢測信號，而後處理信號，因爲master進程一直會比較穩定，當它發現worker進程異常時，又會去重啓該worker進程，並且還會檢查其餘worker進程。可見nginx的這種設計容錯性是很高的。

traffic server中因爲server是工做進程，並且只有一個，所以系統要保障它的正常運行。爲此係統添加了traffic_cop進程與traffic_manager進程來管理server進程，給server進程加上了雙重的保障，當server異常時，traffic_manager進程會及時的重啓它，並且在重啓的過程當中還會繼續利用traffic_manager進程來接受客戶請求，這是個不錯的設計。當traffic_manager進程和sever進程同時異常結束的時候，traffic_cop又會重啓它們，所以系統的穩定性也是很高的。

因爲traffic server重啓的過程當中沒法繼續服務，所以穩定性上nginx要賽過traffic server。

4.峯值響應

web服務器都很關心當一小段時間內有大量的鏈接請求的時候服務器的響狀況的。

nginx因爲是多個worker進程工做，大量請求來的時候各個worker的負載會比較均勻分佈，當峯值太高時，會致使worker進程調度延遲，也就會阻塞客戶請求，說明服務器的處理能力會阻塞客戶請求，它們之間會存在一個約束關係。另外而Nginx採起了分階段資源分配技術，由cache manager進程和cache loader 進程處理，這種設計也會使得nginx在遇到峯值請求的時候不輕易的將內存耗盡，不容易形成系統在過載請求下異常結束。

traffic server使用server進程接收到大量的用戶請求後會發送到請求隊列，而後線程在處理的時候會形成數據量過大，容易內存耗盡，出現異常致使server進程也退出，雖然會很快的重啓該進程（官方文檔說重啓只須要幾秒鐘），並且重啓的過程當中還會由manager進程繼續接受請求，可是系統卻在這段時間內沒法處理請求，可是nginx不會中止處理請求。（traffic server沒有集羣的狀況下）

分析說明在短期爆發性訪問的時候nginx的響應能力要優於traffic server。這裏說的過載請求量是針對它們各自不一樣的請求量，好比nginx處理能力爲50000鏈接，那麼它的峯值就是50000，它們的反應僅是針對各自的峯值請求。可是traffic server支持集羣，這將會很大程度的的提升其峯值響應能力。

5.安全性

nginx對於安全性作的工做很少，惡意鏈接攻擊可能會致使worker進程耗盡系統資源而中止響應，雖然master進程會檢測並嘗試重啓，若是master進程也是去響應，那麼系統就須要重啓。可是nginx採用分階段資源分配技術，系統很難會耗盡所有的資源而是去響應，所以通常的dos攻擊對於nginx是沒什麼效果的。整體來講安全性通常。

traffic server在安全性方面作了不少工做，系統會週期性調用heartbeat_manager函數和heartbeat_server函數來檢查manager進程和server進程的健康情況，發現不正常時則會當即重啓響應的異常進程。並且一旦server進程異常結束，也會很快被重啓。所以當收到攻擊的時候，traffic server會比較及時的做出反應，系統安全性比較高。

總結：我的認爲nginx是多進程併發模型的典範，而traffic server是多線程異步事件處理模型的典範，各有其優缺點。nginx是一款優秀的輕量級web服務器，適合處理請求很少的狀況；traffic server則是一款高性能web服務器，還支持集羣，更適合處理大量請求鏈接的狀況。