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

在nginx橫空出世之前，Apache服務(wù)器一直占據(jù)web服務(wù)器的壟斷地位，所以就用對比的方式來解釋nginx那么強(qiáng)！

兩者性能差別的主要原因在于網(wǎng)絡(luò)IO模型選擇不同，apache使用了select，而nginx使用了epoll模型！

舉個(gè)例子:一個(gè)萬人村里面選村長，有兩種方式:

①，讓每個(gè)人在紙條上寫下自己的名字，然后前村長去收集紙條(一個(gè)線程去遍歷)，然后得到村長推薦候選人的名單(需要處理的連接)，這就相當(dāng)于select模型，去輪詢每一個(gè)連接，并對需要進(jìn)行處理的連接進(jìn)行處理！

②，每個(gè)人都可以毛遂自薦(每個(gè)連接都有可能活躍)，想要競選的在旁邊站成一排(事件觸發(fā)，放入隊(duì)列中)，然后就在這幾個(gè)人中選擇(幾個(gè)待處理的任務(wù))，相當(dāng)于只要對少量的事件進(jìn)行處理！

一個(gè)是從上萬人中循環(huán)得到幾個(gè)進(jìn)行處理，一個(gè)是幾個(gè)自己站出來直接處理，這種效率相差不是一般的大吧？

nginx是基于epoll模型開發(fā)的，而epoll是基于JAVA NIO的同步非阻塞開發(fā)，在高并發(fā)情況下能支持更多的連接！

nginx是事件驅(qū)動的，一個(gè)主進(jìn)程跟多個(gè)工作進(jìn)程組成的工作模式，主線程負(fù)責(zé)循環(huán)分配事件，多個(gè)工作線程負(fù)責(zé)事件的處理！

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

nginx作為高性能的http服務(wù)器和反向代理服務(wù)器，通常用做負(fù)載均衡組件，負(fù)責(zé)接受大量的連接然后基于一定的規(guī)則(輪詢，權(quán)重等)分發(fā)連接給不同的應(yīng)用服務(wù)器進(jìn)行處理！

而且負(fù)載均衡配置十分簡單，只需要在安裝好nginx之后，通過修改配置文件nginx.conf，將不同的連接分發(fā)到不同的服務(wù)器上(通過配置server)，配置十分簡單！

一般來說，企業(yè)中使用nginx作為負(fù)載均衡組件的場景還是很多的，同時(shí)為了避免單點(diǎn)故障帶來的不穩(wěn)定性，通常會使用keepalive搭建高可用的集群方案！

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

看到下面回答中“nginx是基于epoll模型開發(fā)的，而epoll是基于JAVA NIO的同步非阻塞開發(fā)“，忍不住想這回答還真是無畏啊，錯(cuò)的離譜，竟還有那么多點(diǎn)贊。應(yīng)該說Epoll機(jī)制僅僅是nginx在Linux上實(shí)現(xiàn)事件驅(qū)動的一種技術(shù)而已，說nginx基于epoll開發(fā)那就錯(cuò)了，說nginx基于java nio開發(fā)就更不知所云了。

當(dāng)我們說性能優(yōu)越的時(shí)候，我們在說什么呢？首先讓我們看看有哪些衡量性能的性能指標(biāo)吧。

性能指標(biāo)一般包括響應(yīng)時(shí)間、吞吐量、并發(fā)用戶數(shù)等。

響應(yīng)時(shí)間指功能完成的時(shí)間，和客觀環(huán)境、數(shù)據(jù)量級、主觀感受等都有關(guān)系。客觀環(huán)境中硬件包括服務(wù)器配置、客戶端機(jī)器配置等，軟件包括數(shù)據(jù)庫部署方式、客戶端使用的瀏覽器等，另外還有網(wǎng)絡(luò)環(huán)境。

吞吐量是給定時(shí)間內(nèi)系統(tǒng)可處理的事務(wù)/請求的數(shù)量等，例如網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)流量。這個(gè)指標(biāo)對于互聯(lián)網(wǎng)軟件更為關(guān)鍵，目前我們尚未進(jìn)行定量分析和測試。

并發(fā)用戶數(shù)用來衡量系統(tǒng)的同步協(xié)調(diào)能力，我們更關(guān)注多個(gè)用戶同時(shí)操作同一功能或數(shù)據(jù)時(shí)，對系統(tǒng)性能的影響。

