Nginx的負載均衡的那點事

本節就聊聊採用nginx負載均衡之後碰到的問題：

通常解決伺服器負載問題，都會通過多伺服器分載來解決。常見的解決方案有：

那我們看看nginx是如何實現負載均衡的，nginx的upstream目前支援以下幾種方式的分配

1、輪詢（預設）

每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。

2、weight

指定輪詢機率，weight和訪問比率成正比，用於後端伺服器效能不均的情況。

2、ip_hash

每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問乙個後端伺服器，可以解決session的問題。

3、fair（第三方）

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

4、url_hash（第三方）

按訪問url的hash結果來分配請求，使每個url定向到同乙個後端伺服器，後端伺服器為快取時比較有效。

upstream配置如何實現負載

當有請求到www.test1.com/www.test2.com 時請求會被分發到對應的upstream設定的伺服器列表上。test2的每一次請求分發的伺服器都是隨機的，就是第一種情況列舉的。而test1剛是根據來訪問ip的hashid來分發到指定的伺服器，也就是說該ip的請求都是轉到這個指定的伺服器上。

根據伺服器的本身的效能差別及職能，可以設定不同的引數控制。

down 表示負載過重或者不參與負載

weight 權重過大代表承擔的負載就越大

backup 其它伺服器時或down時才會請求backup伺服器

max_fails 失敗超過指定次數會暫停或請求轉往其它伺服器

fail_timeout 失敗超過指定次數後暫停時間

以上就nginx的負載均衡的簡單配置。那繼續我們的本節討論內容：

一、session問題

當我們確定一系列負載的伺服器後，那我們的web站點會分布到這些伺服器上。這個時候如果採用test2 每一次請求隨機訪問任何一台伺服器上，這樣導致你訪問a伺服器後，下一次請求又突然轉到b伺服器上。這個時候與a伺服器建立的session，傳到b站點伺服器肯定是無法正常響應的。我們看一下常用的解決方案：

第一種快取的方式比較理想，快取的效率也比較高。但是每一台請求伺服器都去訪問session會話伺服器，那不是加載重了這台session伺服器的負擔嗎？

第二種儲存到資料庫中，除了要控制session的有效期，同時加重了資料庫的負擔，所以最終的轉變為sql server 負載均衡，涉及讀，寫，過期，同步。

第三種通過nginx ip_hash負載保持對同一伺服器的會話，這種看起來最方便，最輕量。

正常情況下架構簡單的話， ip_hash可以解決session問題，但是我們來看看下面這種情況

這個時候ip_hash 收到的請求都是來自固定ip**的請求，如果**ip的負載過高就會導致ip_hash對應的伺服器負載壓力過大，這樣ip_hash就失去了負載均衡的作用了。

如果快取可以實現同步共享的話，我們可以通過多session伺服器來解決單一負載過重的問題。那memcached是否可以做session快取伺服器呢？memcachedprovider提供了session的功能，即將session儲存到資料庫中。那為什麼不直接儲存到資料庫中，而要通過memcached儲存到資料庫中呢？很簡單，如果直接儲存到資料庫中，每一次請求session有效性都要回資料庫驗證一下。其次，即使我們為資料庫建立一層快取，那這個快取也無法實現分布式共享，還是針對同一臺快取伺服器負載過重。網上也看到有用memcached實現session快取的成功案例，當然資料庫方式實現的還是比較常用的，比如開源disuz.net論壇。快取實現的小範圍分布式也是比較常用的，比如單點登入也是一種特殊情況。

兩種方案都是常用的，我們來說一下檔案壓縮資料庫，以前的方式都是將檔案二進位制壓縮至關係型資料庫，而現在nosql的流行，加上mongodb處理檔案又比較方便，所以檔案壓庫又多了一種選擇。畢竟檔案伺服器的效率和管理以及安全都不及資料庫。

原文參考自：

Nginx的負載均衡的那點事

Nginx的負載均衡的那點事

Nginx的負載均衡的那點事

Nginx的負載均衡的那點事

相關推薦