本文基本上這為兩篇文章的翻譯和整合 --
  Scalable networking And
  Why are event-driven server so great

傳統(tǒng)服務(wù)器模型如Apache為每一個(gè)請(qǐng)求生成一個(gè)子進(jìn)程。當(dāng)用戶連接到服務(wù)器的一個(gè)子進(jìn)程就產(chǎn)生，并處理連接。每個(gè)連接獲得一個(gè)多帶帶的線程和子進(jìn)程。當(dāng)用戶請(qǐng)求數(shù)據(jù)返回時(shí)，子進(jìn)程開(kāi)始等待數(shù)據(jù)庫(kù)操作返回。如果此時(shí)另一個(gè)用戶也請(qǐng)求返回?cái)?shù)據(jù)，這時(shí)就產(chǎn)生了阻塞。

這種模式在非常小的工作負(fù)荷是表現(xiàn)良好，當(dāng)請(qǐng)求的數(shù)量變得太大是服務(wù)器會(huì)壓力過(guò)于巨大。 當(dāng)Apache達(dá)到進(jìn)程的最大數(shù)量，所有進(jìn)程都變得緩慢。每個(gè)請(qǐng)求都有自己的線程，如果服務(wù)代碼使用PHP編寫(xiě)時(shí)，每個(gè)進(jìn)程所需要的內(nèi)存量是相當(dāng)大的[1]。

事實(shí)上，基于OPPC的網(wǎng)絡(luò)并不如想象中的高效。首先新建進(jìn)程的性能很大程度上依賴(lài)于操作系統(tǒng)對(duì)fork()的實(shí)現(xiàn)，然而不同操作系統(tǒng)的處理并非都理想。如圖為各操作系統(tǒng)fork()的延遲時(shí)間對(duì)比。

操作系統(tǒng)fork操作只是簡(jiǎn)單的拷貝分頁(yè)映射。動(dòng)態(tài)鏈接為共享庫(kù)和全局偏移表中的ELF（Executable and Linking Format）部分創(chuàng)建太多的分頁(yè)映射。雖然靜態(tài)的鏈接fork會(huì)是的性能大幅度提升，但是延時(shí)依然不樂(lè)觀。

圖 1 fork延時(shí)

Linux每10毫秒（Alpha是1毫秒，該值為已編譯常量）中斷一次在運(yùn)行態(tài)的進(jìn)程，查看是否要切換別的進(jìn)程執(zhí)行。進(jìn)程調(diào)度的任務(wù)就是決定下一個(gè)應(yīng)該執(zhí)行的進(jìn)程，而其難度就在于如何公平的分配CPU資源。一個(gè)好的調(diào)度算法應(yīng)該給每一個(gè)進(jìn)程都分享公平的CPU資源，而且不應(yīng)該出現(xiàn)饑餓進(jìn)程。

Unix系統(tǒng)采用多級(jí)反饋隊(duì)列調(diào)度算法。使用多個(gè)不同優(yōu)先級(jí)的就緒隊(duì)列，使用Heap保持隊(duì)列按優(yōu)先級(jí)順序排序。Linux 2.6版本提供了一個(gè)復(fù)雜度O(1)的調(diào)度算法，將進(jìn)程調(diào)度延時(shí)降至最小。但是進(jìn)程調(diào)度的頻率是100Hz，意味著10毫秒會(huì)中止一個(gè)進(jìn)程而判斷是否需要切換到另一個(gè)進(jìn)程。如果切換過(guò)多，會(huì)讓CPU忙于切換，導(dǎo)致降低吞吐量。

　　創(chuàng)建多進(jìn)程會(huì)帶來(lái)另外一個(gè)問(wèn)題：內(nèi)存消耗。

每一個(gè)創(chuàng)建的進(jìn)程都會(huì)占用內(nèi)存，在Linux 2.6中的測(cè)試結(jié)果，400個(gè)左右的連接后fork()的性能要超過(guò)pthread_create()的性能。IBM對(duì)Linux做過(guò)優(yōu)化后，一個(gè)進(jìn)程可以處理10萬(wàn)個(gè)連接。fork（）在每一個(gè)連接時(shí)都fork()一次成本太高，多線程在于需要考慮線程安全(thread-safe)與死鎖(deadlock)，以及內(nèi)存泄露問(wèn)題這些問(wèn)題。 　　