總的來說，nginx的性能是指其低延遲、高吞吐、高并發(fā)能力。

下面我們就從架構(gòu)設(shè)計(jì)的角度，來分析nginx是如何做到低延遲、高吞吐、高并發(fā)能力的。

Nginx采用一個(gè)Master管理進(jìn)程，多個(gè)worker工作進(jìn)程的設(shè)計(jì)方式。如下圖所示，Master進(jìn)程管理了完全相同的worker進(jìn)程，一個(gè)cache manager進(jìn)程和cache loader進(jìn)程。

這種多進(jìn)程的架構(gòu)可以充分利用多核系統(tǒng)的并發(fā)處理能力。同時(shí)，多個(gè)worker進(jìn)程間可以實(shí)現(xiàn)負(fù)載均衡，一個(gè)請求到來時(shí)更容易被分配到負(fù)載較輕的worker進(jìn)程中處理。這將降低請求的延遲，也提高了網(wǎng)絡(luò)處理的性能。

Nginx進(jìn)程內(nèi)部采用了非阻塞方式的事件驅(qū)動架構(gòu)模式，這也是Nginx不同于傳統(tǒng)Web服務(wù)器的地方。傳統(tǒng)的Web服務(wù)器而言，采用的所謂事件驅(qū)動往往局限于TCP建立連接、關(guān)閉事件上，一個(gè)連接建立以后，在關(guān)閉之前的所有操作都不再是事件驅(qū)動，這時(shí)會退化成按序執(zhí)行每個(gè)操作的批處理模式，這樣每個(gè)請求在連接建立之后都將始終占用系統(tǒng)資源，直到關(guān)閉才會釋放。

nginx的異步事件驅(qū)動實(shí)際上是請求的多階段異步處理的過程。nginx實(shí)際把請求處理流程劃分為了11個(gè)階段，這樣劃分的原因是將請求的執(zhí)行邏輯細(xì)分，各階段按照處理時(shí)機(jī)定義了清晰的執(zhí)行語義，開發(fā)者可以很容易分辨自己需要開發(fā)的模塊應(yīng)該定義在什么階段。

nginx做為一個(gè)異步高效的事件驅(qū)動型web服務(wù)器，在linux平臺中當(dāng)系統(tǒng)支持epoll時(shí)nginx默認(rèn)采用epoll來高效的處理事件。Epoll實(shí)際上是 poll 的一種改進(jìn)，它可以處理大批量的句柄。而 poll 又是select 的一種改進(jìn)。在select 中對所打開的文件描述符個(gè)數(shù)有一定的限制，該限制由 FD_SETSIZE 設(shè)置（一般為 1024 或 2048）， 而且內(nèi)核中的 select 的實(shí)現(xiàn)是采用輪詢來處理描文件描述符集，因此效率低。當(dāng)文件描述符集中的某個(gè)描述符處于可讀、可寫或異常狀態(tài)時(shí)，select 采用內(nèi)存拷貝方法通知用戶空間。因此， 在select 模型中文件描述符個(gè)數(shù)受限且效率低的問題就很明顯。為了解決select 對文件描述符個(gè)數(shù)的限制，采用了 poll 模型，但是 poll 依然不能解決 select 的效率問題。所以，最終epoll 模型重新對poll 模型進(jìn)行改進(jìn) 。

epoll 的優(yōu)點(diǎn)如下所示：

• 處理大批量文件句柄：一個(gè)進(jìn)程可以處理大批量的文件句柄，可處理文件描述符的個(gè)數(shù)遠(yuǎn)大于 2048；
  

• 高效率：內(nèi)核實(shí)現(xiàn)中 epoll 是根據(jù)每個(gè)描述符上面的回調(diào)函數(shù)實(shí)現(xiàn)的，并且只有處于活動狀態(tài)的套接字才會主動調(diào)用該回調(diào)函數(shù)，其他不活動的套接字并不會去調(diào)用，因此，epoll 不必掃描整個(gè)文件描述符集，只需要掃描處于活動狀態(tài)的文件描述符。所有大大減低了效率。
  
• 加快內(nèi)核與用戶的消息傳遞：epoll 是通過內(nèi)核與用戶空間mmap 同一塊內(nèi)存實(shí)現(xiàn)內(nèi)核與用戶之間消息的傳遞。
  
