所謂沒有對比就沒有傷害！

在nginx橫空出世之前，Apache伺服器一直佔據web伺服器的壟斷地位，所以就用對比的方式來解釋nginx那麼強！

兩者效能差別的主要原因在於網路IO模型選擇不同，apache使用了select，而nginx使用了epoll模型！

舉個例子:一個萬人村裡面選村長，有兩種方式:

①，讓每個人在紙條上寫下自己的名字，然後前村長去收集紙條(一個執行緒去遍歷)，然後得到村長推薦候選人的名單(需要處理的連線)，這就相當於select模型，去輪詢每一個連線，並對需要進行處理的連線進行處理！

②，每個人都可以毛遂自薦(每個連線都有可能活躍)，想要競選的在旁邊站成一排(事件觸發，放入佇列中)，然後就在這幾個人中選擇(幾個待處理的任務)，相當於只要對少量的事件進行處理！

一個是從上萬人中迴圈得到幾個進行處理，一個是幾個自己站出來直接處理，這種效率相差不是一般的大吧？

nginx是基於epoll模型開發的，而epoll是基於JAVA NIO的同步非阻塞開發，在高併發情況下能支援更多的連線！

nginx是事件驅動的，一個主程序跟多個工作程序組成的工作模式，主執行緒負責迴圈分配事件，多個工作執行緒負責事件的處理！

我們通常使用nginx做什麼呢？

nginx作為高效能的http伺服器和反向代理伺服器，通常用做負載均衡元件，負責接受大量的連線然後基於一定的規則(輪詢，權重等)分發連線給不同的應用伺服器進行處理！

而且負載均衡配置十分簡單，只需要在安裝好nginx之後，透過修改配置檔案nginx.conf，將不同的連線分發到不同的伺服器上(透過配置server)，配置十分簡單！

一般來說，企業中使用nginx作為負載均衡元件的場景還是很多的，同時為了避免單點故障帶來的不穩定性，通常會使用keepalive搭建高可用的叢集方案！

nginx搭建比較簡單，大家自己可以多玩一玩！更多的技術分享，敬請關注。。。

看到下面回答中“nginx是基於epoll模型開發的，而epoll是基於JAVA NIO的同步非阻塞開發“，忍不住想這回答還真是無畏啊，錯的離譜，竟還有那麼多點贊。應該說Epoll機制僅僅是nginx在Linux上實現事件驅動的一種技術而已，說nginx基於epoll開發那就錯了，說nginx基於java nio開發就更不知所云了。

當我們說效能優越的時候，我們在說什麼呢？首先讓我們看看有哪些衡量效能的效能指標吧。

效能指標一般包括響應時間、吞吐量、併發使用者數等。

響應時間指功能完成的時間，和客觀環境、資料量級、主觀感受等都有關係。客觀環境中硬體包括伺服器配置、客戶端機器配置等，軟體包括資料庫部署方式、客戶端使用的瀏覽器等，另外還有網路環境。

吞吐量是給定時間內系統可處理的事務/請求的數量等，例如網路傳輸的資料流量。這個指標對於網際網路軟體更為關鍵，目前我們尚未進行定量分析和測試。

併發使用者數用來衡量系統的同步協調能力，我們更關注多個使用者同時操作同一功能或資料時，對系統性能的影響。

總的來說，nginx的效能是指其低延遲、高吞吐、高併發能力。

下面我們就從架構設計的角度，來分析nginx是如何做到低延遲、高吞吐、高併發能力的。

Nginx採用一個Master管理程序，多個worker工作程序的設計方式。如下圖所示，Master程序管理了完全相同的worker程序，一個cache manager程序和cache loader程序。

這種多程序的架構可以充分利用多核系統的併發處理能力。同時，多個worker程序間可以實現負載均衡，一個請求到來時更容易被分配到負載較輕的worker程序中處理。這將降低請求的延遲，也提高了網路處理的效能。

