Nginx的事件處理機制

nginx的事件處理機制：

對於乙個主要的webserver來說，事件通常有三種型別，網路事件、訊號、定時器。

首先看乙個請求的基本過程：建立連線---接收資料---傳送資料。

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

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

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

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

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

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

以epoll為例：當事件沒有準備好時，就放入epoll(佇列)裡面。假設有事件準備好了，那麼就去處理。假設事件返回的是eagain，那麼繼續將其放入epoll裡面。從而，僅僅要有事件準備好了，我們就去處理她，僅僅有當全部時間都沒有準備好時。才在epoll裡面等著。這樣。我們就能夠併發處理大量的併發了，當然，這裡的併發請求。是指未處理完的請求，執行緒僅僅有乙個，所以同一時候能處理的請求當然僅僅有乙個了，僅僅是在請求間進行不斷地切換而已，切換也是由於非同步事件未準備好，而主動讓出的。

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

4）與多執行緒的比較：

與多執行緒相比，這種事件處理方式是有非常大的優勢的。不須要建立執行緒，每乙個請求占用的記憶體也非常少，沒有上下文切換，事件處理非常的輕量級。

併發數再多也不會導致無謂的資源浪費（上下文切換）。

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

Nginx的事件處理機制

Nginx的事件處理機制

Nginx的事件處理機制

Nginx程序模型與事件處理機制

相關推薦