• 內(nèi)核微調(diào)：可以根據(jù)運(yùn)行時(shí)所需內(nèi)存動態(tài)調(diào)整內(nèi)存大小。
  

Nginx的高性能有賴于其高效內(nèi)存管理，下面我們看看其內(nèi)存池設(shè)計(jì)。

Nginx 使用內(nèi)存池對內(nèi)存進(jìn)行管理，把內(nèi)存分配歸結(jié)為大內(nèi)存分配和小內(nèi)存分配。若申請的內(nèi)存大小比同頁的內(nèi)存池最大值 max 還大，則是大內(nèi)存分配，否則為小內(nèi)存分配。

1. 大塊內(nèi)存的分配請求不會直接在內(nèi)存池上分配內(nèi)存來滿足請求，而是直接向系統(tǒng)申請一塊內(nèi)存（就像直接使用 malloc 分配內(nèi)存一樣），然后將這塊內(nèi)存掛到內(nèi)存池頭部的 large 字段下。
2. 小塊內(nèi)存分配，則是從已有的內(nèi)存池?cái)?shù)據(jù)區(qū)中分配出一部分內(nèi)存。

這樣設(shè)計(jì)的好處就是減少了內(nèi)存碎片，提升了內(nèi)存分配的效率。

總結(jié)一下，nginx優(yōu)越的性能得益于其多進(jìn)程、異步事件處理的架構(gòu)，得益于其高效的內(nèi)存管理。

本回答的內(nèi)容參考了nginx官網(wǎng)上的內(nèi)容，截圖也來自于https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/

這個(gè)問題要從本質(zhì)來看，NGINX本質(zhì)上是不實(shí)現(xiàn)業(yè)務(wù)的，不是容器，而是一個(gè)看門+轉(zhuǎn)發(fā)的服務(wù)器，這個(gè)定位決定了NGINX可以做得高效，如果不是NGINX，也會有另一個(gè)服務(wù)器來實(shí)現(xiàn)得這么高效。

1.NGINX

2.采用了EPOLL的這個(gè)異步IO模型，在面對大并發(fā)時(shí)，系統(tǒng)在處理網(wǎng)絡(luò)事件上，占用的CPU極低，為高性能提供了可能。

3.在內(nèi)存使用上，NGINX不像傳統(tǒng)的寫法，在池里面分配，然后再釋放，而是為每個(gè)連接生成一個(gè)臨時(shí)池，這個(gè)池上的申請小塊內(nèi)存不進(jìn)鎖，同時(shí)這個(gè)池上的內(nèi)存也不釋放，而是在完成請求后，這個(gè)池一次性釋放。

我做過深入測試，windows下面最強(qiáng)者是iis，linux下最強(qiáng)者是nginx，nginx在win下性能很差，還不如apache

想必大家一定聽說過 Nginx，若沒聽說過它，那么一定聽過它的\"同行\(zhòng)"Apache 吧！

Nginx 的產(chǎn)生

Nginx 同 Apache 一樣都是一種 Web 服務(wù)器�；�于 REST 架構(gòu)風(fēng)格，以統(tǒng)一資源描述符（Uniform Resources Identifier）URI 或者統(tǒng)一資源定位符（Uniform Resources Locator）URL 作為溝通依據(jù)，通過 HTTP 協(xié)議提供各種網(wǎng)絡(luò)服務(wù)。

然而，這些服務(wù)器在設(shè)計(jì)之初受到當(dāng)時(shí)環(huán)境的局限，例如當(dāng)時(shí)的用戶規(guī)模，網(wǎng)絡(luò)帶寬，產(chǎn)品特點(diǎn)等局限并且各自的定位和發(fā)展都不盡相同。這也使得各個(gè) Web 服務(wù)器有著各自鮮明的特點(diǎn)。

Apache 的發(fā)展時(shí)期很長，而且是毫無爭議的世界第一大服務(wù)器。它有著很多優(yōu)點(diǎn)：穩(wěn)定、開源、跨平臺等等。

它出現(xiàn)的時(shí)間太長了，它興起的年代，互聯(lián)網(wǎng)產(chǎn)業(yè)遠(yuǎn)遠(yuǎn)比不上現(xiàn)在。所以它被設(shè)計(jì)為一個(gè)重量級的。

它不支持高并發(fā)的服務(wù)器。在 Apache 上運(yùn)行數(shù)以萬計(jì)的并發(fā)訪問，會導(dǎo)致服務(wù)器消耗大量內(nèi)存。