Nginx程序內部採用了非阻塞方式的事件驅動架構模式，這也是Nginx不同於傳統Web伺服器的地方。傳統的Web伺服器而言，採用的所謂事件驅動往往侷限於TCP建立連線、關閉事件上，一個連線建立以後，在關閉之前的所有操作都不再是事件驅動，這時會退化成按序執行每個操作的批處理模式，這樣每個請求在連線建立之後都將始終佔用系統資源，直到關閉才會釋放。

nginx的非同步事件驅動實際上是請求的多階段非同步處理的過程。nginx實際把請求處理流程劃分為了11個階段，這樣劃分的原因是將請求的執行邏輯細分，各階段按照處理時機定義了清晰的執行語義，開發者可以很容易分辨自己需要開發的模組應該定義在什麼階段。

nginx做為一個非同步高效的事件驅動型web伺服器，在linux平臺中當系統支援epoll時nginx預設採用epoll來高效的處理事件。Epoll實際上是 poll 的一種改進，它可以處理大批次的控制代碼。而 poll 又是select 的一種改進。在select 中對所開啟的檔案描述符個數有一定的限制，該限制由 FD_SETSIZE 設定（一般為 1024 或 2048）， 而且核心中的 select 的實現是採用輪詢來處理描檔案描述符集，因此效率低。當檔案描述符集中的某個描述符處於可讀、可寫或異常狀態時，select 採用記憶體複製方法通知使用者空間。因此， 在select 模型中檔案描述符個數受限且效率低的問題就很明顯。為了解決select 對檔案描述符個數的限制，採用了 poll 模型，但是 poll 依然不能解決 select 的效率問題。所以，最終epoll 模型重新對poll 模型進行改進 。

epoll 的優點如下所示：

處理大批次檔案控制代碼：一個程序可以處理大批次的檔案控制代碼，可處理檔案描述符的個數遠大於 2048；

高效率：核心實現中 epoll 是根據每個描述符上面的回撥函式實現的，並且只有處於活動狀態的套接字才會主動呼叫該回調函式，其他不活動的套接字並不會去呼叫，因此，epoll 不必掃描整個檔案描述符集，只需要掃描處於活動狀態的檔案描述符。所有大大減低了效率。加快核心與使用者的訊息傳遞：epoll 是透過核心與使用者空間mmap 同一塊記憶體實現核心與使用者之間訊息的傳遞。核心微調：可以根據執行時所需記憶體動態調整記憶體大小。

Nginx的高效能有賴於其高效記憶體管理，下面我們看看其記憶體池設計。

Nginx 使用記憶體池對記憶體進行管理，把記憶體分配歸結為大記憶體分配和小記憶體分配。若申請的記憶體大小比同頁的記憶體池最大值 max 還大，則是大記憶體分配，否則為小記憶體分配。

大塊記憶體的分配請求不會直接在記憶體池上分配記憶體來滿足請求，而是直接向系統申請一塊記憶體（就像直接使用 malloc 分配記憶體一樣），然後將這塊記憶體掛到記憶體池頭部的 large 欄位下。小塊記憶體分配，則是從已有的記憶體池資料區中分配出一部分記憶體。

這樣設計的好處就是減少了記憶體碎片，提升了記憶體分配的效率。

總結一下，nginx優越的效能得益於其多程序、非同步事件處理的架構，得益於其高效的記憶體管理。

本回答的內容參考了nginx官網上的內容，截圖也來自於https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/

1.NGINX

採用了的構架極其簡單，採用了多程序，每個程序的核心業務其實是單執行緒的，在執行上，程式碼邏輯可以極其簡化。同時也可以把多核機器的效能發揮出來。

2.採用了EPOLL的這個非同步IO模型，在面對大併發時，系統在處理網路事件上，佔用的CPU極低，為高效能提供了可能。

3.在記憶體使用上，NGINX不像傳統的寫法，在池裡面分配，然後再釋放，而是為每個連線生成一個臨時池，這個池上的申請小塊記憶體不進鎖，同時這個池上的記憶體也不釋放，而是在完成請求後，這個池一次性釋放。

部署架構上支援負載均衡

設計上採用程序池概念

網路模組在linux上支援非阻塞epoll模型

我做過深入測試，windows下面最強者是iis，linux下最強者是nginx，nginx在win下效能很差，還不如apache