Nginx 相關介紹(Nginx是什麼?能幹嗎?)

Nginx 相關介紹(Nginx是什麼?能幹嗎?)

 

 

 

 

 

 

 

 

 

 

 

Nginx的產生

沒有聽過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使用基於事件驅動架構，使得其能夠支持數以百萬級別的TCP鏈接
• 高度的模塊化和自由軟件許可證使得第三方模塊層出不窮（這是個開源的時代啊~）
• Nginx是一個跨平臺服務器，能夠運行在Linux，Windows，FreeBSD，Solaris，AIX，Mac OS等操做系統上
• 這些優秀的設計帶來的是極大的穩定性

因此，Nginx火了！

Nginx的用武之地

Nginx是一款自由的、開源的、高性能的HTTP服務器和反向代理服務器；同時也是一個IMAP、POP三、SMTP代理服務器；Nginx能夠做爲一個HTTP服務器進行網站的發佈處理，另外Nginx能夠做爲反向代理進行負載均衡的實現。

關於代理

說到代理，首先咱們要明確一個概念，所謂代理就是一個表明、一個渠道；

此時就涉及到兩個角色，一個是被代理角色，一個是目標角色，被代理角色經過這個代理訪問目標角色完成一些任務的過程稱爲代理操做過程；如同生活中的專賣店~客人到adidas專賣店買了一雙鞋，這個專賣店就是代理，被代理角色就是adidas廠家，目標角色就是用戶。

正向代理

說反向代理以前，咱們先看看正向代理，正向代理也是你們最常接觸的到的代理模式，咱們會從兩個方面來講關於正向代理的處理模式，分別從軟件方面和生活方面來解釋一下什麼叫正向代理。

在現在的網絡環境下，咱們若是因爲技術須要要去訪問國外的某些網站，此時你會發現位於國外的某網站咱們經過瀏覽器是沒有辦法訪問的，此時你們可能都會用一個操做FQ進行訪問，FQ的方式主要是找到一個能夠訪問國外網站的代理服務器，咱們將請求發送給代理服務器，代理服務器去訪問國外的網站，而後將訪問到的數據傳遞給咱們！

上述這樣的代理模式稱爲正向代理，正向代理最大的特色是客戶端很是明確要訪問的服務器地址；服務器只清楚請求來自哪一個代理服務器，而不清楚來自哪一個具體的客戶端；正向代理模式屏蔽或者隱藏了真實客戶端信息。來看個示意圖（我把客戶端和正向代理框在一塊，同屬於一個環境，後面我有介紹）：

客戶端必須設置正向代理服務器，固然前提是要知道正向代理服務器的IP地址，還有代理程序的端口。如圖。

總結來講：正向代理，"它代理的是客戶端，代客戶端發出請求"，是一個位於客戶端和原始服務器(origin server)之間的服務器，爲了從原始服務器取得內容，客戶端向代理髮送一個請求並指定目標(原始服務器)，而後代理向原始服務器轉交請求並將得到的內容返回給客戶端。客戶端必需要進行一些特別的設置才能使用正向代理。

正向代理的用途：
（1）訪問原來沒法訪問的資源，如Google
（2） 能夠作緩存，加速訪問資源
（3）對客戶端訪問受權，上網進行認證
（4）代理能夠記錄用戶訪問記錄（上網行爲管理），對外隱藏用戶信息

反向代理

明白了什麼是正向代理，咱們繼續看關於反向代理的處理方式，舉例如我大天朝的某寶網站，天天同時鏈接到網站的訪問人數已經爆表，單個服務器遠遠不能知足人民日益增加的購買慾望了，此時就出現了一個你們耳熟能詳的名詞：分佈式部署；也就是經過部署多臺服務器來解決訪問人數限制的問題；某寶網站中大部分功能也是直接使用Nginx進行反向代理實現的，而且經過封裝Nginx和其餘的組件以後起了個高大上的名字：Tengine，有興趣的童鞋能夠訪問Tengine的官網查看具體的信息：http://tengine.taobao.org/。那麼反向代理具體是經過什麼樣的方式實現的分佈式的集羣操做呢，咱們先看一個示意圖（我把服務器和反向代理框在一塊，同屬於一個環境，後面我有介紹）：

經過上述的圖解你們就能夠看清楚了，多個客戶端給服務器發送的請求，Nginx服務器接收到以後，按照必定的規則分發給了後端的業務處理服務器進行處理了。此時~請求的來源也就是客戶端是明確的，可是請求具體由哪臺服務器處理的並不明確了，Nginx扮演的就是一個反向代理角色。

客戶端是無感知代理的存在的，反向代理對外都是透明的，訪問者並不知道本身訪問的是一個代理。由於客戶端不須要任何配置就能夠訪問。

