nginx能做什么
- 反向代理
- 正向代理
- 負載均衡
- HTTP服務器(包含動靜分離)
反向代理和正向代理
正向代理。簡單的說,我是一個用戶,我無法直接訪問一個網站,但是我能訪問一個代理服務器,這個代理服務器能訪問那個我不能訪問的網站,於是我先連上代理服務器,告訴它我需要那個無法訪問網站的內容,代理服務器去取回來,然后返回給我。從網站的角度,只在代理服務器來取內容的時候有一次記錄。結論就是，正向代理，是一個位於客戶端和原始服務器(origin server)之間的服務器，為了從原始服務器取得內容，客戶端向代理發送一個請求並指定目標(原始服務器)，然后代理向原始服務器轉交請求並將獲得的內容返回給客戶端。客戶端必須要進行一些特別的設置才能使用正向代理。
反向代理。例如我要訪問 localhost:8080/views/test1 這個頁面，但view對應的服務器上並沒有test1這個資源，它是從另一台服務器上調用的資源。這樣view對應的那個服務器就使用了反向代理。即用戶只需要把請求發給特定的反向代理服務器，具體請求是誰處理的用戶不需要知道(其實也不知道)，由代理服務器統一處理。結論就是 反向代理正好相反，對於客戶端而言它就像是原始服務器，並且客戶端不需要進行任何特別的設置。客戶端向反向代理 的命名空間(name-space)中的內容發送普通請求，接着反向代理將判斷向何處(原始服務器)轉交請求，並將獲得的內容返回給客戶端，就像這些內容 原本就是它自己的一樣。
正向代理的典型用途是為在防火牆內的局域網客戶端提供訪問Internet的途徑。正向代理還可以使用緩沖特性減少網絡使用率。反向代理的典型用途是將 防火牆后面的服務器提供給Internet用戶訪問。反向代理還可以為后端的多台服務器提供負載平衡，或為后端較慢的服務器提供緩沖服務。
總結
正向代理：針對客戶端而言， 代理服務器代理客戶端，轉發請求，並將獲得的內容返回給客戶端。
反向代理：針對客戶端而言， 代理服務器就像是原始服務器,代理集群的web節點服務器返回結果。
負載均衡
負載均衡也是Nginx常用的一個功能，負載均衡其意思就是分攤到多個操作單元上進行執行，例如Web服務器、FTP服務器、企業關鍵應用服務器和其它關鍵任務服務器等，從而共同完成工作任務。簡單而言就是當有2台或以上服務器時，根據規則隨機的將請求分發到指定的服務器上處理，負載均衡配置一般都需要同時配置反向代理，通過反向代理跳轉到負載均衡。而Nginx目前支持自帶3種負載均衡策略，還有2種常用的第三方策略。
-
RR
按照輪詢（默認）方式進行負載，每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器down掉，能自動剔除。雖然這種方式簡便、成本低廉。但缺點是：可靠性低和負載分配不均衡。 -
權重
指定輪詢幾率，weight和訪問比率成正比，用於后端服務器性能不均的情況。upstream test{ server localhost:8080 weight=9; server localhost:8081 weight=1; } -
ip_hash
上面的2種方式都有一個問題，那就是下一個請求來的時候請求可能分發到另外一個服務器，當我們的程序不是無狀態的時候（采用了session保存數據），這時候就有一個很大的很問題了，比如把登錄信息保存到了session中，那么跳轉到另外一台服務器的時候就需要重新登錄了，所以很多時候我們需要一個客戶只訪問一個服務器，那么就需要用iphash了，iphash的每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決session的問題。upstream test { ip_hash; server localhost:8080; server localhost:8081; } -
fair(第三方)
按后端服務器的響應時間來分配請求，響應時間短的優先分配。upstream backend { fair; server localhost:8080; server localhost:8081; } -
url_hash(第三方)
按訪問url的hash結果來分配請求，使每個url定向到同一個后端服務器，后端服務器為緩存時比較有效。 在upstream中加入hash語句，server語句中不能寫入weight等其他的參數，hash_method是使用的hash算法。upstream backend { hash $request_uri; hash_method crc32; server localhost:8080; server localhost:8081; }
HTTP服務器
Nginx本身也是一個靜態資源的服務器，當只有靜態資源的時候，就可以使用Nginx來做服務器，同時現在也很流行動靜分離，就可以通過Nginx來實現，動靜分離是讓動態網站里的動態網頁根據一定規則把不變的資源和經常變的資源區分開來，動靜資源做好了拆分以后，我們就可以根據靜態資源的特點將其做緩存操作，這就是網站靜態化處理的核心思路。
nginx進程模型
在工作方式上，Nginx分為單工作進程和多工作進程兩種模式。在單工作進程模式下，除主進程外，還有一個工作進程，工作進程是單線程的；在多工作進程模式下，每個工作進程包含多個線程。Nginx默認為單工作進程模式。
Nginx在啟動后，會有一個master進程和多個worker進程。
master進程
主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控worker進程的運行狀態，當worker進程退出后(異常情況下)，會自動重新啟動新的worker進程。
master進程充當整個進程組與用戶的交互接口，同時對進程進行監護。它不需要處理網絡事件，不負責業務的執行，只會通過管理worker進程來實現重啟服務、平滑升級、更換日志文件、配置文件實時生效等功能。
我們要控制nginx，只需要通過kill向master進程發送信號就行了。比如kill -HUP pid，則是告訴nginx，從容地重啟nginx，我們一般用這個信號來重啟nginx，或重新加載配置，因為是從容地重啟，因此服務是不中斷的。master進程在接收到HUP信號后是怎么做的呢？
首先master進程在接到信號后，會先重新加載配置文件，然后再啟動新的worker進程，並向所有老的worker進程發送信號，告訴他們可以光榮退休了。新的worker在啟動后，就開始接收新的請求，而老的worker在收到來自master的信號后，就不再接收新的請求，並且在當前進程中的所有未處理完的請求處理完成后，再退出。
當然，直接給master進程發送信號，這是比較老的操作方式，nginx在0.8版本之后，引入了一系列命令行參數，來方便我們管理。比如，./nginx -s reload，就是來重啟nginx，./nginx -s stop，就是來停止nginx的運行。
如何做到的呢？我們還是拿reload來說，我們看到，執行命令時，我們是啟動一個新的nginx進程，而新的nginx進程在解析到reload參數后，就知道我們的目的是控制nginx來重新加載配置文件了，它會向master進程發送信號，然后接下來的動作，就和我們直接向master進程發送信號一樣了。
worker進程
而基本的網絡事件，則是放在worker進程中來處理了。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。worker進程的個數是可以設置的，一般我們會設置與機器cpu核數一致，這里面的原因與nginx的進程模型以及事件處理模型是分不開的。
worker進程之間是平等的，每個進程，處理請求的機會也是一樣的。當我們提供80端口的http服務時，一個連接請求過來，每個進程都有可能處理這個連接，怎么做到的呢？首先，每個worker進程都是從master進程fork過來，在master進程里面，先建立好需要listen的socket（listenfd）之后，然后再fork出多個worker進程。
所有worker進程的listenfd會在新連接到來時變得可讀，為保證只有一個進程處理該連接，所有worker進程在注冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進程注冊listenfd讀事件，在讀事件里調用accept接受該連接。當一個worker進程在accept這個連接之后，就開始讀取請求，解析請求，處理請求，產生數據后，再返回給客戶端，最后才斷開連接，這樣一個完整的請求就是這樣的了。
我們可以看到，一個請求，完全由worker進程來處理，而且只在一個worker進程中處理。worker進程之間是平等的，每個進程，處理請求的機會也是一樣的。當我們提供80端口的http服務時，一個連接請求過來，每個進程都有可能處理這個連接，怎么做到的呢？首先，每個worker進程都是從master進程fork過來，在master進程里面，先建立好需要listen的socket（listenfd）之后，然后再fork出多個worker進程。
所有worker進程的listenfd會在新連接到來時變得可讀，為保證只有一個進程處理該連接，所有worker進程在注冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進程注冊listenfd讀事件，在讀事件里調用accept接受該連接。當一個worker進程在accept這個連接之后，就開始讀取請求，解析請求，處理請求，產生數據后，再返回給客戶端，最后才斷開連接，這樣一個完整的請求就是這樣的了。我們可以看到，一個請求，完全由worker進程來處理，而且只在一個worker進程中處理。
多進程IO模型好處
首先，對於每個worker進程來說，獨立的進程，不需要加鎖，所以省掉了鎖帶來的開銷，同時在編程以及問題查找時，也會方便很多。
其次，采用獨立的進程，可以讓互相之間不會影響，一個進程退出后，其它進程還在工作，服務不會中斷，master進程則很快啟動新的worker進程。當然，worker進程的異常退出，肯定是程序有bug了，異常退出，會導致當前worker上的所有請求失敗，不過不會影響到所有請求，所以降低了風險。
nginx多進程事件模型：異步非阻塞
雖然nginx采用多worker的方式來處理請求，每個worker里面只有一個主線程，那能夠處理的並發數很有限啊，多少個worker就能處理多少個並發，何來高並發呢？非也，這就是nginx的高明之處，nginx采用了異步非阻塞的方式來處理請求，也就是說，nginx是可以同時處理成千上萬個請求的。
一個worker進程可以同時處理的請求數只受限於內存大小，而且在架構設計上，不同的worker進程之間處理並發請求時幾乎沒有同步鎖的限制，worker進程通常不會進入睡眠狀態，因此，當Nginx上的進程數與CPU核心數相等時（最好每一個worker進程都綁定特定的CPU核心），進程間切換的代價是最小的。
而apache的常用工作方式（apache也有異步非阻塞版本，但因其與自帶某些模塊沖突，所以不常用），每個進程在一個時刻只處理一個請求，因此，當並發數上到幾千時，就同時有幾千的進程在處理請求了。這對操作系統來說，是個不小的挑戰，進程帶來的內存占用非常大，進程的上下文切換帶來的cpu開銷很大，自然性能就上不去了，而這些開銷完全是沒有意義的。
為什么nginx可以采用異步非阻塞的方式來處理呢，或者異步非阻塞到底是怎么回事呢？
我們先回到原點，看看一個請求的完整過程:首先，請求過來，要建立連接，然后再接收數據，接收數據后，再發送數據。
具體到系統底層，就是讀寫事件，而當讀寫事件沒有准備好時，必然不可操作，如果不用非阻塞的方式來調用，那就得阻塞調用了，事件沒有准備好，那就只能等了，等事件准備好了，你再繼續吧。阻塞調用會進入內核等待，cpu就會讓出去給別人用了，對單線程的worker來說，顯然不合適，當網絡事件越多時，大家都在等待呢，cpu空閑下來沒人用，cpu利用率自然上不去了，更別談高並發了。
好吧，你說加進程數，這跟apache的線程模型有什么區別，注意，別增加無謂的上下文切換。所以，在nginx里面，最忌諱阻塞的系統調用了。不要阻塞，那就非阻塞嘍。非阻塞就是，事件沒有准備好，馬上返回EAGAIN，告訴你，事件還沒准備好呢，你慌什么，過會再來吧。
好吧，你過一會，再來檢查一下事件，直到事件准備好了為止，在這期間，你就可以先去做其它事情，然后再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你可以做更多的事情了，但帶來的開銷也是不小的。