Nginx的事件處理機制：

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

首先看一個請求的基本過程：建立連接---接收數(shù)據(jù)---發(fā)送數(shù)據(jù) 。

再次看系統(tǒng)底層的操作 ：上述過程（建立連接---接收數(shù)據(jù)---發(fā)送數(shù)據(jù)）在系統(tǒng)底層就是讀寫事件。

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

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

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

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

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

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

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

4）與多線程的比較：

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

并發(fā)數(shù)再多也不會導致無謂的資源浪制。Nginx實現(xiàn)由進程循環(huán)處理多個準備好的事件，從而實現(xiàn)高并發(fā)和輕量級。