操作系統(tǒng)對其進(jìn)行進(jìn)程或線程間的切換也消耗了大量的 CPU 資源，導(dǎo)致 HTTP 請求的平均響應(yīng)速度降低。

這些都決定了 Apache 不可能成為高性能 Web 服務(wù)器，輕量級高并發(fā)服務(wù)器 Nginx 就應(yīng)運(yùn)而生了。

俄羅斯的工程師 Igor Sysoev，他在為 Rambler Media 工作期間，使用 C 語言開發(fā)了 Nginx。

Nginx 作為 Web 服務(wù)器一直為 Rambler Media 提供出色而又穩(wěn)定的服務(wù)。然后呢，Igor Sysoev 將 Nginx 代碼開源，并且賦予自由軟件許可證。

由于以下這幾點(diǎn)，所以，Nginx 火了：

• Nginx 使用基于事件驅(qū)動架構(gòu)，使得其可以支持?jǐn)?shù)以百萬級別的 TCP 連接。
• 高度的模塊化和自由軟件許可證使得第三方模塊層出不窮（這是個(gè)開源的時(shí)代�。�。
• Nginx 是一個(gè)跨平臺服務(wù)器，可以運(yùn)行在 Linux、Windows、FreeBSD、Solaris、AIX、Mac OS 等操作系統(tǒng)上。
• 這些優(yōu)秀的設(shè)計(jì)帶來的極大的穩(wěn)定性。

Nginx 的用武之地

Nginx 是一款自由的、開源的、高性能的 HTTP 服務(wù)器和反向代理服務(wù)器；同時(shí)也是一個(gè) IMAP、POP3、SMTP 代理服務(wù)器。

Nginx 可以作為一個(gè) HTTP 服務(wù)器進(jìn)行網(wǎng)站的發(fā)布處理，另外 Nginx 可以作為反向代理進(jìn)行負(fù)載均衡的實(shí)現(xiàn)。

關(guān)于代理

說到代理，首先我們要明確一個(gè)概念，所謂代理就是一個(gè)代表、一個(gè)渠道；此時(shí)就涉及到兩個(gè)角色，一個(gè)是被代理角色，一個(gè)是目標(biāo)角色。

被代理角色通過這個(gè)代理訪問目標(biāo)角色完成一些任務(wù)的過程稱為代理操作過程；如同生活中的專賣店，客人到 adidas 專賣店買了一雙鞋，這個(gè)專賣店就是代理，被代理角色就是 adidas 廠家，目標(biāo)角色就是用戶。

正向代理

說反向代理之前，我們先看看正向代理，正向代理也是大家最常接觸到的代理模式，我們會從兩個(gè)方面來說關(guān)于正向代理的處理模式，分別從軟件方面和生活方面來解釋一下什么叫正向代理。

在如今的網(wǎng)絡(luò)環(huán)境下，我們?nèi)绻�由于技術(shù)需要要去訪問國外的某些網(wǎng)站，此時(shí)你會發(fā)現(xiàn)位于國外的某網(wǎng)站我們通過瀏覽器是沒有辦法訪問的。

此時(shí)大家可能都會用一個(gè)操作 FQ 進(jìn)行訪問，F(xiàn)Q 的方式主要是找到一個(gè)可以訪問國外網(wǎng)站的代理服務(wù)器，我們將請求發(fā)送給代理服務(wù)器，代理服務(wù)器去訪問國外的網(wǎng)站，然后將訪問到的數(shù)據(jù)傳遞給我們！

上述這樣的代理模式稱為正向代理，正向代理最大的特點(diǎn)是客戶端非常明確要訪問的服務(wù)器地址；服務(wù)器只清楚請求來自哪個(gè)代理服務(wù)器，而不清楚來自哪個(gè)具體的客戶端；正向代理模式屏蔽或者隱藏了真實(shí)客戶端信息。徹底理解正向代理和反向代理，這篇看下。

來看個(gè)示意圖（我把客戶端和正向代理框在一塊，同屬于一個(gè)環(huán)境，后面我有介紹）：

客戶端必須設(shè)置正向代理服務(wù)器，當(dāng)然前提是要知道正向代理服務(wù)器的 IP 地址，還有代理程序的端口。

如下圖：

