這篇文章主要講解了“Nginx是如何處理事件的”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Nginx是如何處理事件的”吧！

專注于為中小企業(yè)提供網(wǎng)站建設(shè)、網(wǎng)站制作服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)平原免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了千余家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

Nginx 事件循環(huán)

當(dāng) Nginx 剛剛啟動時，在等待事件部分，也就是打開了 80 或 443 端口，這個時候在等待新的事件進(jìn)來，比如新的客戶端連上了 Nginx 向我們發(fā)起了連接，此步往往對應(yīng) epoll 的 epoll wait 方法，這個時候的 Nginx 其實是處于 sleep 這樣一個進(jìn)程狀態(tài)的。當(dāng)操作系統(tǒng)收到了一個建立 TCP 連接的握手報文時并且處理完握手流程以后，操作系統(tǒng)就會通知 epoll wait 這個阻塞方法，告訴它可以往下走了，同時喚醒 Nginx worker 進(jìn)程。

接著往下走之后，會去找操作系統(tǒng)索要要事件，操作系統(tǒng)會把他準(zhǔn)備好的事件，放在事件隊列中，從這個事件隊列中可以獲取到需要處理的事件。比如建立連接或者收到一個 TCP 請求報文。

取出以后就會進(jìn)行循環(huán)處理事件，如上就是處理事件的一個循環(huán)：當(dāng)發(fā)現(xiàn)隊列中不為空，就把事件取出來開始處理事件；在處理事件的過程中，可能又生成新的事件，比如說發(fā)現(xiàn)一個連接新建立了，可能要添加一個超時時間，比如默認(rèn)的 60 秒，也就是說 60 秒之內(nèi)如果瀏覽器不向 Nginx 發(fā)送請求的話，Nginx 就會把這個連接關(guān)掉；又比如說當(dāng) Nginx 發(fā)現(xiàn)已經(jīng)收完了完整的 HTTP 請求以后，可以生成 HTTP 響應(yīng)了，那么這個生成響應(yīng)是需要 Nginx 可以向操作系統(tǒng)的寫緩存中心里面去把響應(yīng)寫進(jìn)去，要求操作系統(tǒng)盡快的把這樣一段響應(yīng)內(nèi)容發(fā)到瀏覽器上，也就是說可能在處理過程中可能會產(chǎn)生新的事件，就是循環(huán)處理事件部分指向的事件隊列部分，等待下一次來處理。

如果所有的事件都處理完成以后呢，又會返回到等待事件部分。

在學(xué)習(xí)了 Nginx 事件循環(huán)后，我們再去理解有時候使用一些第三方模塊，這些第三方模塊可能會做大量的 CPU 運算，這樣的計算任務(wù)會導(dǎo)致處理一個事件的時間非常的長；在上面的一個流程圖中，可以看到會導(dǎo)致隊列中的大量事件會長時間得不到處理，從而引發(fā)惡性循環(huán)，也就是他們的超時時間可能到了；大量的 CPU、Nginx 的任務(wù)都消耗在處理連接不正常的斷開，所以 Nginx 不能容忍有些第三方模塊長時間的消耗大量的 CPU 進(jìn)行計算任務(wù)就是這樣一個原因。我們可以看到像 GZIP 這樣的模塊，他們都不會在一次使用大量的 CPU 而是分段使用，這些都與 Nginx 的事件循環(huán)有關(guān)的。

總結(jié)

本篇文章主要講解了 Nginx 是如何處理事件的以及 Nginx 事件循環(huán)的流程是怎么樣的，為下一步講解 Nginx 事件循環(huán)流程中是如何從操作系統(tǒng)中獲取等待處理的事件做鋪墊，并且通過事件循環(huán)了解到為什么 Nginx 不期望第三方模塊中出現(xiàn)大量 CPU 的計算任務(wù)。

感謝各位的閱讀，以上就是“Nginx是如何處理事件的”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Nginx是如何處理事件的這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！