一、 關(guān)于A(yíng)pache與Nginx的優(yōu)勢(shì)比較

    不斷有人跟我說(shuō)Nginx比Apache好、比Apache快之類(lèi)。Nginx更主要是作為反向代理，而非Web服務(wù)器使用。我翻譯過(guò)一本關(guān)于反向代理的技術(shù)書(shū)籍，同時(shí)精通Apache API開(kāi)發(fā)，對(duì)Nginx和Apache的工作原理都略有了解，粗談一下看法。

　　不管是Nginx還是Squid這種反向代理，其網(wǎng)絡(luò)模式都是事件驅(qū)動(dòng)。事件驅(qū)動(dòng)其實(shí)是很老的技術(shù)，早期的select、poll都是如此。后來(lái)基于內(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密集型工作，如反向代理，它在客戶(hù)端與WEB服務(wù)器之間起一個(gè)數(shù)據(jù)中轉(zhuǎn)作用，純粹是IO操作，自身并不涉及到復(fù)雜計(jì)算。反向代理用事件驅(qū)動(dòng)來(lái)做，顯然更好，一個(gè)工作進(jìn)程就可以run了，沒(méi)有進(jìn)程、線(xiàn)程管理的開(kāi)銷(xiāo)，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)文件本身也是磁盤(pán)IO操作，處理過(guò)程一樣。至于說(shuō)多少萬(wàn)的并發(fā)連接，這個(gè)毫無(wú)意義。我隨手寫(xiě)個(gè)網(wǎng)絡(luò)程序都能處理幾萬(wàn)的并發(fā)，但如果大部分客戶(hù)端阻塞在那里，就沒(méi)什么價(jià)值。

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

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

二、nginx

基于nginx的tomcat負(fù)載均衡和集群(超簡(jiǎn)單)  側(cè)重點(diǎn)簡(jiǎn)單配置，缺點(diǎn)多人訪(fǎng)問(wèn)時(shí)，session
使用基于Nginx集群策略后置模式避免Session復(fù)制
開(kāi)啟Nginx的gzip壓縮功能詳解
Nginx 反向代理、負(fù)載均衡、頁(yè)面緩存、URL重寫(xiě)及讀寫(xiě)分離詳解

1 正向代理的概念 

       正向代理，也就是傳說(shuō)中的代理，他的工作原理就像一個(gè)跳板，簡(jiǎn)單的說(shuō)，我是一個(gè)用戶(hù)，我訪(fǎng)問(wèn)不了某網(wǎng)站，但是我能訪(fǎng)問(wèn)一個(gè)代理服務(wù)器，這個(gè)代理服務(wù)器呢，他能訪(fǎng)問(wèn)那個(gè)我不能訪(fǎng)問(wèn)的網(wǎng)站，于是我先連上代理服務(wù)器，告訴他我需要那個(gè)無(wú)法訪(fǎng)問(wèn)網(wǎng)站的內(nèi)容，代理服務(wù)器去取回來(lái)，然后分會(huì)給我。從網(wǎng)站的角度，只能在代理服務(wù)器來(lái)取內(nèi)容的時(shí)候有一條記錄，有時(shí)候并不知道是用戶(hù)的請(qǐng)求，也隱藏了用戶(hù)的資料，這取決于代理告不告訴網(wǎng)站。
      結(jié)論就是，正向代理是一個(gè)位于客戶(hù)端和服務(wù)器(origin server)之間的服務(wù)器，為了從原始服務(wù)器取得內(nèi)容，客戶(hù)端向代理發(fā)送一個(gè)請(qǐng)求并制定目標(biāo)（原始服務(wù)器），然后代理向原始服務(wù)器轉(zhuǎn)交請(qǐng)求并將獲得的內(nèi)容返回給客戶(hù)端?？蛻?hù)端必須要進(jìn)行一些特別的設(shè)置才能使用正向代理。

2 反向代理的概念
       例如 用戶(hù)訪(fǎng)問(wèn) http://www.test.com/readme,但是www.test.com上并不存在readme頁(yè)面，他是偷偷從另外一臺(tái)服務(wù)器取回來(lái)，然后作為自己的內(nèi)容返回用戶(hù)，但用戶(hù)并不知情。這里所提到的www.test.com 這個(gè)域名對(duì)應(yīng)額服務(wù)器就設(shè)置了反向代理功能。
       結(jié)論就是，反向代理正好相反，對(duì)于客戶(hù)端而言它就像是原始服務(wù)器，并且客戶(hù)端不需要進(jìn)行任何特別設(shè)置?？蛻?hù)端向反向代理的命名空間(name-space)中的內(nèi)容發(fā)送普通請(qǐng)求，接著反向代理將判斷向何處（原始服務(wù)器）轉(zhuǎn)交請(qǐng)求，并將獲得的內(nèi)容返回給客戶(hù)端，就像這些內(nèi)容元貝就是它自己的一樣。           

3 兩者區(qū)別
     從用途上來(lái)講:
             正向代理的典型用途是為在防火墻內(nèi)的局域網(wǎng)客戶(hù)端提供訪(fǎng)問(wèn)Internet的途徑。正向代理還可以使用緩存特性減少網(wǎng)絡(luò)使用率。
             反向代理的典型用途是將防火墻后面的代理服務(wù)器提供給Internet用戶(hù)訪(fǎng)問(wèn)。反向代理還可以為后端的多臺(tái)服務(wù)器提供負(fù)載平衡，或?yàn)楹蠖溯^慢的服務(wù)器提供緩沖服務(wù)。另外反向代理還可以啟用高級(jí)URL策略和管理技術(shù)，從而是處于不同web服務(wù)器系統(tǒng)的web頁(yè)面同時(shí)存在于同一個(gè)URL空間下。
      從安全性來(lái)講：
              正向代理允許客戶(hù)端通過(guò)訪(fǎng)問(wèn)任意網(wǎng)站并且隱藏客戶(hù)自身，因此你必須采取安全措施以確保僅為經(jīng)過(guò)授權(quán)的客戶(hù)端提供服務(wù)。
              反向代理對(duì)外都是透明的，訪(fǎng)問(wèn)者并不自導(dǎo)自己訪(fǎng)問(wèn)的是一個(gè)代理。

5. 看到一本關(guān)于nginx開(kāi)發(fā)的書(shū)《深入理解Nginx：模塊開(kāi)發(fā)與架構(gòu)解析》

  阿里巴巴資深Nginx專(zhuān)家撰寫(xiě)，透徹解析Nginx架構(gòu)，詳解Nginx模塊開(kāi)發(fā)方法和技巧。知道不適合我，但是很膜拜。

  另外一直關(guān)注的一本書(shū)總是缺貨  叫《Web協(xié)議與實(shí)踐》o(╯□╰)o

最新評(píng)論