深入NGINX：我們如何設計它的性能和擴展性

來源: cnBeta 發布時間: 2015-06-24 22:32 閱讀: 12530 次推薦: 25 原文鏈接 [收藏]

　　英文原文：Inside NGINX: How We Designed for Performance & Scale

　　為了更好地理解設計，你需要了解NGINX是如何工作的。NGINX之所以能在性能上如此優越，是由于其背后的設計。許多web服務器和應用服務器使用簡單的線程的（threaded）、或基于流程的（process-based）架構， NGINX則以一種復雜的事件驅動（event-driven）的架構脫穎而出，這種架構能支持現代硬件上成千上萬的并發連接。

　　Inside NGINX infographic涉及了從高層次進程架構的挖掘，到NGINX的單進程處理多連接的圖解。本篇文章講解了這些工作細節。

　　設置場景——NGINX進程模型

　　為了更好地理解設計，你需要了解NGINX是如何工作的。NGINX有一個主進程（master process）（執行特權操作，如讀取配置、綁定端口）和一系列工作進程（worker process）和輔助進程（helper process）。

　　這個四核服務器內，NGINX主進程創建了4個工作進程和2個緩存輔助進程（cachehelper processes）來管理磁盤內容緩存（on-disk content cache）。

　　為什么架構很重要?

　　任何Unix應用程序的根本基礎都是線程或進程（從Linux操作系統的角度看，線程和進程基本上是相同的，主要區別是他們共享內存的程度）。進程或線程，是一組操作系統可調度的、運行在CPU內核上的獨立指令集。大多數復雜的應用程序都并行運行多個線程或進程，原因有兩個：

可以同時使用更多的計算機內核。
線程和進程使并行操作很容易實現（例如，同時處理多個連接）。

　　進程和線程都消耗資源。它們都使用內存和其他OS資源，導致內核頻繁切換(被稱作上下文切換（context switch）的操作)。大多數現代服務器可以同時處理數百個小的、活躍的（active）線程或進程，但一旦內存耗盡，或高I/O負載導致大量的上下文切換時，服務器的性能就會嚴重下降。對于網絡應用，通常會為每個連接（connection）分配一個線程或進程。這種架構易于實現，但是當應用程序需要處理成千上萬的并發連接時，這種架構的擴展性就會出現問題。

　　NGINX是如何工作的?

　　NGINX使用一個了可預見式的（predictable）進程模型，調度可用的硬件資源：

　　1. 主進程執行特權操作，如讀取配置和綁定端口，還負責創建子進程(下面的三種類型)。

　　2. 緩存加載進程（cache loader process）在啟動時運行，把基于磁盤的緩存（disk-based cache）加載到內存中，然后退出。對它的調度很謹慎，所以其資源需求很低。

　　3. 緩存管理進程（cache manager process）周期性運行，并削減磁盤緩存（prunes entries from the disk caches），以使其保持在配置范圍內。

　　4. 工作進程（worker processes）才是執行所有實際任務的進程：處理網絡連接、讀取和寫入內容到磁盤，與上游服務器通信等。

　　多數情況下，NGINX建議每1個CPU核心都運行1個工作進程，使硬件資源得到最有效的利用。你可以在配置中設置如下指令： worker_processes auto，當NGINX服務器在運行時，只有工作進程在忙碌。每個工作進程都以非阻塞的方式處理多個連接，以削減上下文切換的開銷。每個工作進程都是單線程且獨立運行的，抓取并處理新的連接。進程間通過共享內存的方式，來共享緩存數據、會話持久性數據（session persistence data）和其他共享資源。

　　NGINX內部的工作進程

　　每一個NGINX的工作進程都是NGINX配置（NGINX configuration）初始化的，并被主進程設置了一組監聽套接字（listen sockets）。

　　NGINX工作進程會監聽套接字上的事件(accept_mutex和kernel socketsharding)，來決定什么時候開始工作。事件是由新的連接初始化的。這些連接被會分配給狀態機（statemachine）—— HTTP狀態機是最常用的，但NGINX還為流（原生TCP）和大量的郵件協議（SMTP，IMAP和POP3）實現了狀態機。

　　狀態機本質上是一組告知NGINX如何處理請求的指令。大多數和NGINX具有相同功能的web服務器也使用類似的狀態機——只是實現不同。

　　調度狀態機

　　把狀態機想象成國際象棋的規則。每個HTTP事務（HTTP transaction）都是一局象棋比賽。棋盤的一邊是web服務器——坐著一位可以迅速做出決定的大師級棋手。另一邊是遠程客戶端——在相對較慢的網絡中，訪問站點或應用程序的web瀏覽器。然而，比賽的規則可能會很復雜。例如，web服務器可能需要與各方溝通(代理一個上游的應用程序)，或者和認證服務器交流。web服務器的第三方模塊也可以拓展比賽規則。

　　阻塞狀態機

　　回憶一下我們之前對進程和線程的描述：是一組操作系統可調度的、運行在CPU內核上的獨立指令集。大多數web服務器和web應用都使用一個連接/一個進程或一個連接/一個線程的模型來進行這局國際象棋比賽。每個進程或線程都包含一個將比賽玩到最后的指令。在這個過程中，進程是由服務器來運行的，它的大部分時間都花在“阻塞（blocked）”上，等待客戶端完成其下一個動作。

　　1. web服務器進程（web server process）在監聽套接字上，監聽新的連接（客戶端發起的新比賽）。

　　2. 一局新的比賽發起后，進程就開始工作，每一步棋下完后都進入阻塞狀態，等待客戶端走下一步棋。

　　3. 一旦比賽結束，web服務器進程會看看客戶是否想開始新的比賽（這相當于一個存活的連接）。如果連接被關閉（客戶端離開或者超時），web服務器進程會回到監聽狀態，等待全新的比賽。

　　記住重要的一點：每一個活躍的HTTP連接（每局象棋比賽）都需要一個專用的進程或線程（一位大師級棋手）。這種架構非常易于擴展第三方模塊（“新規則”）。然而，這里存在著一個巨大的不平衡：一個以文件描述符（file descriptor）和少量內存為代表的輕量級HTTP連接，會映射到一個單獨的進程或線程——它們是非常重量級的操作系統對象。這在編程上是方便的，但它造成了巨大的浪費。

　　NGINX是真正的大師

　　NGINX is a True Grandmaster

　　也許你聽說過車輪表演賽，在比賽中一個象棋大師要在同一時間對付幾十個對手。