Ngnix的學習總結

Ngnix一直以來都是I/O密集性服務的不二選擇，今天就把這兩天整理學習關於Ngnix的基本知識整理下，如果有錯誤，請大家指出，謝謝批評。

基本的架構設計

1. 介面設計
   所有的模組都遵循著同樣的ngx_module_t介面設計規範。
2. Ngnix核心及其常用模組設計關係
   
   從圖中可以看出，總共有四個模組。
   首先是配置模組，配置模組是所有模組的基礎，他實現了最基本的配置項的解析功能。
   nginx定義了一種基礎型別的模組：核心模組，模組型別是NGX_CORE_MODULE。定義核心模組的目的是使得非模組化的框架程式碼只關注與如何呼叫6個核心模組。
   事件模組、HTTP模組、mail模組這三種模組的共性是：實際上它們在核心模組中各有1個模組作為自己的代言人，並在同類模組中有1個作為核心業務與管理功能的模組。
   
   事件模組是HTTP模組和mail模組的基礎。

Nginx核心程序模型

首先，正常執行中的nginx會有多個程序，最基本的有master process（監控程序，也叫做主程序）和woker process（工作程序），還可能有cache相關程序。

1. master程序
   監控程序充當整個程序組與使用者的互動介面，同時對程序進行監護。它不需要處理網路事件，不負責業務的執行，只會通過管理worker程序來實現重啟服務、平滑升級、更換日誌檔案、配置檔案實時生效等功能。
   TIPS:master程序中for(::)無限迴圈內有一個關鍵的sigsuspend()函式呼叫，該函式呼叫是的master程序的大部分時間都處於掛起狀態，直到master程序收到訊號為止。

2. worker程序
   基本的網路事件,是放在worker程序中來處理的，wenkor之間的程序是對等的，只可能在相同的wenkor中處理，一個wenkor程序不可能處理其他程序的請求。
   wenkor的個數，一般來說設定與cpu的個數相同，所以當我們提供8080埠的http請求服務時，一個請求過來，每個程序都有可能處理這個連結。因為更多的worker數，只會導致程序相互競爭cpu資源，從而帶來不必要的上下文切換

3. 處理過程
   master（master程序會先建立好需要listen的socket）——–fork生成子程序workers，繼承socket（此時workers子程序們都繼承了父程序master的所有屬性，當然也包括已經建立好的socket，當然不是同一個socket，只是每個程序的這個socket會監控在同一個ip地址與埠，這個在網路協議裡面是允許的）
   ——當一個連線進入，產生驚群現象。
   驚群現象：一般來說，當一個連線進來後，所有在accept在這個socket上面的程序，都會收到通知，而只有一個程序可以accept這個連線，其它的則accept失敗。

Nginx對驚群現象的處理：
當一個worker程序在accept這個連線之後，就開始讀取請求，解析請求，處理請求，產生資料後，再返回給客戶端，最後才斷開連線，一個完整的請求。一個請求，完全由worker程序來處理，而且只在一個worker程序中處理。

Nginx的事件處理機制：
首先，對於一個web伺服器來說，基本事務型別是:網路事件、訊號、定時器。
1. Ngnix採用的是非同步非阻塞的事件處理機制，由程序迴圈處理多個準備好的事件，從而實現高併發和輕量級。
2. 採用訊號事務機制通知worker進行工作
詳解: 以epoll為例：當事件沒有準備好時，就放入epoll裡面。如果有事件準備好了，那麼就去處理；如果事件返回的是EAGAIN，那麼繼續將其放入epoll裡面。從而，只要有事件準備好了，我們就去處理她，只有當所有時間都沒有準備好時，才在epoll裡面等著。這樣，我們就可以併發處理大量的併發了，當然，這裡的併發請求，是指未處理完的請求，執行緒只有一個，所以同時能處理的請求當然只有一個了，只是在請求間進行不斷地切換而已，切換也是因為非同步事件未準備好，而主動讓出的。
這裡的切換是沒有任何代價，你可以理解為迴圈處理多個準備好的事件

題外問題

Nginx與Apache對於高併發處理上的區別
對於Apache，每個請求都會獨佔一個工作執行緒，當併發數到達幾千時，就同時有幾千的執行緒在處理請求了。這對於作業系統來說，佔用的記憶體非常大，執行緒的上下文切換帶來的cpu開銷也很大，效能就難以上去，同時這些開銷是完全沒有意義的。
對於Nginx來講，一個程序只有一個主執行緒，通過非同步非阻塞的事件處理機制，實現了迴圈處理多個準備好的事件，從而實現輕量級和高併發。

—————————————-

Nginx比較Apache：事件驅動適合於IO密集型服務，多程序或執行緒適合於CPU密集型服務
1. Nginx更主要是作為反向代理，而非Web伺服器使用。其網路模式是事件驅動（select、poll、epoll）。
2. 事件驅動的本質還是IO事件，應用程式在多個IO控制代碼間快速切換，實現所謂的非同步IO。
3. 事件驅動伺服器，最適合做的就是這種IO密集型工作，如反向代理，它在客戶端與WEB伺服器之間起一個數據中轉作用，純粹是IO操作，自身並不涉及到複雜計算。
4. 反向代理用事件驅動來做，顯然更好，一個工作程序就可以run了，沒有程序、執行緒管理的開銷，CPU、記憶體消耗都小。
5. 當然，Nginx也可以是多程序 + 事件驅動的模式，幾個程序跑libevent，不需要Apache那樣動輒數百的程序數。
6. Nginx處理靜態檔案效果也很好，那是因為靜態檔案本身也是磁碟IO操作，處理過程一樣。至於說多少萬的併發連線，這個毫無意義。我隨手寫個網路程式都能處理幾萬7）的併發，但如果大部分客戶端阻塞在那裡，就沒什麼價值。

再看看Apache或者Resin這類應用伺服器，之所以稱他們為應用伺服器，是因為他們真的要跑具體的業務應用，如科學計算、圖形影象、資料庫讀寫等。它們很可能是CPU密集型的服務，事件驅動並不合適。

1. 例如一個計算耗時2秒，那麼這2秒就是完全阻塞的，什麼event都沒用。想想MySQL如果改成事件驅動會怎麼樣，一個大型的join或sort就會阻塞住所有客戶端。
2. 這個時候多程序或執行緒就體現出優勢，每個程序各幹各的事，互不阻塞和干擾。當然，現代CPU越來越快，單個計算阻塞的時間可能很小，但只要有阻塞，事件程式設計就毫無優勢。所以程序、執行緒這類技術，並不會消失，而是與事件機制相輔相成，長期存在。

總結之，事件驅動適合於IO密集型服務，多程序或執行緒適合於CPU密集型服務，它們各有各的優勢，並不存在誰取代誰的傾向。