一、 關于Apache與Nginx的優勢比較

    不斷有人跟我說Nginx比Apache好、比Apache快之類。Nginx更主要是作為反向代理，而非Web服務器使用。我翻譯過一本關于反向代理的技術書籍，同時精通Apache API開發，對Nginx和Apache的工作原理都略有了解，粗談一下看法。

　　不管是Nginx還是Squid這種反向代理，其網絡模式都是事件驅動。事件驅動其實是很老的技術，早期的select、poll都是如此。后來基于內核通知的更高級事件機制出現，如libevent里的epoll，使事件驅動性能得以提高。事件驅動的本質還是IO事件，應用程序在多個IO句柄間快速切換，實現所謂的異步IO。事件驅動服務器，最適合做的就是這種IO密集型工作，如反向代理，它在客戶端與WEB服務器之間起一個數據中轉作用，純粹是IO操作，自身并不涉及到復雜計算。反向代理用事件驅動來做，顯然更好，一個工作進程就可以run了，沒有進程、線程管理的開銷，CPU、內存消耗都小。

　　所以Nginx、Squid都是這樣做的。當然，Nginx也可以是多進程 + 事件驅動的模式，幾個進程跑libevent，不需要Apache那樣動輒數百的進程數。Nginx處理靜態文件效果也很好，那是因為靜態文件本身也是磁盤IO操作，處理過程一樣。至于說多少萬的并發連接，這個毫無意義。我隨手寫個網絡程序都能處理幾萬的并發，但如果大部分客戶端阻塞在那里，就沒什么價值。

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

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

二、nginx

基于nginx的tomcat負載均衡和集群(超簡單)  側重點簡單配置，缺點多人訪問時，session
使用基于Nginx集群策略后置模式避免Session復制
開啟Nginx的gzip壓縮功能詳解
Nginx 反向代理、負載均衡、頁面緩存、URL重寫及讀寫分離詳解

1 正向代理的概念 

       正向代理，也就是傳說中的代理，他的工作原理就像一個跳板，簡單的說，我是一個用戶，我訪問不了某網站，但是我能訪問一個代理服務器，這個代理服務器呢，他能訪問那個我不能訪問的網站，于是我先連上代理服務器，告訴他我需要那個無法訪問網站的內容，代理服務器去取回來，然后分會給我。從網站的角度，只能在代理服務器來取內容的時候有一條記錄，有時候并不知道是用戶的請求，也隱藏了用戶的資料，這取決于代理告不告訴網站。
      結論就是，正向代理是一個位于客戶端和服務器(origin server)之間的服務器，為了從原始服務器取得內容，客戶端向代理發送一個請求并制定目標（原始服務器），然后代理向原始服務器轉交請求并將獲得的內容返回給客戶端。客戶端必須要進行一些特別的設置才能使用正向代理。

2 反向代理的概念