一、Nginx是什么
Nginx ("engine x") 是一個高性能的 HTTP 和反向代理服務器,特點是占有內存少，並發能力強，事實上nginx的並發能力確實在同類型的網頁服務器中表現較好，中國大陸使用nginx網站用戶有：百度、京東、新浪、網易、騰訊、淘寶等。代理服務器:一般是指局域網內部的機器通過代理服務器發送請求到互聯網上的服務器,代理服務器一般作用在客戶端。應用比如：GoAgent，翻牆神器。
一個完整的代理請求過程為：客戶端首先與代理服務器創建連接，接着根據代理服務器所使用的代理協議，請求對目標服務器創建連接、或者獲得目標服務器的指定資源。 Web代理（proxy）服務器是網絡的中間實體。 代理位於Web客戶端和Web服務器之間，扮演“中間人”的角色。HTTP的代理服務器即是Web服務器又是Web客戶端。
代理服務器是介於客戶端和Web服務器之間的另一台服務器，有了它之后，瀏覽器不是直接到Web服務器去取回網頁而是向代理服務器發出請求，信號會先送到代理服務器，由代理服務器來取回瀏覽器所需要的信息並傳送給你的瀏覽器。
正向代理 是一個位於客戶端和原始服務器(origin server)之間的服務器，為了從原始服務器取得內容，客戶端向代理發送一個請求並指定目標(原始服務器)，然后代理向原始服務器轉交請求並將獲得的內容返回給客戶端。客戶端必須要進行一些特別的設置才能使用正向代理。
反向代理服務器：在服務器端接受客戶端的請求，然后把請求分發給具體的服務器進行處理，然后再將服務器的響應結果反饋給客戶端。Nginx就是其中的一種反向代理服務器軟件。客戶端必須設置正向代理服務器，當然前提是要知道正向代理服務器的IP地址，還有代理程序的端口。
反向代理正好與正向代理相反，對於客戶端而言代理服務器就像是原始服務器，並且客戶端不需要進行任何特別的設置。客戶端向反向代理的命名空間(name-space)中的內容發送普通請求，接着反向代理將判斷向何處(原始服務器)轉交請求，並將獲得的內容返回給客戶端。
二、Nginx的特點
- 跨平台：Nginx 可以在大多數 Unix like OS編譯運行，而且也有Windows的移植版本。
- 非阻塞、高並發連接：數據復制時，磁盤I/O的第一階段是非阻塞的。官方測試能夠支撐5萬並發連接，在實際生產環境中跑到2～3萬並發連接數.(這得益於Nginx使用了最新的epoll模型)
- 事件驅動：通信機制采用epoll模型，支持更大的並發連接。
- master/worker結構：一個master進程，生成一個或多個worker進程
- 內存消耗小：處理大並發的請求內存消耗非常小。在3萬並發連接下，開啟的10個Nginx 進程才消耗150M內存（15M*10=150M）
- 成本低廉：Nginx為開源軟件，可以免費使用。而購買F5 BIG-IP、NetScaler等硬件負載均衡交換機則需要十多萬至幾十萬人民幣
- 內置的健康檢查功能：如果 Nginx Proxy 后端的某台 Web 服務器宕機了，不會影響前端訪問。
- 節省帶寬：支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭。
- 穩定性高：用於反向代理，宕機的概率微乎其微。
三、Nginx的事件處理機制
對於一個基本的web服務器來說，事件通常有三種類型，網絡事件、信號、定時器。首先看一個請求的基本過程：建立連接---接收數據---發送數據 。再次看系統底層的操作 ：上述過程（建立連接---接收數據---發送數據）在系統底層就是讀寫事件。
1、如果采用阻塞調用的方式，當讀寫事件沒有准備好時，必然不能夠進行讀寫事件，那么久只好等待，等事件准備好了，才能進行讀寫事件。那么請求就會被耽擱 。阻塞調用會進入內核等待，cpu就會讓出去給別人用了，對單線程的worker來說，顯然不合適，當網絡事件越多時，大家都在等待呢，cpu空閑下來沒人用，cpu利用率自然上不去了，更別談高並發了 。
2、既然沒有准備好阻塞調用不行，那么采用非阻塞方式。非阻塞就是，事件，馬上返回EAGAIN，告訴你，事件還沒准備好呢，你慌什么，過會再來吧。好吧，你過一會，再來檢查一下事件，直到事件准備好了為止，在這期間，你就可以先去做其它事情，然后再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你可以做更多的事情了，但帶來的開銷也是不小的 小結：非阻塞通過不斷檢查事件的狀態來判斷是否進行讀寫操作，這樣帶來的開銷很大。
3、因此才有了異步非阻塞的事件處理機制。具體到系統調用就是像select/poll/epoll/kqueue這樣的系統調用。他們提供了一種機制，讓你可以同時監控多個事件，調用他們是阻塞的，但可以設置超時時間，在超時時間之內，如果有事件准備好了，就返回。這種機制解決了我們上面兩個問題。
以epoll為例：當事件沒有准備好時，就放入epoll(隊列)里面。如果有事件准備好了，那么就去處理；如果事件返回的是EAGAIN，那么繼續將其放入epoll里面。從而，只要有事件准備好了，我們就去處理她，只有當所有時間都沒有准備好時，才在epoll里面等着。這樣，我們就可以並發處理大量的並發了，當然，這里的並發請求，是指未處理完的請求，線程只有一個，所以同時能處理的請求當然只有一個了，只是在請求間進行不斷地切換而已，切換也是因為異步事件未准備好，而主動讓出的。這里的切換是沒有任何代價，你可以理解為循環處理多個准備好的事件，事實上就是這樣的。
4、與多線程的比較：與多線程相比，這種事件處理方式是有很大的優勢的，不需要創建線程，每個請求占用的內存也很少，沒有上下文切換，事件處理非常的輕量級。並發數再多也不會導致無謂的資源浪費（上下文切換）。 小結：通過異步非阻塞的事件處理機制，Nginx實現由進程循環處理多個准備好的事件，從而實現高並發和輕量級。
四、Nginx的內部（進程）模型
nginx是以多進程的方式來工作的，當然nginx也是支持多線程的方式的,只是我們主流的方式還是多進程的方式，也是nginx的默認方式。nginx采用多進程的方式有諸多好處。
1、nginx在啟動后，會有一個master進程和多個worker進程。master進程主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控 worker進程的運行狀態,當worker進程退出后(異常情況下)，會自動重新啟動新的worker進程。而基本的網絡事件，則是放在worker進程中來處理了 。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的 。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。 worker進程的個數是可以設置的，一般我們會設置與機器cpu核數一致，這里面的原因與nginx的進程模型以及事件處理模型是分不開的 。
2、Master接收到信號以后怎樣進行處理（./nginx -s reload ）?首先master進程在接到信號后，會先重新加載配置文件，然后再啟動新的進程，並向所有老的進程發送信號，告訴他們可以光榮退休了。新的進程在啟動后，就開始接收新的請求，而老的進程在收到來自master的信號后，就不再接收新的請求，並且在當前進程中的所有未處理完的請求處理完成后，再退出。
3、worker進程又是如何處理請求的呢？我們前面有提到，worker進程之間是平等的，每個進程，處理請求的機會也是一樣的。當我們提供80端口的http服務時，一個連接請求過來，每個進程都有可能處理這個連接，怎么做到的呢？首先，每個worker進程都是從master進程fork過來，在master進程里面，先建立好需要listen的socket之后，然后再fork出多個worker進程，這樣每個worker進程都可以去accept這個socket(當然不是同一個socket，只是每個進程的這個socket會監控在同一個ip地址與端口，這個在網絡協議里面是允許的)。一般來說，當一個連接進來后，所有在accept在這個socket上面的進程，都會收到通知，而只有一個進程可以accept這個連接，其它的則accept失敗，這是所謂的驚群現象。當然，nginx也不會視而不見，所以nginx提供了一個accept_mutex這個東西，從名字上，我們可以看這是一個加在accept上的一把共享鎖。有了這把鎖之后，同一時刻，就只會有一個進程在accpet連接，這樣就不會有驚群問題了。accept_mutex是一個可控選項，我們可以顯示地關掉，默認是打開的。當一個worker進程在accept這個連接之后，就開始讀取請求，解析請求，處理請求，產生數據后，再返回給客戶端，最后才斷開連接，這樣一個完整的請求就是這樣的了。我們可以看到，一個請求，完全由worker進程來處理，而且只在一個worker進程中處理。
4、nginx采用這種進程模型有什么好處呢？采用獨立的進程，可以讓互相之間不會影響，一個進程退出后，其它進程還在工作，服務不會中斷，master進程則很快重新啟動新的worker進程。當然，worker進程的異常退出，肯定是程序有bug了，異常退出，會導致當前worker上的所有請求失敗，不過不會影響到所有請求，所以降低了風險。當然，好處還有很多，大家可以慢慢體會。
5、有人可能要問了，nginx采用多worker的方式來處理請求，每個worker里面只有一個主線程，那能夠處理的並發數很有限啊，多少個worker就能處理多少個並發，何來高並發呢？非也，這就是nginx的高明之處，nginx采用了異步非阻塞的方式來處理請求，也就是說，nginx是可以同時處理成千上萬個請求的 .對於IIS服務器每個請求會獨占一個工作線程，當並發數上到幾千時，就同時有幾千的線程在處理請求了。這對操作系統來說，是個不小的挑戰，線程帶來的內存占用非常大，線程的上下文切換帶來的cpu開銷很大，自然性能就上不去了，而這些開銷完全是沒有意義的。我們之前說過，推薦設置worker的個數為cpu的核數，在這里就很容易理解了，更多的worker數，只會導致進程來競爭cpu資源了，從而帶來不必要的上下文切換。而且，nginx為了更好的利用多核特性，提供了cpu親緣性的綁定選項，我們可以將某一個進程綁定在某一個核上，這樣就不會因為進程的切換帶來cache的失效
五、Nginx是如何處理一個請求
首先，nginx在啟動時，會解析配置文件，得到需要監聽的端口與ip地址，然后在nginx的master進程里面，先初始化好這個監控的socket(創建socket，設置addrreuse等選項，綁定到指定的ip地址端口，再listen)，然后再fork(一個現有進程可以調用fork函數創建一個新進程。由fork創建的新進程被稱為子進程 )出多個子進程出來，然后子進程會競爭accept新的連接。此時，客戶端就可以向nginx發起連接了。當客戶端與nginx進行三次握手，與nginx建立好一個連接后，此時，某一個子進程會accept成功，得到這個建立好的連接的socket，然后創建nginx對連接的封裝，即ngx_connection_t結構體。接着，設置讀寫事件處理函數並添加讀寫事件來與客戶端進行數據的交換。最后，nginx或客戶端來主動關掉連接，到此，一個連接就壽終正寢了。
當然，nginx也是可以作為客戶端來請求其它server的數據的（如upstream模塊），此時，與其它server創建的連接，也封裝在ngx_connection_t中。作為客戶端，nginx先獲取一個ngx_connection_t結構體，然后創建socket，並設置socket的屬性（ 比如非阻塞）。然后再通過添加讀寫事件，調用connect/read/write來調用連接，最后關掉連接，並釋放ngx_connection_t。
nginx在實現時，是通過一個連接池來管理的，每個worker進程都有一個獨立的連接池，連接池的大小是worker_connections。這里的連接池里面保存的其實不是真實的連接，它只是一個worker_connections大小的一個ngx_connection_t結構的數組。並且，nginx會通過一個鏈表free_connections來保存所有的空閑ngx_connection_t，每次獲取一個連接時，就從空閑連接鏈表中獲取一個，用完后，再放回空閑連接鏈表里面。
在這里，很多人會誤解worker_connections這個參數的意思，認為這個值就是nginx所能建立連接的最大值。其實不然，這個值是表示每個worker進程所能建立連接的最大值，所以，一個nginx能建立的最大連接數，應該是worker_connections * worker_processes。當然，這里說的是最大連接數，對於HTTP請求本地資源來說，能夠支持的最大並發數量是worker_connections * worker_processes，而如果是HTTP作為反向代理來說，最大並發數量應該是worker_connections * worker_processes/2。因為作為反向代理服務器，每個並發會建立與客戶端的連接和與后端服務的連接，會占用兩個連接。
六、Nginx典型的應用場景
負載均衡技術在現有網絡結構之上提供了一種廉價、有效、透明的方法，來擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。它有兩方面的含義：首先，大量的並發訪問或數據流量分擔到多台節點設備上分別處理，減少用戶等待響應的時間；其次，單個重負載的運算分擔到多台節點設備上做並行處理，每個節點設備處理結束后，將結果匯總，返回給用戶，系統處理能力得到大幅度提高。