沒有聽過nginx？那麼一定聽過它的"同行"apache吧！nginx同apache一樣都是一種web伺服器。基於rest架構風格，以統一資源描述符(uniform resources identifier)uri或者統一資源定位符(uniform resources locator)url作為溝通依據，通過http協議提供各種網路服務。
然而，這些伺服器在設計之初受到當時環境的侷限，例如當時的使用者規模，網路頻寬，產品特點等侷限並且各自的定位和發展都不盡相同。這也使得各個web伺服器有著各自鮮明的特點。
apache的發展時期很長，而且是毫無爭議的世界第一大伺服器。它有著很多優點：穩定、開源、跨平台等等。它出現的時間太長了，它興起的年代，網際網路產業遠遠比不上現在。所以它被設計為乙個重量級的。它不支援高併發的伺服器。在apache上執行數以萬計的併發訪問，會導致伺服器消耗大量記憶體。作業系統對其進行程序或執行緒間的切換也消耗了大量的cpu資源，導致http請求的平均響應速度降低。
這些都決定了apache不可能成為高效能web伺服器，輕量級高併發伺服器nginx就應運而生了。
俄羅斯的工程師igor sysoev，他在為rambler media工作期間，使用c語言開發了nginx。nginx作為web伺服器一直為rambler media提供出色而又穩定的服務。
然後呢，igor sysoev將nginx**開源，並且賦予自由軟體許可證。
由於：所以，nginx火了！
nginx是一款自由的、開源的、高效能的http伺服器和反向**伺服器；同時也是乙個imap、pop3、smtp**伺服器；nginx可以作為乙個http伺服器進行**的發布處理，另外nginx可以作為反向**進行負載均衡的實現。
說到**，首先我們要明確乙個概念，所謂**就是乙個代表、乙個渠道；
此時就設計到兩個角色，乙個是被**角色，乙個是目標角色，被**角色通過這個**訪問目標角色完成一些任務的過程稱為**操作過程；如同生活中的專賣店~客人到adidas專賣店買了一雙鞋，這個專賣店就是**，被**角色就是adidas廠家，目標角色就是使用者。
說反向**之前，我們先看看正向**，正向**也是大家最常接觸的到的**模式，我們會從兩個方面來說關於正向**的處理模式，分別從軟體方面和生活方面來解釋一下什麼叫正向**。
在如今的網路環境下，我們如果由於技術需要要去訪問國外的某些**，此時你會發現位於國外的某**我們通過瀏覽器是沒有辦法訪問的，此時大家可能都會用乙個操作fq進行訪問，fq的方式主要是找到乙個可以訪問國外**的**伺服器，我們將請求傳送給**伺服器，**伺服器去訪問國外的**，然後將訪問到的資料傳遞給我們！
上述這樣的**模式稱為正向**，正向**最大的特點是客戶端非常明確要訪問的伺服器位址；伺服器只清楚請求來自哪個**伺服器，而不清楚來自哪個具體的客戶端；正向**模式遮蔽或者隱藏了真實客戶端資訊。來看個示意圖（我把客戶端和正向**框在一塊，同屬於乙個環境，後面我有介紹）：
客戶端必須設定正向**伺服器，當然前提是要知道正向**伺服器的ip位址，還有**程式的埠。如圖。
總結來說：正向**，"它**的是客戶端"，是乙個位於客戶端和原始伺服器(origin server)之間的伺服器，為了從原始伺服器取得內容，客戶端向**傳送乙個請求並指定目標(原始伺服器)，然後**向原始伺服器轉交請求並將獲得的內容返回給客戶端。客戶端必須要進行一些特別的設定才能使用正向**。
正向**的用途：
（1）訪問原來無法訪問的資源，如google
（2） 可以做快取，加速訪問資源
（3）對客戶端訪問授權，上網進行認證
（4）**可以記錄使用者訪問記錄（上網行為管理），對外隱藏使用者資訊
明白了什麼是正向**，我們繼續看關於反向**的處理方式，舉例如我大**的某寶**，每天同時連線到**的訪問人數已經爆表，單個伺服器遠遠不能滿足人民日益增長的購買慾望了，此時就出現了乙個大家耳熟能詳的名詞：分布式部署；也就是通過部署多台伺服器來解決訪問人數限制的問題；某寶**中大部分功能也是直接使用nginx進行反向**實現的，並且通過封裝nginx和其他的元件之後起了個高大上的名字：tengine，有興趣的童鞋可以訪問tengine的官網檢視具體的資訊：那麼反向**具體是通過什麼樣的方式實現的分布式的集群操作呢，我們先看乙個示意圖（我把伺服器和反向**框在一塊，同屬於乙個環境，後面我有介紹）：
通過上述的**大家就可以看清楚了，多個客戶端給伺服器傳送的請求，nginx伺服器接收到之後，按照一定的規則分發給了後端的業務處理伺服器進行處理了。此時~請求的**也就是客戶端是明確的，但是請求具體由哪台伺服器處理的並不明確了，nginx扮演的就是乙個反向**角色。
客戶端是無感知**的存在的，反向**對外都是透明的，訪問者並不知道自己訪問的是乙個**。因為客戶端不需要任何配置就可以訪問。
反向**，"它**的是服務端"，主要用於伺服器集群分布式部署的情況下，反向**隱藏了伺服器的資訊。
通常情況下，我們在實際專案操作時，正向**和反向**很有可能會存在在乙個應用場景中，正向****客戶端的請求去訪問目標伺服器，目標伺服器是乙個反向單利伺服器，反向**了多台真實的業務處理伺服器。具體的拓撲圖如下：
截了一張圖來說明正向**和反向**二者之間的區別，如圖。
**：在正向**中，proxy和client同屬於乙個lan（圖中方框內），隱藏了客戶端資訊；
在反向**中，proxy和server同屬於乙個lan（圖中方框內），隱藏了服務端資訊；
實際上，proxy在兩種**中做的事情都是替伺服器代為收發請求和響應，不過從結構上看正好左右互換了一下，所以把後出現的那種**方式稱為反向**了。
我們已經明確了所謂**伺服器的概念，那麼接下來，nginx扮演了反向**伺服器的角色，它是以依據什麼樣的規則進行請求分發的呢？不用的專案應用場景，分發的規則是否可以控制呢？
這裡提到的客戶端傳送的、nginx反向**伺服器接收到的請求數量，就是我們說的負載量。
請求數量按照一定的規則進行分發到不同的伺服器處理的規則，就是一種均衡規則。
所以~將伺服器接收到的請求按照規則分發的過程，稱為負載均衡。
負載均衡在實際專案操作過程中，有硬體負載均衡和軟體負載均衡兩種，硬體負載均衡也稱為硬負載，如f5負載均衡，相對造價昂貴成本較高，但是資料的穩定性安全性等等有非常好的保障，如中國移動中國聯通這樣的公司才會選擇硬負載進行操作；更多的公司考慮到成本原因，會選擇使用軟體負載均衡，軟體負載均衡是利用現有的技術結合主機硬體實現的一種訊息佇列分發機制。
nginx支援的負載均衡排程演算法方式如下：
weight輪詢(預設)：接收到的請求按照順序逐一分配到不同的後端伺服器，即使在使用過程中，某一台後端伺服器宕機，nginx會自動將該伺服器剔除出佇列，請求受理情況不會受到任何影響。 這種方式下，可以給不同的後端伺服器設定乙個權重值(weight)，用於調整不同的伺服器上請求的分配率；權重資料越大，被分配到請求的機率越大；該權重值，主要是針對實際工作環境中不同的後端伺服器硬體配置進行調整的。
ip_hash：每個請求按照發起客戶端的ip的hash結果進行匹配，這樣的演算法下乙個固定ip位址的客戶端總會訪問到同乙個後端伺服器，這也在一定程度上解決了集群部署環境下session共享的問題。
fair：智慧型調整排程演算法，動態的根據後端伺服器的請求處理到響應的時間進行均衡分配，響應時間短處理效率高的伺服器分配到請求的概率高，響應時間長處理效率低的伺服器分配到的請求少；結合了前兩者的優點的一種排程演算法。但是需要注意的是nginx預設不支援fair演算法，如果要使用這種排程演算法，請安裝upstream_fair模組。
url_hash：按照訪問的url的hash結果分配請求，每個請求的url會指向後端固定的某個伺服器，可以在nginx作為靜態伺服器的情況下提高快取效率。同樣要注意nginx預設不支援這種排程演算法，要使用的話需要安裝nginx的hash軟體包。
Nginx 相關介紹
nginx同apache一樣都是一種web伺服器。基於rest架構風格，以統一資源描述符 uniform resources identifier uri或者統一資源定位符 uniform resources locator url作為溝通依據，通過http協議提供各種網路服務。apache的發展時...
Nginx 相關介紹
沒有聽過nginx？那麼一定聽過它的 同行 apache吧！nginx同apache一樣都是一種web伺服器。基於rest架構風格，以統一資源描述符 uniform resources identifier uri或者統一資源定位符 uniform resources locator url作為溝通...
Nginx 相關介紹
沒有聽過nginx？那麼一定聽過它的 同行 apache吧！nginx同apache一樣都是一種web伺服器。基於rest架構風格，以統一資源描述符 uniform resources identifier uri或者統一資源定位符 uniform resources locator url作為溝通...