Nginx的事件處理機制：
對於一個基本的web伺服器來說，事件通常有三種類型，網路事件、訊號、定時器。 
首先看一個請求的基本過程：建立連線---接收資料---傳送資料 。
再次看系統底層的操作 ：上述過程（建立連線---接收資料---傳送資料）在系統底層就是讀寫事件。

1）如果採用阻塞呼叫的方式，當讀寫事件沒有準備好時，必然不能夠進行讀寫事件，那麼久只好等待，等事件準備好了，才能進行讀寫事件。那麼請求就會被耽擱 。阻塞呼叫會進入核心等待，cpu就會讓出去給別人用了，對單執行緒的worker來說，顯然不合適，當網路事件越多時，大家都在等待呢，cpu空閒下來沒人用，cpu利用率自然上不去了，更別談高併發了 。

2）既然沒有準備好阻塞呼叫不行，那麼採用非阻塞方式。非阻塞就是，事件，馬上返回EAGAIN，告訴你，事件還沒準備好呢，你慌什麼，過會再來吧。好吧，你過一會，再來檢查一下事件，直到事件準備好了為止，在這期間，你就可以先去做其它事情，然後再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你可以做更多的事情了，但帶來的開銷也是不小的 

小結：非阻塞通過不斷檢查事件的狀態來判斷是否進行讀寫操作，這樣帶來的開銷很大。 

3）因此才有了非同步非阻塞的事件處理機制。具體到系統呼叫就是像select/poll/epoll/kqueue這樣的系統呼叫。他們提供了一種機制，讓你可以同時監控多個事件，呼叫他們是阻塞的，但可以設定超時時間，在超時時間之內，如果有事件準備好了，就返回。這種機制解決了我們上面兩個問題。 

以epoll為例：當事件沒有準備好時，就放入epoll(佇列)裡面。如果有事件準備好了，那麼就去處理；如果事件返回的是EAGAIN，那麼繼續將其放入epoll裡面。從而，只要有事件準備好了，我們就去處理她，只有當所有時間都沒有準備好時，才在epoll裡面等著。這樣，我們就可以併發處理大量的併發了，當然，這裡的併發請求，是指未處理完的請求，執行緒只有一個，所以同時能處理的請求當然只有一個了，只是在請求間進行不斷地切換而已，切換也是因為非同步事件未準備好，而主動讓出的。這裡的切換是沒有任何代價，你可以理解為迴圈處理多個準備好的事件，事實上就是這樣的。 

 4）與多執行緒的比較：
與多執行緒相比，這種事件處理方式是有很大的優勢的，不需要建立執行緒，每個請求佔用的記憶體也很少，沒有上下文切換，事件處理非常的輕量級。併發數再多也不會導致無謂的資源浪費（上下文切換）。

小結：通過非同步非阻塞的事件處理機制，Nginx實現由程序迴圈處理多個準備好的事件，從而實現高併發和輕量級。 


Nginx特點：
1. 跨平臺：Nginx 可以在大多數 Unix like OS編譯執行，而且也有Windows的移植版本。
2. 配置異常簡單，非常容易上手。配置風格跟程式開發一樣，神一般的配置
3. 非阻塞、高併發連線：資料複製時，磁碟I/O的第一階段是非阻塞的。官方測試能夠支撐5萬併發連線，在實際生產環境中跑到2～3萬併發連線數.(這得益於Nginx使用了最新的epoll模型)
4. 事件驅動：通訊機制採用epoll模型，支援更大的併發連線。
 

5. nginx代理和後端web伺服器間無需長連線；
6. 接收使用者請求是非同步的，即先將使用者請求全部接收下來，再一次性發送後後端web伺服器，極大的減輕後端web伺服器的壓力
7. 傳送響應報文時，是邊接收來自後端web伺服器的資料，邊傳送給客戶端的
8. 網路依賴型低。NGINX對網路的依賴程度非常低，理論上講，只要能夠ping通就可以實施負載均衡，而且可以有效區分內網和外網流量
9. 支援伺服器檢測。NGINX能夠根據應用伺服器處理頁面返回的狀態碼、超時資訊等檢測伺服器是否出現故障，並及時返回錯誤的請求重新提交到其它節點上







master/worker結構：一個master程序，生成一個或多個worker程序
記憶體消耗小：處理大併發的請求記憶體消耗非常小。在3萬併發連線下，開啟的10個Nginx 程序才消耗150M記憶體（15M*10=150M） 成本低廉：Nginx為開源軟體，可以免費使用。而購買F5 BIG-IP、NetScaler等硬體負載均衡交換機則需要十多萬至幾十萬人民幣
內建的健康檢查功能：如果 Nginx Proxy 後端的某臺 Web 伺服器宕機了，不會影響前端訪問。
節省頻寬：支援 GZIP 壓縮，可以新增瀏覽器本地快取的 Header 頭。
穩定性高：用於反向代理，宕機的概率微乎其微


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的失效 

負載均衡

負載均衡技術在現有網路結構之上提供了一種廉價、有效、透明的方法，來擴充套件網路裝置和伺服器的頻寬、增加吞吐量、加強網路資料處理能力、提高網路的靈活性和可用性。它有兩方面的含義：首先，大量的併發訪問或資料流量分擔到多臺節點裝置上分別處理，減少使用者等待響應的時間；其次，單個重負載的運算分擔到多臺節點裝置上做並行處理，每個節點裝置處理結束後，將結果彙總，返回給使用者，系統處理能力得到大幅度提高