Nginx（四） nginx 負載均衡

早期的系統架構，基本上都是如下形式的：

客戶端傳送多個請求到伺服器，伺服器處理請求，有一些可能要與資料庫進行互補，伺服器處理完畢後，再將結果返回給客戶端。

這種架構模式對於早期的系統相對單一，併發請求相對較少的情況下是比較適合的，成本也低，但是隨著資訊數量的不斷增長，訪問量和資料量的飛速增長，以及系統業務的複雜度增加，這種架構會造成伺服器相應客戶端的請求日益緩慢，併發量特別大的時候，還容易造成伺服器直接崩潰。很明顯這是由於伺服器效能的瓶頸造成的問題，那麼如何解決這種情況呢？

我們首先想到的可能是公升級伺服器的配置，比如cpu執行頻率，加大記憶體等提高機器的物理效能來解決此問題，但是我們知道摩爾定律的日益失效，硬體的效能提公升已經不能滿足日益提公升的需求了。很明顯的乙個例子，天貓雙十一當天，某個熱銷產品的瞬時訪問量是極其龐大的，那麼類似上面的系統架構，將機器都增加到現有的頂級物理配置，都是不能夠滿足需求的。那怎麼辦呢？

上面的分析我們去掉了增加伺服器物理配置來解決問題的辦法，也就是說縱向解決問題的辦法行不通了，那麼橫向增加伺服器的數量呢？這時候集群的概念產生了，單個伺服器解決不了，我們增加伺服器的數量，然後將請求分發到各個伺服器上，將原先請求集中到單個伺服器上的情況改為將請求分發到多個伺服器上，將負載分發到不同的伺服器，也就是我們所說的負載均衡

負載均衡完美的解決了單個伺服器硬體效能瓶頸的問題，但是隨著而來的如何實現負載均衡呢？客戶端怎麼知道要將請求傳送到哪個伺服器去處理呢

靜態負載均衡演算法：主要包括輪訓演算法、基於比率的加權輪訓演算法或者基於優先順序的加權輪訓演算法。

動態負載均衡演算法：主要包括基於任務量的最少連線優化演算法、基於效能的最快相應優先演算法、**演算法及動態效能分配演算法。

靜態負載均衡演算法在一般網路環境下也能表現的比較好，動態負載均衡演算法更加適用於複雜的網路環境。

例子：①、普通輪訓演算法

這是nginx預設的輪詢演算法

例子：兩台相同的tomcat伺服器，通過localhost：8080訪問tomcat1，通過localhost：8081訪問tomcat2,現在我們要輸入localhost這個位址，可以在這兩個tomcat伺服器之間進行交替訪問。

二、修改nginx的配置檔案nginx.conf

1 upstream ordinarypolling 5 server 14 }

三、啟動nginx。然後在瀏覽器輸入localhost位址，**頁面變化：

②、基於比例加權輪詢

上述兩台tomcat伺服器基本是交替進行訪問的。但是這裡我們有個需求：

由於tomcat1的伺服器的配置更高點，我們希望該伺服器接受更多的請求，而tomcat2伺服器配置低，希望處理相對較少的請求。

那麼這時候就用到了加權輪詢機制了。

nginx.conf配置檔案如下：

1 upstream ordinarypolling 5 server 14 }

其實對比上面不加權的輪詢方式，這裡upstream指令中多了乙個weight指令。該指令用於配置前面請求處理的權重，預設值為1。

也就是說：第一種不加權的普通輪詢，其實其加權值weight都為1。

下面我們看頁面結果：

明顯8080埠號出現的次數更多，實驗的次數越多越接近我們配置的比例。

③、基於ip路由負載

我們知道乙個請求在經過乙個伺服器時，伺服器會儲存相關的會話資訊，比如session，但是該請求如果第乙個伺服器沒處理完，通過nginx輪詢到第二個伺服器上，那麼這個伺服器是沒有會話資訊的。

最典型的乙個例子：使用者第一次進入乙個系統是需要進行登入身份驗證的，首先將請求跳轉到tomcat1伺服器進行處理，登入資訊是儲存在tomcat1 上的，這時候需要進行別的操作，那麼可能會將請求輪詢到第二個tomcat2上，那麼由於tomcat2 沒有儲存會話資訊，會以為該使用者沒有登入，然後繼續登入一次，如果有多個伺服器，每次第一次訪問都要進行登入，這顯然是很影響使用者體驗的。

這裡產生的乙個問題也就是集群環境下的 session 共享，如何解決這個問題？

通常由兩種方法：

1、第一種方法是選擇乙個中介軟體，將登入資訊儲存在乙個中介軟體上，這個中介軟體可以為 redis 這樣的資料庫。那麼第一次登入，我們將session 資訊儲存在 redis 中，跳轉到第二個伺服器時，我們可以先去redis上查詢是否有登入資訊，如果有，就能直接進行登入之後的操作了，而不用進行重複登入。

2、第二種方法是根據客戶端的ip位址劃分，每次都將同乙個 ip 位址傳送的請求都分發到同乙個 tomcat 伺服器，那麼也不會存在 session 共享的問題。

而 nginx 的基於 ip 路由負載的機制就是上訴第二種形式。大概配置如下：

1 upstream ordinarypolling 6 server 15 }

注意：我們在 upstream 指令塊中增加了 ip_hash 指令。該指令就是告訴 nginx 伺服器，同乙個 ip 位址客戶端傳送的請求都將分發到同乙個 tomcat 伺服器進行處理。

④、基於伺服器響應時間負載分配

根據伺服器處理請求的時間來進行負載，處理請求越快，也就是響應時間越短的優先分配。

1 upstream ordinarypolling 6 server 15 }

通過增加了 fair 指令。

⑤、對不同網域名稱實現負載均衡

通過配合location 指令塊我們還可以實現對不同網域名稱實現負載均衡。

1 upstream wordbackend 5 6 upstream pptbackend 10 11 server 20 location /ppt/ 25 }

Nginx（四） nginx 負載均衡

Nginx（四） nginx 負載均衡

nginx 四負載均衡

nginx 負載均衡 Nginx負載均衡策略

Nginx（四） nginx 負載均衡

Nginx（四） nginx 負載均衡

nginx 四 負載均衡

nginx 負載均衡 Nginx負載均衡策略

相關推薦

nginx 四負載均衡