精品主題,實(shí)戰(zhàn)科普,最新行業(yè)熱點(diǎn)話題,隨時(shí)掌握云上咨訊。
Nginx更主要是作為反向代理,而非Web服務(wù)器使用。不管是Nginx還是Squid這種反向代理,其網(wǎng)絡(luò)模式都是事件驅(qū)動(dòng)。事件驅(qū)動(dòng)其實(shí)是很老的技術(shù),早期的select、poll都是如此。后來基于內(nèi)核通知的更高級(jí)事件機(jī)制出現(xiàn),如libevent里的epoll,使事件驅(qū)動(dòng)性能得以提高。事件驅(qū)動(dòng)的本質(zhì)還是IO事件,應(yīng)用程序在多個(gè)IO句柄間快速切換,實(shí)現(xiàn)所謂的異步IO。事件驅(qū)動(dòng)服務(wù)器,最適合做的就是這種IO密集型工作,如反向代理,它在客戶端與WEB服務(wù)器之間起一個(gè)數(shù)據(jù)中轉(zhuǎn)作用,純粹是IO操作,自身并不涉及到復(fù)雜計(jì)算。反向代理用事件驅(qū)動(dòng)來做,顯然更好,一個(gè)工作進(jìn)程就可以run了,沒有進(jìn)程、線程管理的開銷,CPU、內(nèi)存消耗都小。所以Nginx、Squid都是這樣做的。當(dāng)然,Nginx也可以是多進(jìn)程 + 事件驅(qū)動(dòng)的模式,幾個(gè)進(jìn)程跑libevent,不需要Apache那樣動(dòng)輒數(shù)百的進(jìn)程數(shù)。Nginx處理靜態(tài)文件效果也很好,那是因?yàn)殪o態(tài)文件本身也是磁盤IO操作,處理過程一樣。至于說多少萬的并發(fā)連接,這個(gè)毫無意義。我隨手寫個(gè)網(wǎng)絡(luò)程序都能處理幾萬的并發(fā),但如果大部分客戶端阻塞在那里,就沒什么價(jià)值。
再看看Apache或者Resin這類應(yīng)用服務(wù)器,之所以稱他們?yōu)閼?yīng)用服務(wù)器,是因?yàn)樗麄冋娴囊芫唧w的業(yè)務(wù)應(yīng)用,如科學(xué)計(jì)算、圖形圖像、數(shù)據(jù)庫讀寫等。它們很可能是CPU密集型的服務(wù),事件驅(qū)動(dòng)并不合適。例如一個(gè)計(jì)算耗時(shí)2秒,那么這2秒就是完全阻塞的,什么event都沒用。想想MySQL如果改成事件驅(qū)動(dòng)會(huì)怎么樣,一個(gè)大型的join或sort就會(huì)阻塞住所有客戶端。這個(gè)時(shí)候多進(jìn)程或線程就體現(xiàn)出優(yōu)勢(shì),每個(gè)進(jìn)程各干各的事,互不阻塞和干擾。當(dāng)然,現(xiàn)代CPU越來越快,單個(gè)計(jì)算阻塞的時(shí)間可能很小,但只要有阻塞,事件編程就毫無優(yōu)勢(shì)。所以進(jìn)程、線程這類技術(shù),并不會(huì)消失,而是與事件機(jī)制相輔相成,長(zhǎng)期存在。
總結(jié)之,事件驅(qū)動(dòng)適合于IO密集型服務(wù),多進(jìn)程或線程適合CPU密集型服務(wù),它們各有各的優(yōu)勢(shì),并不存在誰取代誰的傾向。再盲目的言之Nginx可以取代Apache的,該好好反思了。