反向代理，"它代理的是服務端，代服務端接收請求"，主要用於服務器集羣分佈式部署的狀況下，反向代理隱藏了服務器的信息。

反向代理的做用：
（1）保證內網的安全，一般將反向代理做爲公網訪問地址，Web服務器是內網
（2）負載均衡，經過反向代理服務器來優化網站的負載

項目場景

一般狀況下，咱們在實際項目操做時，正向代理和反向代理頗有可能會存在在一個應用場景中，正向代理代理客戶端的請求去訪問目標服務器，目標服務器是一個反向單利服務器，反向代理了多臺真實的業務處理服務器。具體的拓撲圖以下：

兩者區別

截了一張圖來講明正向代理和反向代理兩者之間的區別，如圖。

圖解：

在正向代理中，Proxy和Client同屬於一個LAN（圖中方框內），隱藏了客戶端信息；

在反向代理中，Proxy和Server同屬於一個LAN（圖中方框內），隱藏了服務端信息；

實際上，Proxy在兩種代理中作的事情都是替服務器代爲收發請求和響應，不過從結構上看正好左右互換了一下，因此把後出現的那種代理方式稱爲反向代理了。

負載均衡

咱們已經明確了所謂代理服務器的概念，那麼接下來，Nginx扮演了反向代理服務器的角色，它是以依據什麼樣的規則進行請求分發的呢？不用的項目應用場景，分發的規則是否能夠控制呢？

這裏提到的客戶端發送的、Nginx反向代理服務器接收到的請求數量，就是咱們說的負載量。

請求數量按照必定的規則進行分發到不一樣的服務器處理的規則，就是一種均衡規則。

因此~將服務器接收到的請求按照規則分發的過程，稱爲負載均衡。

負載均衡在實際項目操做過程當中，有硬件負載均衡和軟件負載均衡兩種，硬件負載均衡也稱爲硬負載，如F5負載均衡，相對造價昂貴成本較高，可是數據的穩定性安全性等等有很是好的保障，如中國移動中國聯通這樣的公司纔會選擇硬負載進行操做；更多的公司考慮到成本緣由，會選擇使用軟件負載均衡，軟件負載均衡是利用現有的技術結合主機硬件實現的一種消息隊列分發機制。

Nginx支持的負載均衡調度算法方式以下：

1. weight輪詢(默認，經常使用)：接收到的請求按照權重分配到不一樣的後端服務器，即便在使用過程當中，某一臺後端服務器宕機，Nginx會自動將該服務器剔除出隊列，請求受理狀況不會受到任何影響。 這種方式下，能夠給不一樣的後端服務器設置一個權重值(weight)，用於調整不一樣的服務器上請求的分配率；權重數據越大，被分配到請求的概率越大；該權重值，主要是針對實際工做環境中不一樣的後端服務器硬件配置進行調整的。
2. ip_hash（經常使用）：每一個請求按照發起客戶端的ip的hash結果進行匹配，這樣的算法下一個固定ip地址的客戶端總會訪問到同一個後端服務器，這也在必定程度上解決了集羣部署環境下session共享的問題。
3. fair：智能調整調度算法，動態的根據後端服務器的請求處理到響應的時間進行均衡分配，響應時間短處理效率高的服務器分配到請求的機率高，響應時間長處理效率低的服務器分配到的請求少；結合了前二者的優勢的一種調度算法。可是須要注意的是Nginx默認不支持fair算法，若是要使用這種調度算法，請安裝upstream_fair模塊。
4. url_hash：按照訪問的url的hash結果分配請求，每一個請求的url會指向後端固定的某個服務器，能夠在Nginx做爲靜態服務器的狀況下提升緩存效率。一樣要注意Nginx默認不支持這種調度算法，要使用的話須要安裝Nginx的hash軟件包。

 幾種經常使用web服務器對比

對比項\服務器	Apache	Nginx	Lighttpd
Proxy代理	很是好	很是好	通常
Rewriter	好	很是好	通常
Fcgi	很差	好	很是好
熱部署	不支持	支持	不支持
系統壓力	很大	很小	比較小
穩定性	好	很是好	很差
安全性	好	通常	通常
靜態文件處理	通常	很是好	好
反向代理	通常	很是好	通常

淺析負載均衡的6種算法，Ngnix的5種算法。

2018年01月10日 09:20:05 Java技術棧 閱讀數 4168更多

分類專欄： 後端技術

 

版權聲明：本文爲博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接和本聲明。

本文連接： https://blog.csdn.net/youanyyou/article/details/78990133

常見的幾種負載均衡算法

一、輪詢法