該模型具有可靠性問(wèn)題。一個(gè)配置不當(dāng)?shù)姆?wù)器，很容易遭受拒絕服務(wù)攻擊（DoS）。當(dāng)大量并發(fā)請(qǐng)求的服務(wù)器資源時(shí)，負(fù)載均衡配置不當(dāng)時(shí)服務(wù)器會(huì)很快耗盡源而奔潰。

在這個(gè)模型中，應(yīng)用程序執(zhí)行一個(gè)系統(tǒng)調(diào)用，這會(huì)導(dǎo)致應(yīng)用程序阻塞。這意味著應(yīng)用程序會(huì)一直阻塞，直到系統(tǒng)調(diào)用完成為止（數(shù)據(jù)傳輸完成或發(fā)生錯(cuò)誤）。調(diào)用應(yīng)用程序處于一種不再占用CPU，而只是簡(jiǎn)單等待響應(yīng)的狀態(tài)，但是該進(jìn)程依然占用著資源。當(dāng)大量并發(fā)I/O請(qǐng)求到達(dá)時(shí)，則會(huì)產(chǎn)生I/O阻塞，造成服務(wù)器瓶頸。

通過(guò)上訴分析與實(shí)驗(yàn)說(shuō)明，事實(shí)上，操作系統(tǒng)并不是設(shè)計(jì)來(lái)處理服務(wù)器工作負(fù)載。傳統(tǒng)的線程模型是基于運(yùn)行應(yīng)用程序是的一些密集型操作的需要。 操作系統(tǒng)的設(shè)計(jì)是讓用戶執(zhí)行的多線程程序，使后臺(tái)文件寫(xiě)入和UI操作同時(shí)進(jìn)行，而并不是設(shè)計(jì)于處理大量并發(fā)請(qǐng)求連接。

Fork和多線程是相當(dāng)費(fèi)資源的操作，創(chuàng)建線程需要分配一個(gè)全新的內(nèi)存堆棧。此外，上下文切換也是一項(xiàng)開(kāi)銷(xiāo)的，CPU調(diào)度模型是并不太適合一個(gè)傳統(tǒng)的Web服務(wù)器。

因此，OPPC模型面臨著多進(jìn)程多線程的延遲已經(jīng)內(nèi)存消耗的問(wèn)題。要用OPPC模型解決C10K問(wèn)題顯得十分復(fù)雜。

為解決C10K問(wèn)題，一些新的服務(wù)器呈現(xiàn)出來(lái)。下列是解決C10K問(wèn)題的Web服務(wù)器：

nginx：一個(gè)基于事件驅(qū)動(dòng)的處理請(qǐng)求架構(gòu)反向代理服務(wù)器。

Cherokee：Twitter使用的開(kāi)源Web服務(wù)器。

Tornado：一個(gè)Python語(yǔ)言實(shí)現(xiàn)的非阻塞式Web服務(wù)器框架。Facebook的FriendFeed模塊使用此框架完成。

Node.js：異步非阻塞Web服務(wù)器，運(yùn)行于Google V8 JavaScript引擎。

顯然以上解決C10K問(wèn)題的服務(wù)器都有著共同特點(diǎn)：事件驅(qū)動(dòng)，異步非阻塞技術(shù)。

由于網(wǎng)絡(luò)負(fù)載工作包括大量的等待。比如 Apache服務(wù)器，產(chǎn)生大量的子進(jìn)程，需要消耗大量?jī)?nèi)存。但大多數(shù)子進(jìn)程占用大量?jī)?nèi)存資源卻只是在等待一個(gè)阻塞任務(wù)結(jié)束。由于這一特點(diǎn)，新模型拋棄了對(duì)每個(gè)請(qǐng)求生成子進(jìn)程的想法。所有的請(qǐng)求和事物操作只使用一個(gè)多帶帶的線程管理，此線程被稱(chēng)之為事件循環(huán)。事件循環(huán)將異步的管理所有用戶連接與文件存儲(chǔ)或數(shù)據(jù)庫(kù)服務(wù)器。當(dāng)請(qǐng)求到達(dá)時(shí)，使用poll或者select喚醒操作系統(tǒng)對(duì)其請(qǐng)求做相應(yīng)處理。解決了很多問(wèn)題。這樣以來(lái)處理的并發(fā)請(qǐng)求不再是緊緊圍繞在阻塞資源。當(dāng)然，這樣也有一定的開(kāi)銷(xiāo)，如保持一個(gè)始終打開(kāi)的TCP連接的列表，但內(nèi)存并不會(huì)由于大量并發(fā)請(qǐng)求而急速上升，因?yàn)檫@個(gè)列表只占內(nèi)存堆上很小的一部分。Node.js和Nginx的都用這種方法來(lái)構(gòu)建應(yīng)用程序的規(guī)模超級(jí)大的連接數(shù)。一切操作都由一個(gè)事件循環(huán)管理，并很好地處理多個(gè)連接[4]（圖3）。