總結(jié)來說：正向代理，\"它代理的是客戶端\"，是一個(gè)位于客戶端和原始服務(wù)器（Origin Server）之間的服務(wù)器，為了從原始服務(wù)器取得內(nèi)容，客戶端向代理發(fā)送一個(gè)請求并指定目標(biāo)（原始服務(wù)器）。

然后代理向原始服務(wù)器轉(zhuǎn)交請求并將獲得的內(nèi)容返回給客戶端�？蛻舳吮仨氁�進(jìn)行一些特別的設(shè)置才能使用正向代理。

正向代理的用途：

• 訪問原來無法訪問的資源，如 Google。
• 可以做緩存，加速訪問資源。
• 對客戶端訪問授權(quán)，上網(wǎng)進(jìn)行認(rèn)證。
• 代理可以記錄用戶訪問記錄（上網(wǎng)行為管理），對外隱藏用戶信息。

反向代理

明白了什么是正向代理，我們繼續(xù)看關(guān)于反向代理的處理方式，舉例如我國的某寶網(wǎng)站，每天同時(shí)連接到網(wǎng)站的訪問人數(shù)已經(jīng)爆表，單個(gè)服務(wù)器遠(yuǎn)遠(yuǎn)不能滿足人民日益增長的購買欲望了。

此時(shí)就出現(xiàn)了一個(gè)大家耳熟能詳?shù)拿�詞：分布式部署；也就是通過部署多臺服務(wù)器來解決訪問人數(shù)限制的問題。

某寶網(wǎng)站中大部分功能也是直接使用 Nginx 進(jìn)行反向代理實(shí)現(xiàn)的，并且通過封裝 Nginx 和其他的組件之后起了個(gè)高大上的名字：Tengine。

有興趣的童鞋可以訪問 Tengine 的官網(wǎng)查看具體的信息：

http://tengine.taobao.org/

那么反向代理具體是通過什么樣的方式實(shí)現(xiàn)的分布式的集群操作呢，我們先看一個(gè)示意圖（我把服務(wù)器和反向代理框在一塊，同屬于一個(gè)環(huán)境，后面我有介紹）：

通過上述的圖解大家就可以看清楚了，多個(gè)客戶端給服務(wù)器發(fā)送的請求，Nginx 服務(wù)器接收到之后，按照一定的規(guī)則分發(fā)給了后端的業(yè)務(wù)處理服務(wù)器進(jìn)行處理了。超詳細(xì) Nginx 極簡教程，傻瓜一看也會。

此時(shí)請求的來源也就是客戶端是明確的，但是請求具體由哪臺服務(wù)器處理的并不明確了，Nginx 扮演的就是一個(gè)反向代理角色。

客戶端是無感知代理的存在的，反向代理對外都是透明的，訪問者并不知道自己訪問的是一個(gè)代理。因?yàn)榭蛻舳瞬恍枰�任何配置就可以訪問。

反向代理，\"它代理的是服務(wù)端\"，主要用于服務(wù)器集群分布式部署的情況下，反向代理隱藏了服務(wù)器的信息。

反向代理的作用：

• 保證內(nèi)網(wǎng)的安全，通常將反向代理作為公網(wǎng)訪問地址，Web 服務(wù)器是內(nèi)網(wǎng)。
• 負(fù)載均衡，通過反向代理服務(wù)器來優(yōu)化網(wǎng)站的負(fù)載。

項(xiàng)目場景

通常情況下，我們在實(shí)際項(xiàng)目操作時(shí)，正向代理和反向代理很有可能會存在同一個(gè)應(yīng)用場景中，正向代理代理客戶端的請求去訪問目標(biāo)服務(wù)器，目標(biāo)服務(wù)器是一個(gè)反向單利服務(wù)器，反向代理了多臺真實(shí)的業(yè)務(wù)處理服務(wù)器。

另外，關(guān)注微信公眾號：Java技術(shù)棧，在后臺回復(fù)：架構(gòu)，可以獲取我整理的 N 篇最架構(gòu)教程，都是干貨。

具體的拓?fù)鋱D如下：

截了一張圖來說明正向代理和反向代理二者之間的區(qū)別，如下圖：

圖解：

• 在正向代理中，Proxy 和 Client 同屬于一個(gè) LAN（圖中方框內(nèi)），隱藏了客戶端信息。
• 在反向代理中，Proxy 和 Server 同屬于一個(gè) LAN（圖中方框內(nèi)），隱藏了服務(wù)端信息。

