Nginx的事件處理機制：

對于一個主要的webserver來說，事件通常有三種類型，網絡事件、信號、定時器。

首先看一個請求的基本過程：建立連接---接收數據---發送數據 。

再次看系統底層的操作 ：上述過程（建立連接---接收數據---發送數據）在系統底層就是讀寫事件。

1）假設採用堵塞調用的方式，當讀寫事件沒有準備好時。必定不能夠進行讀寫事件。那么久僅僅好等待，等事件準備好了，才干進行讀寫事件。那么請求就會被耽擱 。堵塞調用會進入內核等待，cpu就會讓出去給別人用了，對單線程的worker來說，顯然不合適。當網絡事件越多時。大家都在等待呢，cpu空暇下來沒人用，cpu利用率自然上不去了，更別談高并發了 。

2）既然沒有準備好堵塞調用不行，那么採用非堵塞方式。非堵塞就是，事件，立即返回EAGAIN。告訴你，事件還沒準備好呢，你慌什么，過會再來吧。

好吧。你過一會。再來檢查一下事件，直到事件準備好了為止，在這期間，你就能夠先去做其他事情。然后再來看看事件好了沒。盡管不堵塞了。但你得不時地過來檢查一下事件的狀態，你能夠做很多其他的事情了，但帶來的開銷也是不小的

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

3）因此才有了異步非堵塞的事件處理機制。詳細到系統調用就是像select/poll/epoll/kqueue這種系統調用。他們提供了一種機制。讓你能夠同一時候監控多個事件。調用他們是堵塞的，但能夠設置超時時間，在超時時間之內，假設有事件準備好了，就返回。這種機制攻克了我們上面兩個問題。

以epoll為例：當事件沒有準備好時，就放入epoll（隊列）里面。假設有事件準備好了，那么就去處理。假設事件返回的是EAGAIN，那么繼續將其放入epoll里面。從而，僅僅要有事件準備好了，我們就去處理她，僅僅有當全部時間都沒有準備好時。才在epoll里面等著。這樣。我們就能夠并發處理大量的并發了，當然，這里的并發請求。是指未處理完的請求，線程僅僅有一個，所以同一時候能處理的請求當然僅僅有一個了，僅僅是在請求間進行不斷地切換而已，切換也是由于異步事件未準備好，而主動讓出的。

這里的切換是沒有不論什么代價。你能夠理解為循環處理多個準備好的事件，其實就是這種。

4）與多線程的比較：

與多線程相比，這種事件處理方式是有非常大的優勢的。不須要創建線程，每一個請求占用的內存也非常少，沒有上下文切換，事件處理非常的輕量級。

并發數再多也不會導致無謂的資源浪制。Nginx實現由進程循環處理多個準備好的事件，從而實現高并發和輕量級。