目前最為流行的事件驅(qū)動(dòng)的異步非阻塞式I/O的Web服務(wù)器Node.js，稱(chēng)其會(huì)在內(nèi)存占用上更為高效，而且由于不是傳統(tǒng)OPPC模式，也不用擔(dān)心死鎖。Node.js沒(méi)有函數(shù)直接執(zhí)行I/O操作[5]，因此也不會(huì)產(chǎn)生阻塞[6]。

圖 3 事件驅(qū)動(dòng)模型

圖 4 傳統(tǒng)OPPC模型

本文對(duì)目前應(yīng)用最廣的傳統(tǒng)模型的Apache+PHP服務(wù)器，與兩個(gè)流行事件驅(qū)動(dòng)模型服務(wù)器Node.js，tornado，進(jìn)行了壓力測(cè)試。使用Apache bench對(duì)三個(gè)服務(wù)器分別進(jìn)行每次1000個(gè)并發(fā)請(qǐng)求，總共100000次請(qǐng)求測(cè)試。分別監(jiān)測(cè)和記錄了三個(gè)服務(wù)器的內(nèi)存與CPU占用情況。

實(shí)驗(yàn)環(huán)境為Ubuntu 11.10，Intel Celeron 1.86GHzCPU,內(nèi)存1G(oh no,教研室的古董機(jī)子)。服務(wù)器分別為Apache2+PHP5.5,Node.js0.8.6和Tornado2.4.1。

{% include_code Nodejs nodeTest.sh %}

{% include_code Tornado tornadoTest.sh %}

{% include_code PHP phpTest.sh %}

圖4 內(nèi)存占用

圖 5 CPU占用

在這個(gè)1000并發(fā)請(qǐng)求的壓力測(cè)試中可以看到，基于事件驅(qū)動(dòng)的Node.js與Tornado都比傳統(tǒng)OPPC模型的Apache服務(wù)器要快。當(dāng)然Node.js的性能也離不開(kāi)其運(yùn)行于Google V8引擎上的原因。兩個(gè)事件驅(qū)動(dòng)模型服務(wù)器平均每秒處理的請(qǐng)求數(shù)為Apache服務(wù)器的一倍，而內(nèi)存降低了一半。圖2顯示事件驅(qū)動(dòng)模型服務(wù)器會(huì)占用更高的CPU，這說(shuō)明這種模型雖然是單線程運(yùn)行，但是能更高效的利用CPU處理更多的并發(fā)請(qǐng)求。

存在的不足

事件循環(huán)并不能解決一切問(wèn)題[2]。特別是在Node.js的有一些缺陷。Node.js的最明顯的遺漏是多線程的實(shí)現(xiàn)。事件驅(qū)動(dòng)技術(shù)似乎應(yīng)該都是多線程進(jìn)行的，如大多數(shù)事件驅(qū)動(dòng)GUI框架。理論上來(lái)說(shuō)，事件之間應(yīng)該是相互獨(dú)立的關(guān)系，因此并行化應(yīng)該并不難實(shí)現(xiàn)。

雖然理論上是這樣，但一些技術(shù)上的原因使得Node.js難以實(shí)現(xiàn)多線程。Node.js運(yùn)行與Google的V8 Javascript引擎上[12]。V8引擎是一個(gè)高性能的JavaScript引擎，但它并沒(méi)有設(shè)計(jì)為多線程。因?yàn)樗緸镚oogle Chrome瀏覽器Javascript引擎，瀏覽器中Javascropt在一個(gè)單線程上運(yùn)行。因此添加多線程，將是非常艱難的，底層架構(gòu)并非為服務(wù)器而設(shè)計(jì)。

