Nginx 究竟如何處理事件？

在瞭解了網絡事件以及事件分發收集器之後，讓咱們來了解 Nginx 是怎麼樣處理事件的？

Nginx 事件循環

當 Nginx 剛剛啓動時，在等待事件部分，也就是打開了 80 或 443 端口，這個時候在等待新的事件進來，好比新的客戶端連上了 Nginx 向咱們發起了鏈接，此步每每對應 epoll 的 epoll wait 方法，這個時候的 Nginx 實際上是處於 sleep 這樣一個進程狀態的。當操做系統收到了一個創建 TCP 鏈接的握手報文時而且處理完握手流程之後，操做系統就會通知 epoll wait 這個阻塞方法，告訴它能夠往下走了，同時喚醒 Nginx worker 進程。

接着往下走以後，會去找操做系統索要要事件，操做系統會把他準備好的事件，放在事件隊列中，從這個事件隊列中能夠獲取到須要處理的事件。好比創建鏈接或者收到一個 TCP 請求報文。

取出之後就會進行循環處理事件，如上就是處理事件的一個循環：當發現隊列中不爲空，就把事件取出來開始處理事件；在處理事件的過程當中，可能又生成新的事件，好比說發現一個鏈接新創建了，可能要添加一個超時時間，好比默認的 60 秒，也就是說 60 秒以內若是瀏覽器不向 Nginx 發送請求的話，Nginx 就會把這個鏈接關掉；又好比說當 Nginx 發現已經收完了完整的 HTTP 請求之後，能夠生成 HTTP 響應了，那麼這個生成響應是須要 Nginx 能夠向操做系統的寫緩存中內心面去把響應寫進去，要求操做系統儘快的把這樣一段響應內容發到瀏覽器上，也就是說可能在處理過程當中可能會產生新的事件，就是循環處理事件部分指向的事件隊列部分，等待下一次來處理。

若是全部的事件都處理完成之後呢，又會返回到等待事件部分。

在學習了 Nginx 事件循環後，咱們再去理解，有時候使用一些第三方模塊，這些第三方模塊可能會作大量的 CPU 運算，這樣的計算任務會致使處理一個事件的時間很是的長；在上面的一個流程圖中，能夠看到會致使隊列中的大量事件會長時間得不處處理，從而引起惡性循環，也就是他們的超時時間可能到了；大量的 CPU、Nginx 的任務都消耗在處理鏈接不正常的斷開，因此 Nginx 不能容忍有些第三方模塊長時間的消耗大量的 CPU 進行計算任務就是這樣一個緣由。咱們能夠看到像 GZIP 這樣的模塊，他們都不會在一次使用大量的 CPU 而是分段使用，這些都與 Nginx 的事件循環有關的。

總結

本篇文章主要講解了 Nginx 是如何處理事件的以及 Nginx 事件循環的流程是怎麼樣的，爲下一步講解 Nginx 事件循環流程中是如何從操做系統中獲取等待處理的事件作鋪墊，而且經過事件循環瞭解到爲何 Nginx 不指望第三方模塊中出現大量 CPU 的計算任務。