負載均衡服務器有哪些

負載均衡服務器簡介

負載均衡服務器（load-balancing server）是進行負載分配的服務器。通過負載均衡服務器，將服務請求均衡分配到實際執行的服務中，從而保證整個系統的響應速度。

定義

“負載均衡服務器”是本系統的控制服務器，所有用戶的請求都首先到此服務器，然后由此服務器根據各個實際處理服務器狀態將請求具體分配到某個實際處理服務器中，對外公開的域名與IP地址都是這臺服務器。負載均衡控制與管理軟件安裝在這臺服務器上，這臺服務器一般只做負載均衡任務分配，但不是實際對網絡請求進行處理的服務器。

負載均衡服務器類型

網絡負載均衡服務器

WEB負載均衡服務器

負載均衡服務器解析

負載均衡是一個很大的話題，也是一個很小的話題，小到一個基本理念，你必須通過負載均衡提供多點服務。在架構搭建的最初最初階段，就應該實施非單點服務的架構體系，這樣才可以確保業務不被故障中斷。

最簡單的負載均衡架構如下架構示例圖：

雖然這個架構圖非常簡陋，但是的確利用DNS服務器做了負載均衡，多數大型網站都是混合式的負載均衡方案，基本都不會少了DNS的負載均衡。可以使用dig命令看看qq.com和baidu.com，其中baidu.com有4條A記錄，也就是通過DNS做了4個分支的負載均衡。

圖中還存在單點服務的地方，譬如共享文件系統的服務器端只在”web應用1“存在，不過意義非常大。

在應用系統搭建初期就規劃好共享文件的存儲路徑，為將來的擴展提供便利，也給代碼編寫提供了參考標準，避免后期再做調整。如果是租用云服務器提供商的服務器，將來直接使用對象存儲服務、CDN都比較容易。

雙備份的數據庫體系，架構簡單易維護，但可以在故障發生的時候最大程度保護數據。

雙備份的web應用，可以給前線業務提供高保障的應用系統，發布新版本的時候，還可以很方便的把其中一臺作為預發布環境，新版本內容發布和驗證完畢后再更新另外一臺應用，起碼保證了50%的業務正常運行。

配置簡單，管理簡單

當然，這僅僅只適用于時效要求低、缺少管理人員的創業型min公司。

利用負載均衡應用來搭建負載均衡架構

如圖：

雖然上圖依然非常簡單，不過也是需要不少的基礎知識做支撐的，下面分別整理和學習，便于將來搭建系統的時候使用。

負載均衡服務的實現方式

DNS負載均衡

基于DNS的負載均衡方案是最容易實施的，而且通常你也不用去管DNS服務器的性能和可用性，它的屬主會關心這些問題。但是通常DNS服務器只是通過RR算法來均衡調度，因此，用戶的在線信息需要管理好，也就是session數據需要在所有服務器間進行共享，不然用戶的登陸狀態會丟失。

反向代理負載均衡

基于反向代理服務器實施負載均衡應該是應用得最多的方式，反向代理服務工作在7層，通過轉發http請求提供服務。目前幾乎所有web容器都支持反向代理服務，如nginx。nginx可以根據實際需要定義負載均衡調度算法，權重，健康狀態檢測等參數。

默認情況下，nginx使用 round-robin 調度算法，并有健康狀態檢查和恢復主機的能力，另外還支持ip_hash，least_conn，sticky，不過有的需要安裝額外的組件。

Http重定向負載均衡

http重定向方案可以說最個性化的負載均衡方案，因為幾乎是代碼級的工作，不同于反向代理，反向代理是轉發http請求，而http重定向是web服務告訴用戶的瀏覽器去訪問另外一個url，可能是根據IP地址找到了更好的服務器，或者其他策略。例如從鏡像下載文件，中國區用戶可能會重定向到一個中國區的服務器上進行下載。這都是通過http協議中指定Location屬性來實現的。

NAT負載均衡

也叫IP負載均衡，工作在7層網絡結構里的第四層，通過對數據包中的IP地址和端口信息進行修改，從而打到負載均衡的效果。因為涉及的知識比較深，而且我也沒有實踐過，所以不深入寫了。

在《構建高性能Web站點》一書中，還提到兩種更高性能的方案，即直接路由、IP隧道，因為工作得更底層更接近硬件，所以性能會比上面的方式更高。

混合型負載均衡

在有些大型網絡，由于多個服務器群內硬件設備、各自的規模、提供的服務等的差異，可以考慮給每個服務器群采用最合適的負載均衡方式，然后又在這多個服務器群間再一次負載均衡或群集起來以一個整體向外界提供服務（即把這多個服務器群當做一個新的服務器群），從而達到最佳的性能。