將請求按順序輪流地分配到後端服務器上，它均衡地對待後端的每一臺服務器，而不關心服務器實際的鏈接數和當前的系統負載。

二、隨機法

經過系統的隨機算法，根據後端服務器的列表大小值來隨機選取其中的一臺服務器進行訪問。由機率統計理論能夠得知，隨着客戶端調用服務端的次數增多，

其實際效果愈來愈接近於平均分配調用量到後端的每一臺服務器，也就是輪詢的結果。

三、源地址哈希法

源地址哈希的思想是根據獲取客戶端的IP地址，經過哈希函數計算獲得的一個數值，用該數值對服務器列表的大小進行取模運算，獲得的結果即是客服端要訪問服務器的序號。採用源地址哈希法進行負載均衡，同一IP地址的客戶端，當後端服務器列表不變時，它每次都會映射到同一臺後端服務器進行訪問。

四、加權輪詢法

不一樣的後端服務器可能機器的配置和當前系統的負載並不相同，所以它們的抗壓能力也不相同。給配置高、負載低的機器配置更高的權重，讓其處理更多的請；而配置低、負載高的機器，給其分配較低的權重，下降其系統負載，加權輪詢能很好地處理這一問題，並將請求順序且按照權重分配到後端。

五、加權隨機法

與加權輪詢法同樣，加權隨機法也根據後端機器的配置，系統的負載分配不一樣的權重。不一樣的是，它是按照權重隨機請求後端服務器，而非順序。

六、最小鏈接數法

最小鏈接數算法比較靈活和智能，因爲後端服務器的配置不盡相同，對於請求的處理有快有慢，它是根據後端服務器當前的鏈接狀況，動態地選取其中當前

積壓鏈接數最少的一臺服務器來處理當前的請求，儘量地提升後端服務的利用效率，將負責合理地分流到每一臺服務器。

Nginx的5種負載均衡算法

一、輪詢（默認）

每一個請求按時間順序逐一分配到不一樣的後端服務器，若是後端服務器down掉，能自動剔除。

二、weight

指定輪詢概率，weight和訪問比率成正比，用於後端服務器性能不均的狀況。

例如：

upstream bakend {  
  server 192.168.0.14 weight=10; server 192.168.0.15 weight=10; }

• 1
• 2
• 3
• 4

三、ip_hash

每一個請求按訪問ip的hash結果分配，這樣每一個訪客固定訪問一個後端服務器，能夠解決session的問題。

例如：

upstream bakend {  
  ip_hash;  
  server 192.168.0.14:88; server 192.168.0.15:80; }

• 1
• 2
• 3
• 4
• 5

四、fair（第三方）

按後端服務器的響應時間來分配請求，響應時間短的優先分配。

upstream backend {  
  server server1; server server2; fair; }

• 1
• 2
• 3
• 4
• 5

五、url_hash（第三方）

按訪問url的hash結果來分配請求，使每一個url定向到同一個後端服務器，後端服務器爲緩存時比較有效。

例：在upstream中加入hash語句，server語句中不能寫入weight等其餘的參數，hash_method是使用的hash算法。

upstream backend {  
  server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32; }

• 1
• 2
• 3
• 4
• 5
• 6

tips:

upstream bakend{#定義負載均衡設備的Ip及設備狀態 ip_hash; server 127.0.0.1:9090 down; server 127.0.0.1:8080 weight=2; server 127.0.0.1:6060; server 127.0.0.1:7070 backup; }

• 1
• 2
• 3
• 4
• 5
• 6
• 7

在須要使用負載均衡的server中增長

proxy_pass http://bakend/;

• 1

每一個設備的狀態設置爲：

1.down 表示單前的server暫時不參與負載 
2.weight 默認爲1.weight越大，負載的權重就越大。 
3.max_fails ：容許請求失敗的次數默認爲1.當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤 
4.fail_timeout:max_fails次失敗後，暫停的時間。 
5.backup： 其它全部的非backup機器down或者忙的時候，請求backup機器。因此這臺機器壓力會最輕。

nginx支持同時設置多組的負載均衡，用來給不用的server來使用。

client_body_in_file_only：設置爲On，能夠講client post過來的數據記錄到文件中用來作debug。

client_body_temp_path：設置記錄文件的目錄，能夠設置最多3層目錄。

location：對URL進行匹配，能夠進行重定向或者進行新的代理，負載均衡。

推薦閱讀

乾貨：2TB架構師四階段視頻教程

面經：史上最全Java多線程面試題及答案

面經：史上最全阿里高級Java面試題

面經：史上最全Spring面試題

教程：最全Spring Boot全套視頻教程

書籍：進階Java架構師必看的15本書

工具：推薦一款在線創做流程圖、思惟導圖軟件