Nginx更主要是作為反向代理，而非Web服務(wù)器使用。不管是Nginx還是Squid這種反向代理，其網(wǎng)絡(luò)模式都是事件驅(qū)動。事件驅(qū)動其實是很老的技術(shù)，早期的select、poll都是如此。后來基于內(nèi)核通知的更高級事件機制出現(xiàn)，如libevent里的epoll，使事件驅(qū)動性能得以提高。事件驅(qū)動的本質(zhì)還是IO事件，應(yīng)用程序在多個IO句柄間快速切換，實現(xiàn)所謂的異步IO。事件驅(qū)動服務(wù)器，最適合做的就是這種IO密集型工作，如反向代理，它在客戶端與WEB服務(wù)器之間起一個數(shù)據(jù)中轉(zhuǎn)作用，純粹是IO操作，自身并不涉及到復(fù)雜計算。反向代理用事件驅(qū)動來做，顯然更好，一個工作進程就可以run了，沒有進程、線程管理的開銷，CPU、內(nèi)存消耗都小。所以Nginx、Squid都是這樣做的。當(dāng)然，Nginx也可以是多進程 + 事件驅(qū)動的模式，幾個進程跑libevent，不需要Apache那樣動輒數(shù)百的進程數(shù)。Nginx處理靜態(tài)文件效果也很好，那是因為靜態(tài)文件本身也是磁盤IO操作，處理過程一樣。至于說多少萬的并發(fā)連接，這個毫無意義。我隨手寫個網(wǎng)絡(luò)程序都能處理幾萬的并發(fā)，但如果大部分客戶端阻塞在那里，就沒什么價值。

再看看Apache或者Resin這類應(yīng)用服務(wù)器，之所以稱他們?yōu)閼?yīng)用服務(wù)器，是因為他們真的要跑具體的業(yè)務(wù)應(yīng)用，如科學(xué)計算、圖形圖像、數(shù)據(jù)庫讀寫等。它們很可能是CPU密集型的服務(wù)，事件驅(qū)動并不合適。例如一個計算耗時2秒，那么這2秒就是完全阻塞的，什么event都沒用。想想MySQL如果改成事件驅(qū)動會怎么樣，一個大型的join或sort就會阻塞住所有客戶端。這個時候多進程或線程就體現(xiàn)出優(yōu)勢，每個進程各干各的事，互不阻塞和干擾。當(dāng)然，現(xiàn)代CPU越來越快，單個計算阻塞的時間可能很小，但只要有阻塞，事件編程就毫無優(yōu)勢。所以進程、線程這類技術(shù)，并不會消失，而是與事件機制相輔相成，長期存在。

總結(jié)之，事件驅(qū)動適合于IO密集型服務(wù)，多進程或線程適合CPU密集型服務(wù)，它們各有各的優(yōu)勢，并不存在誰取代誰的傾向。再盲目的言之Nginx可以取代Apache的，該好好反思了。