未來(lái)

隨著nginx這樣的反向代理服務(wù)器的發(fā)展，可以讓獨(dú)立運(yùn)行的實(shí)例之間的負(fù)載均衡，Node.js的作者提出對(duì)解決多線程缺陷的最好的辦法是使用fork子進(jìn)程，利用負(fù)載均衡來(lái)達(dá)到服務(wù)器并發(fā)任務(wù)處理。 這種解決方案似乎像是要掩蓋其實(shí)現(xiàn)上的缺陷。但事件驅(qū)動(dòng)模型倡導(dǎo)一個(gè)邏輯服務(wù)器應(yīng)該應(yīng)該能在單核CPU下表現(xiàn)得最優(yōu)，以及占用更少的內(nèi)存。與此相反，Apache的最初目的是以一切可利用的資源為代價(jià)充分高效管理并發(fā)和線程。事件驅(qū)動(dòng)模型服務(wù)器避開(kāi)了這種繁瑣的設(shè)計(jì)而用最簡(jiǎn)潔高效的方式實(shí)現(xiàn)了可擴(kuò)展性良好的服務(wù)器。

單線程的也正符合云計(jì)算的平臺(tái)的計(jì)算單位。很明顯，一個(gè)單一的云實(shí)例，非常適合運(yùn)行一個(gè)單一的Node.js的服務(wù)器，并使用負(fù)載均衡橫向擴(kuò)展。

事件驅(qū)動(dòng)模型的出現(xiàn)，是為了解決傳統(tǒng)服務(wù)器與網(wǎng)絡(luò)工作負(fù)載的需求的不匹配，實(shí)現(xiàn)高度可伸縮服務(wù)器，并降低內(nèi)存開(kāi)銷(xiāo)。事情驅(qū)動(dòng)模型更改了連接到服務(wù)器的方式。所有的連接都由事件循環(huán)管理，每個(gè)連接觸發(fā)一個(gè)在事件循環(huán)進(jìn)程中運(yùn)行的事件，而不是為每個(gè)連接生成一個(gè)新的 OS 線程，并為其分配一些配套內(nèi)存。因此不用擔(dān)心出現(xiàn)死鎖，而且不會(huì)直接調(diào)用阻塞資源，而采用異步的方式來(lái)實(shí)現(xiàn)非阻塞式I/O。通過(guò)事件驅(qū)動(dòng)模型是的在相同配置的服務(wù)器能接受更多的并發(fā)請(qǐng)求，實(shí)現(xiàn)可伸縮的服務(wù)器。

[1] Suzumura, T.; Trent, S.; Tatsubori, M.; Tozawa, A.; Onodera, T.; , "Performance Comparison of Web Service Engines in PHP, Java and C," Web Services, 2008. ICWS "08. IEEE International Conference on , vol., no., pp.385-392, 23-26 Sept. 2008

[2] Von Behren, Rob, Jeremy Condit, and Eric Brewer. "Why events are a bad idea (for high-concurrency servers)." Proceedings of the 9th conference on Hot Topics in Operating Systems. Vol. 9. 2003.

[3]Welsh, Matt. "The staged event-driven architecture for highly-concurrent server applications." University of California, Berkeley (2000).

[4] Griffin, L., Ryan, K., de Leastar, E., Botvich, D., "Scaling Instant Messaging communication services: A comparison of blocking and non-blocking techniques", Computers and Communications (ISCC), 2011 IEEE Symposium on, On page(s): 550 - 557

[5] Tilkov, Stefan, and Steve Vinoski. "Node. js: Using JavaScript to build high-performance network programs." Internet Computing, IEEE 14.6 (2010): 80-83.

[6] Deitcher, Avi. "Simplicity and performance: JavaScript on the server." Linux Journal 2011.204 (2011): 3.

[11] W. Stevens. TCP/IP Illustrated Volume 3. Addison-Wesley, Reading, MA, 1996. [12]: http://code.google.com/apis/v8/design.html accessed