實(shí)際上，Proxy 在兩種代理中做的事情都是替服務(wù)器代為收發(fā)請求和響應(yīng)，不過從結(jié)構(gòu)上看正好左右互換了一下，所以把后出現(xiàn)的那種代理方式稱為反向代理了。

負(fù)載均衡

我們已經(jīng)明確了所謂代理服務(wù)器的概念，那么接下來，Nginx 扮演了反向代理服務(wù)器的角色，它是依據(jù)什么樣的規(guī)則進(jìn)行請求分發(fā)的呢？不用的項(xiàng)目應(yīng)用場景，分發(fā)的規(guī)則是否可以控制呢？

這里提到的客戶端發(fā)送的、Nginx 反向代理服務(wù)器接收到的請求數(shù)量，就是我們說的負(fù)載量。請求數(shù)量按照一定的規(guī)則進(jìn)行分發(fā)，到不同的服務(wù)器處理的規(guī)則，就是一種均衡規(guī)則。

所以將服務(wù)器接收到的請求按照規(guī)則分發(fā)的過程，稱為負(fù)載均衡。

負(fù)載均衡在實(shí)際項(xiàng)目操作過程中，有硬件負(fù)載均衡和軟件負(fù)載均衡兩種，硬件負(fù)載均衡也稱為硬負(fù)載，如 F5 負(fù)載均衡，相對造價(jià)昂貴成本較高。

但是數(shù)據(jù)的穩(wěn)定性安全性等等有非常好的保障，如中國移動中國聯(lián)通這樣的公司才會選擇硬負(fù)載進(jìn)行操作。

更多的公司考慮到成本原因，會選擇使用軟件負(fù)載均衡，軟件負(fù)載均衡是利用現(xiàn)有的技術(shù)結(jié)合主機(jī)硬件實(shí)現(xiàn)的一種消息隊(duì)列分發(fā)機(jī)制。

Nginx 支持的負(fù)載均衡調(diào)度算法方式如下：

①weight 輪詢（默認(rèn)）：接收到的請求按照順序逐一分配到不同的后端服務(wù)器，即使在使用過程中，某一臺后端服務(wù)器宕機(jī)，Nginx 會自動將該服務(wù)器剔除出隊(duì)列，請求受理情況不會受到任何影響。

這種方式下，可以給不同的后端服務(wù)器設(shè)置一個(gè)權(quán)重值（weight），用于調(diào)整不同的服務(wù)器上請求的分配率。

權(quán)重?cái)?shù)據(jù)越大，被分配到請求的幾率越大；該權(quán)重值，主要是針對實(shí)際工作環(huán)境中不同的后端服務(wù)器硬件配置進(jìn)行調(diào)整的。

②ip_hash：每個(gè)請求按照發(fā)起客戶端的 ip 的 hash 結(jié)果進(jìn)行匹配，這樣的算法下一個(gè)固定 ip 地址的客戶端總會訪問到同一個(gè)后端服務(wù)器，這也在一定程度上解決了集群部署環(huán)境下 Session 共享的問題。

③fair：智能調(diào)整調(diào)度算法，動態(tài)的根據(jù)后端服務(wù)器的請求處理到響應(yīng)的時(shí)間進(jìn)行均衡分配。

響應(yīng)時(shí)間短處理效率高的服務(wù)器分配到請求的概率高，響應(yīng)時(shí)間長處理效率低的服務(wù)器分配到的請求少，它是結(jié)合了前兩者的優(yōu)點(diǎn)的一種調(diào)度算法。

但是需要注意的是 Nginx 默認(rèn)不支持 fair 算法，如果要使用這種調(diào)度算法，請安裝 upstream_fair 模塊。

④url_hash：按照訪問的 URL 的 hash 結(jié)果分配請求，每個(gè)請求的 URL 會指向后端固定的某個(gè)服務(wù)器，可以在 Nginx 作為靜態(tài)服務(wù)器的情況下提高緩存效率。

同樣要注意 Nginx 默認(rèn)不支持這種調(diào)度算法，要使用的話需要安裝 Nginx 的 hash 軟件包。

Web 服務(wù)器對比

幾種常用 Web 服務(wù)器對比如下圖：

部署架構(gòu)上支持負(fù)載均衡

設(shè)計(jì)上采用進(jìn)程池概念

網(wǎng)絡(luò)模塊在linux上支持非阻塞epoll模型