『壹』 取代apache的高性能web伺服器怎麼樣
Nginx是一款輕量級的Web 伺服器／反向代理伺服器及電子郵件（IMAP/POP3）代理伺服器，並在一個BSD-like 協議下發行。
由俄羅斯的程序設計師Igor Sysoev所開發，最初供俄國大型的入口網站及搜尋引擎Rambler（俄文：Рамблер）使用。 其特點是佔有內存少，並發能力強，事實上nginx的並發能力確實在同類型的網頁伺服器中表現較好.目前中國大陸使用nginx網站用戶有：新浪、網易、 騰訊,另外知名的微網志Plurk也使用nginx。
『貳』 當前技術主流中常用web伺服器有哪些，web伺服器apache和nginx的應用
nginx相對於apache的優點：
輕量級，同樣起web 服務，比apache 佔用更少的內存及資源 ，抗並發，nginx 處理請求是非同步非阻塞的，而apache 則是阻塞型的，在高並發下nginx 能保持低資源低消耗高性能，高度模塊化的設計，編寫模塊相對簡單 ，社區活躍，各種高性能模塊出品迅速啊！
『叄』 詳解下用Tomcat、Nginx結合進行負載均衡來增加系統穩定性和承壓性
如果是詳細用多了,那還是去網上下個[實戰Nginx_取代Apache的高性能Web伺服器].張宴.掃描版.pdf 看吧,希望對你 有幫助,上面一切講的都很清楚了.
『肆』 為什麼要使用nginx伺服器
我們大多數的客戶在他們的伺服器上使用Apache作為Web伺服器，尤其是部署在一個基於PHP系統的前端並且使用mod-PHP。鑒於擴張性和性能方面的原因，我們通常會建議他們改用Nginx和FPM。
Apache是非常強大的Web伺服器，模塊化結構，也是Web服務端的鼻祖。除了捆綁一些其他的工具外，Apache已經成為了世上最廣泛部署的開源系統，直到最近，世界上大多數網站仍運行著Apache系統。
但是，Apache並不是完美的，並且不再適合大規模系統。為什麼？因為他的進程模式雖然簡單而靈活，但並不適合大規模尤其是當要處理像PHP這種需要佔用大量內存應用程序代碼時。
一個典型的網路應用伺服器由兩部分組成。客戶端連接部分負責用戶瀏覽器與HTTP連接，保持長時間的TCP/IP協議，通常是1到2分鍾。對於一個大型的系統，伺服器可能要同時承擔和處理數以萬計的並發連接。
這直接與Apache只有 500條進程即500個HTTP連接的處理能力上限相沖突。而現今的瀏覽器讓這個問題更加嚴重, 因為現在的瀏覽器平均每個主機會打開六個網站鏈接（幾年前是兩個網站鏈接）。所以當超過100個用戶同時訪問時，Apache就已經滿負荷了。
第二部分是應用程序處理部分，這部分承擔了代碼運算。在大多數系統中，這部分工作是最消耗RAM和CPU資源的，因此進程數量必須被嚴格限制，通常是大約每1GB的內存10個進程，或者每個CPU核心兩個進程。因此一台4GB RAM、16內核的伺服器最多隻能運行32個應用程序進程。
但是，問題的關鍵是，Apache直接連接前端客戶端通訊組件與後端應用程序進程組件。如此一來，前端部分往往保持長時間的連接，常常達到幾分鍾，這導致後端部分將持續消耗內存和CPU資源。目前還沒有直接的方法能夠在大型系統中找到前後端服務的平衡，因此他們必須被分離開來。
目前有兩個主要的解決方法。第一個方法，也是現有系統上最容易的方法，就是在Apache前端安裝負載均衡伺服器或者Nginx來處理客戶端連接部分。負載均衡伺服器，像HAProxy或者Nginx能輕松處理成千上萬條並發的連接，並使Apache能夠真正的僅作為後端應用程序工作，來處理32個或是更多的進程。
第二種方案，也是最通用的辦法就是用Nginx替換Apache，同時使用PHP-PFM作為應用伺服器。就像之前所提到的，這將分割前端客戶端通信部分和後端應用程序部分。Nginx處理HTTP通訊協議，同時FPM處理後端應用程序部分，和那32個進程進行交互。
然而這幾種方法仍然還存在一些問題，主要是如何載入伺服器的RPC調用，以及如何釋放已經完成的RPC調用。 這兩個問題都會在其他的博客中加以詳解。
另外，只使用Nginx的解決方法會給那些嚴重依賴於Apache功能的應用程序帶來問題，尤其是特別依賴rewrite rules, .htaccess, 或者mod_security等一些可選組件的應用程序。在這種情況下，在Apache前端增加安裝Nginx是最好的方法。
通常來說，所有新的系統都應該使用Nginx和PHP-FPM來部署。這能提供高性能增長特性，並且是平衡用戶和內存，CPU資源的最佳選擇。已存在的系統可以在前端使用Nginx或者HAProxy以達到同樣的效果，以便在當今現代網路環境中為用戶提供更優質的服務。
『伍』 如何理解openresty標榜的非同步非阻塞高性能web伺服器
OpenResty （也稱為 ngx_openresty）是一個全功能的 Web 應用伺服器，它打包了標準的 Nginx 核心，很多的常用的第三方模塊，以及它們的大多數依賴項。
OpenResty 通過匯聚各種設計精良的 Nginx 模塊,從而將 Nginx 有效的變成一個強大的 Web 應用伺服器,這樣, Web 開發人員可以使用 Lua 腳本語言調動 Nginx 支持的各種C以及Lua 模塊,快速構造出足以勝任 10K+ 並發連接響應的超高性能Web 應用系統.
OpenResty 的目標是讓你的Web服務直接跑在 Nginx 服務內部,充分利用 Nginx 的非阻塞 I/O 模型,不僅僅對 HTTP 客戶端請求,甚至於對遠程後端諸如MySQL,PostgreSQL,~Memcaches 以及 ~Redis 等都進行一致的高性能響應.
『陸』 Linux系統下面的web伺服器用的比較多的是apache，好像有個nginx，聽說性能比apache高
在我的印象裡面用nginx確實也不少，但是去面試的時候發現上了點規模的都是用nginx。因為nginx處理並發的能力要比apache好很多，以前做過測試在不做負載均衡橫和集群的情況下單機apache在6~8K，用nginx可以到2W，至於為什麼相信網上有更多的詳細資料
『柒』 LVS+Nginx+DNS+web伺服器組成的反向代理解析流程是什麼
這個架構我完全無法理解，為毛要2台lvs，一般2台lvs是為了分流或高可用，好吧我暫時這么理解他的意圖，1台nginx是作為反向代理，簡單理解就是在客戶端看來伺服器端就是一台機器，防止其他人員了解你的後端架構和處理流程，nginx也可以減輕web的資源消耗主要是內存和io，也可以配置當成日誌伺服器，減輕web的壓力，但是他後端就一台web啊，用這個架構為毛啊，好吧我暫時理解為他是為了以後方便拓展架構；1台dns伺服器，為毛啊，無法理解，如果只是為了網站本身需要完全可以自解析，直接寫hosts不是更方便，好吧，其實架設dns伺服器是個好習慣，但是在資源有限的前提下，我認為不如把dns換成web，資源利用率更高；lvs和nginx都有負載均衡的作用，小架構1台nginx完全可以搞定，2台lvs純屬浪費；至於123456的問題，nginx配置，推薦《決戰nginx》高性能web伺服器詳解與運維；至於架構原理，推薦《構建高可用linux伺服器》余洪春
簡單說下流程：正常應該是，客戶端包先到lvs，lvs做了高可用，lvs分發給nginx，nginx查詢dns後分發給web
『捌』 面試官：請問Nginx為什麼比Apache性能好
Nginx才短短幾年，就拿下了web伺服器大筆江山，眾所周知，Nginx在處理大並發靜態請求方面，效率明顯高於httpd，甚至能輕松解決C10K問題。下面我們就來聊聊Web伺服器背後的一些原理。
進程是具有一定獨立功能的，在計算機中已經運行的程序的實體。在早期系統中（如linux 2.4以前），進程是基本運作單位，在支持線程的系統中（如windows，linux2.6）中，線程才是基本的運作單位，而進程只是線程的容器。程序本身只是指令、數據及其組織形式的描述，進程才是程序（那些指令和數據）的真正運行實例。若干進程有可能與同一個程序相關系，且每個進程皆可以同步（循序）或非同步（平行）的方式獨立運行。現代計算機系統可在同一段時間內以進程的形式將多個程序載入到存儲器中，並藉由時間共享（或稱時分復用），以在一個處理器上表現出同時（平行性）運行的感覺。同樣的，使用多線程技術（多線程即每一個線程都代表一個進程內的一個獨立執行上下文）的操作系統或計算機架構，同樣程序的平行線程，可在多 CPU 主機或網路上真正同時運行（在不同的CPU上）。
Web伺服器要為用戶提供服務，必須以某種方式，工作在某個套接字上。一般Web伺服器在處理用戶請求是，一般有如下三種方式可選擇：多進程方式、多線程方式、非同步方式。Web伺服器要為用戶提供服務，必須以某種方式，工作在某個套接字上。一般Web伺服器在處理用戶請求是，一般有如下三種方式可選擇：多進程方式、多線程方式、非同步方式。多進程方式：為每個請求啟動一個進程來處理。由於在操作系統中，生成進程、銷毀進程、進程間切換都很消耗CPU和內存，當負載高是，性能會明顯降低。優點： 穩定性！由於採用獨立進程處理獨立請求，而進程之間是獨立的，單個進程問題不會影響其他進程，因此穩定性最好。缺點： 資源佔用！當請求過大時，需要大量的進程處理請求，進程生成、切換開銷很大，而且進程間資源是獨立的，造成內存重復利用。多線程方式：一個進程中用多個線程處理用戶請求。由於線程開銷明顯小於進程，而且部分資源還可以共享，因此效率較高。優點：開銷較小！線程間部分數據是共享的，且線程生成與線程間的切換所需資源開銷比進程間切換小得多。缺點：穩定性！線程切換過快可能造成線程抖動，且線程過多會造成伺服器不穩定。非同步方式：使用非阻塞方式處理請求，是三種方式中開銷最小的。但非同步方式雖然效率高，但要求也高，因為多任務之間的調度如果出現問題，就可能出現整體故障，因此使用非同步工作的，一般是一些功能相對簡單，但卻符合伺服器任務調度、且代碼中沒有影響調度的錯誤代碼存在的程序。優點：性能最好！一個進程或線程處理多個請求，不需要額外開銷，性能最好，資源佔用最低。缺點：穩定性！某個進程或線程出錯，可能導致大量請求無法處理，甚至導致整個服務宕機。
從上圖中我們可以看出，可以看出，越往後，阻塞越少，理論上效率也是最優。其五種I/O模型中，前三種屬於同步I/O，後兩者屬於非同步I/O。
同步I/O:
非同步I/O:
非同步 I/O 和 信號驅動I/O的區別:
注，其中iocp是Windows實現的，select、poll、epoll是Linux實現的，kqueue是FreeBSD實現的，/dev/poll是SUN的Solaris實現的。select、poll對應第3種（I/O復用）模型，iocp對應第5種（非同步I/O）模型，那麼epoll、kqueue、/dev/poll呢？其實也同select屬於同一種模型，只是更高級一些，可以看作有了第4種（信號驅動I/O）模型的某些特性，如callback機制。
答案是，他們無輪詢。因為他們用callback取代了。想想看，當套接字比較多的時候，每次select()都要通過遍歷FD_SETSIZE個Socket來完成調度，不管哪個Socket是活躍的，都遍歷一遍。這會浪費很多CPU時間。如果能給套接字注冊某個回調函數，當他們活躍時，自動完成相關操作，那就避免了輪詢，這正是epoll、kqueue、/dev/poll做的。這樣子說可能不好理解，那麼我說一個現實中的例子，假設你在大學讀書，住的宿舍樓有很多間房間，你的朋友要來找你。select版宿管大媽就會帶著你的朋友挨個房間去找，直到找到你為止。而epoll版宿管大媽會先記下每位同學的房間號，你的朋友來時，只需告訴你的朋友你住在哪個房間即可，不用親自帶著你的朋友滿大樓找人。如果來了10000個人，都要找自己住這棟樓的同學時，select版和epoll版宿管大媽，誰的效率更高，不言自明。同理，在高並發伺服器中，輪詢I/O是最耗時間的操作之一，select、epoll、/dev/poll的性能誰的性能更高，同樣十分明了。
誠然，Windows的IOCP非常出色，目前很少有支持asynchronous I/O的系統，但是由於其系統本身的局限性，大型伺服器還是在UNIX下。而且正如上面所述，kqueue、epoll、/dev/poll 與 IOCP相比，就是多了一層從內核數據到應用層的阻塞，從而不能算作asynchronous I/O類。但是，這層小小的阻塞無足輕重，kqueue、epoll、/dev/poll 已經做得很優秀了。
只有IOCP(windows實現)是asynchronous I/O，其他機制或多或少都會有一點阻塞。select（Linux實現）低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善epoll(Linux實現)、kqueue（FreeBSD實現）、/dev/poll（Solaris實現）是Reacor模式，IOCP是Proactor模式。Apache 2.2.9之前只支持select模型，2.2.9之後支持epoll模型Nginx 支持epoll模型Java nio包是select模型
我們都知道Apache有三種工作模塊，分別為prefork、worker、event。prefork：多進程，每個請求用一個進程響應，這個過程會用到select機制來通知。worker：多線程，一個進程可以生成多個線程，每個線程響應一個請求，但通知機制還是select不過可以接受更多的請求。event：基於非同步I/O模型，一個進程或線程，每個進程或線程響應多個用戶請求，它是基於事件驅動（也就是epoll機制）實現的。
如果不用「--with-mpm」顯式指定某種MPM,prefork就是Unix平台上預設的MPM.它所採用的預派生子進程方式也是 Apache1.3中採用的模式。prefork本身並沒有使用到線程，2.0版使用它是為了與1.3版保持兼容性；另一方面，prefork用單獨的子進程來處理不同的請求，進程之間是彼此獨立的,這也使其成為最穩定的MPM之一。
相對於prefork，worker是2.0版中全新的支持多線程和多進程混合模型的MPM。由於使用線程來處理，所以可以處理相對海量的請求，而系統資源的開銷要小於基於進程的伺服器。但是，worker也使用了多進程,每個進程又生成多個線程，以獲得基於進程伺服器的穩定性，這種MPM的工作方 式將是Apache2.0的發展趨勢。
一個進程響應多個用戶請求，利用callback機制，讓套接字復用，請求過來後進程並不處理請求，而是直接交由其他機制來處理，通過epoll機制來通知請求是否完成；在這個過程中，進程本身一直處於空閑狀態，可以一直接收用戶請求。可以實現一個進程程響應多個用戶請求。支持持海量並發連接數，消耗更少的資源。
有幾個基本條件：
剛好，Nginx 支持以上所有特性。所以Nginx官網上說，Nginx支持50000並發，是有依據的。
傳統上基於進程或線程模型架構的web服務通過每進程或每線程處理並發連接請求，這勢必會在網路和I/O操作時產生阻塞，其另一個必然結果則是對內存或CPU的利用率低下。生成一個新的進程/線程需要事先備好其運行時環境，這包括為其分配堆內存和棧內存，以及為其創建新的執行上下文等。這些操作都需要佔用CPU，而且過多的進程/線程還會帶來線程抖動或頻繁的上下文切換，系統性能也會由此進一步下降。另一種高性能web伺服器/web伺服器反向代理：Nginx（Engine X），nginx的主要著眼點就是其高性能以及對物理計算資源的高密度利用，因此其採用了不同的架構模型。受啟發於多種操作系統設計中基於「事件」的高級處理機制，nginx採用了模塊化、事件驅動、非同步、單線程及非阻塞的架構，並大量採用了多路復用及事件通知機制。在nginx中，連接請求由為數不多的幾個僅包含一個線程的進程worker以高效的回環(run-loop)機制進行處理，而每個worker可以並行處理數千個的並發連接及請求。
Nginx會按需同時運行多個進程：一個主進程(master)和幾個工作進程(worker)，配置了緩存時還會有緩存載入器進程(cache loader)和緩存管理器進程(cache manager)等。所有進程均是僅含有一個線程，並主要通過「共享內存」的機制實現進程間通信。主進程以root用戶身份運行，而worker、cache loader和cache manager均應以非特權用戶身份運行。
主進程主要完成如下工作：
註：如果負載以CPU密集型應用為主，如SSL或壓縮應用，則worker數應與CPU數相同；如果負載以IO密集型為主，如響應大量內容給客戶端，則worker數應該為CPU個數的1.5或2倍。
Nginx的代碼是由一個核心和一系列的模塊組成, 核心主要用於提供Web Server的基本功能，以及Web和Mail反向代理的功能；還用於啟用網路協議，創建必要的運行時環境以及確保不同的模塊之間平滑地進行交互。不過，大多跟協議相關的功能和某應用特有的功能都是由nginx的模塊實現的。這些功能模塊大致可以分為事件模塊、階段性處理器、輸出過濾器、變數處理器、協議、upstream和負載均衡幾個類別，這些共同組成了nginx的http功能。事件模塊主要用於提供OS獨立的(不同操作系統的事件機制有所不同)事件通知機制如kqueue或epoll等。協議模塊則負責實現nginx通過http、tls/ssl、smtp、pop3以及imap與對應的客戶端建立會話。在Nginx內部，進程間的通信是通過模塊的pipeline或chain實現的；換句話說，每一個功能或操作都由一個模塊來實現。例如，壓縮、通過FastCGI或uwsgi協議與upstream伺服器通信，以及與memcached建立會話等。
處理靜態文件，索引文件以及自動索引；反向代理加速(無緩存)，簡單的負載均衡和容錯；FastCGI，簡單的負載均衡和容錯；模塊化的結構。過濾器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI過濾器中，到同一個 proxy 或者 FastCGI 的多個子請求並發處理；SSL 和 TLS SNI 支持；
使用外部 HTTP 認證伺服器重定向用戶到 IMAP/POP3 後端；使用外部 HTTP 認證伺服器認證用戶後連接重定向到內部的 SMTP 後端；認證方法：POP3: POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5;IMAP: IMAP LOGIN;SMTP: AUTH LOGIN PLAIN CRAM-MD5;SSL 支持；在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 支持；
FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64;Linux 2.2, 2.4, 2.6 i386; Linux 2.6 amd64;Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;MacOS X (10.4) PPC;Windows 編譯版本支持 windows 系列操作系統
一個主進程和多個工作進程，工作進程運行於非特權用戶；kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 支持；kqueue支持的不同功能包括 EV_CLEAR, EV_DISABLE （臨時禁止事件）， NOTE_LOWAT, EV_EOF, 有效數據的數目，錯誤代碼；sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+), 和 sendfilev (Solaris 8 7/01+) 支持；輸入過濾 (FreeBSD 4.1+) 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 支持；10,000 非活動的 HTTP keep-alive 連接僅需要 2.5M 內存。最小化的數據拷貝操作；
基於IP 和名稱的虛擬主機服務；Memcached 的 GET 介面；支持 keep-alive 和管道連接；靈活簡單的配置；重新配置和在線升級而無須中斷客戶的工作進程；可定製的訪問日誌，日誌寫入緩存，以及快捷的日誌回卷；4xx-5xx 錯誤代碼重定向；基於 PCRE 的 rewrite 重寫模塊；基於客戶端 IP 地址和 HTTP 基本認證的訪問控制；PUT, DELETE, 和 MKCOL 方法；支持 FLV （Flash 視頻）；帶寬限制；
在高連接並發的情況下，Nginx是Apache伺服器不錯的替代品: Nginx在美國是做虛擬主機生意的老闆們經常選擇的軟體平台之一. 能夠支持高達 50,000 個並發連接數的響應, 感謝Nginx為我們選擇了 epoll and kqueue 作為開發模型。Nginx作為負載均衡伺服器: Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務, 也可以支持作為 HTTP代理 伺服器對外進行服務. Nginx採用C進行編寫, 不論是系統資源開銷還是CPU使用效率都比 Perlbal 要好很多。作為郵件代理伺服器: Nginx 同時也是一個非常優秀的郵件代理伺服器（最早開發這個產品的目的之一也是作為郵件代理伺服器）, Last.fm 描述了成功並且美妙的使用經驗.Nginx 安裝非常的簡單 , 配置文件非常簡潔（還能夠支持perl語法）,Bugs 非常少的伺服器: Nginx 啟動特別容易, 並且幾乎可以做到7*24不間斷運行，即使運行數個月也不需要重新啟動. 你還能夠 不間斷服務的情況下進行軟體版本的升級 。Nginx 的誕生主要解決C10K問題
『玖』 為什麼 Nginx 已經這么成熟，Python 還有各種如 web.py 等 web 框架
nginx是伺服器，web.py是web應用框架。
簡言之，前者封裝對網路io的處理，後者負責具體應用的邏輯，解決的問題是不一樣的。形象點呢，一個請求來了，nginx先把請求攔下來，發現要的是現成的東西(靜態文件)，它就直接把現成的靜態文件返回給客戶端，這樣速度非常快，如果是其他的請求，再交給web.py解決，web.py解決完了之後，只是生成要返回的內容，並不自己做網路io，而是由nginx處理的。
這樣多好，一個安心處理網路、並發，順便把遇到簡單的請求直接ko掉。另一個專心處理應用的邏輯。
當然nginx能做的不只是這些，而為了開發方便web.py等框架都是內置簡單的web伺服器的。
至於tornado，它裡面既有web應用框架，也有web伺服器，而且這個伺服器用的還是高性能單線程非阻塞非同步的模型，是個例外。