nginx的事件處理機制：
對於乙個基本的web伺服器來說，事件通常有三種型別，網路事件、訊號、定時器。
首先看乙個請求的基本過程：建立連線---接收資料---傳送資料 。
再次看系統底層的操作 ：上述過程（建立連線---接收資料---傳送資料）在系統底層就是讀寫事件。
1）如果採用阻塞呼叫的方式，當讀寫事件沒有準備好時，必然不能夠進行讀寫事件，那麼久只好等待，等事件準備好了，才能進行讀寫事件。那麼請求就會被耽擱 。阻塞呼叫會進入核心等待，cpu就會讓出去給別人用了，對單執行緒的worker來說，顯然不合適，當網路事件越多時，大家都在等待呢，cpu空閒下來沒人用，cpu利用率自然上不去了，更別談高併發了 。
2）既然沒有準備好阻塞呼叫不行，那麼採用非阻塞方式。非阻塞就是，事件，馬上返回eagain，告訴你，事件還沒準備好呢，你慌什麼，過會再來吧。好吧，你過一會，再來檢查一下事件，直到事件準備好了為止，在這期間，你就可以先去做其它事情，然後再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你可以做更多的事情了，但帶來的開銷也是不小的
小結：非阻塞通過不斷檢查事件的狀態來判斷是否進行讀寫操作，這樣帶來的開銷很大。
3）因此才有了非同步非阻塞的事件處理機制。具體到系統呼叫就是像select/poll/epoll/kqueue這樣的系統呼叫。他們提供了一種機制，讓你可以同時監控多個事件，呼叫他們是阻塞的，但可以設定超時時間，在超時時間之內，如果有事件準備好了，就返回。這種機制解決了我們上面兩個問題。
以epoll為例：當事件沒有準備好時，就放入epoll(佇列)裡面。如果有事件準備好了，那麼就去處理；如果事件返回的是eagain，那麼繼續將其放入epoll裡面。從而，只要有事件準備好了，我們就去處理她，只有當所有時間都沒有準備好時，才在epoll裡面等著。這樣，我們就可以併發處理大量的併發了，當然，這裡的併發請求，是指未處理完的請求，執行緒只有乙個，所以同時能處理的請求當然只有乙個了，只是在請求間進行不斷地切換而已，切換也是因為非同步事件未準備好，而主動讓出的。這裡的切換是沒有任何代價，你可以理解為迴圈處理多個準備好的事件，事實上就是這樣的。
4）與多執行緒的比較：
與多執行緒相比，這種事件處理方式是有很大的優勢的，不需要建立執行緒，每個請求占用的記憶體也很少，沒有上下文切換，事件處理非常的輕量級。併發數再多也不會導致無謂的資源浪費（上下文切換）。
小結：通過非同步非阻塞的事件處理機制，nginx實現由程序迴圈處理多個準備好的事件，從而實現高併發和輕量級。
Nginx的事件處理機制
nginx的事件處理機制 對於乙個基本的web伺服器來說，事件通常有三種型別，網路事件 訊號 定時器。首先看乙個請求的基本過程 建立連線 接收資料 傳送資料 再次看系統底層的操作 上述過程 建立連線 接收資料 傳送資料 在系統底層就是讀寫事件。1 如果採用阻塞呼叫的方式，當讀寫事件沒有準備好時，必然...
Nginx的事件處理機制
nginx的事件處理機制 對於乙個主要的webserver來說，事件通常有三種型別，網路事件 訊號 定時器。首先看乙個請求的基本過程 建立連線 接收資料 傳送資料 再次看系統底層的操作 上述過程 建立連線 接收資料 傳送資料 在系統底層就是讀寫事件。1 假設採用堵塞呼叫的方式，當讀寫事件沒有準備好時...
Nginx程序模型與事件處理機制
nginx共有兩種程序模型，即master和worker程序。master主程序管理worker程序。管理包含 worker程序可以在核心配置檔案中配置成多個。conf nginx.conf worker processes 6 檢視nginx程序 ps ef grep nginx 管理員傳送指令 ...