對于負載均衡的概念我們已經有過詳細的介紹了，那么對于負載均衡我們應該如何將其運用，發揮它的潛力呢？這就需要我們有一個良好的負載均衡策略，配合我們需要進行整頓的工作，完善一個規劃。

負載均衡策略

在實際應用中，我們可能不想僅僅是把客戶端的服務請求平均地分配給內部服務器，而不管服務器是否宕機。而是想使Pentium III服務器比Pentium II能接受更多的服務請求，一臺處理服務請求較少的服務器能分配到更多的服務請求，出現故障的服務器將不再接受服務請求直至故障恢復等等。

選擇合適的負載均衡策略，使多個設備能很好的共同完成任務，消除或避免現有網絡負載分布不均、數據流量擁擠反應時間長的瓶頸。在各負載均衡方式中，針對不同的應用需求，在OSI參考模型的第二、三、四、七層的負載均衡都有相應的負載均衡策略。

負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素：一、負載均衡算法，二、對網絡系統狀況的檢測方式和能力。

考慮到服務請求的不同類型、服務器的不同處理能力以及隨機選擇造成的負載分配不均勻等問題，為了更加合理的把負載分配給內部的多個服務器，就需要應用相應的能夠正確反映各個服務器處理能力及網絡狀態的負載均衡算法：

輪循均衡（Round Robin）：每一次來自網絡的請求輪流分配給內部中的服務器，從1至N然后重新開始。此種均衡算法適合于服務器組中的所有服務器都有相同的軟硬件配置并且平均服務請求相對均衡的情況。

權重輪循均衡（Weighted Round Robin）：根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠接受相應權值數的服務請求。例如：服務器A的權值被設計成1，B的權值是3，C的權值是6，則服務器A、B、C將分別接受到10%、30％、60％的服務請求。此種均衡算法能確保高性能的服務器得到更多的使用率，避免低性能的服務器負載過重。

隨機均衡（Random）：把來自網絡的請求隨機分配給內部中的多個服務器。

權重隨機均衡（Weighted Random）：此種均衡算法類似于權重輪循算法，不過在處理請求分擔時是個隨機選擇的過程。

響應速度均衡（Response Time）：負載均衡設備對內部各服務器發出一個探測請求（例如Ping），然后根據內部中各服務器對探測請求的最快響應時間來決定哪一臺服務器來響應客戶端的服務請求。此種均衡算法能較好的反映服務器的當前運行狀態，但這最快響應時間僅僅指的是負載均衡設備與服務器間的最快響應時間，而不是客戶端與服務器間的最快響應時間。

最少連接數均衡（Least Connection）：客戶端的每一次請求服務在服務器停留的時間可能會有較大的差異，隨著工作時間加長，如果采用簡單的輪循或隨機均衡算法，每一臺服務器上的連接進程可能會產生極大的不同，并沒有達到真正的負載均衡。最少連接數均衡算法對內部中需負載的每一臺服務器都有一個數據記錄，記錄當前該服務器正在處理的連接數量，當有新的服務連接請求時，將把當前請求分配給連接數最少的服務器，使均衡更加符合實際情況，負載更加均衡。此種均衡算法適合長時處理的請求服務，如FTP。

處理能力均衡：此種均衡算法將把服務請求分配給內部中處理負荷（根據服務器CPU型號、CPU數量、內存大小及當前連接數等換算而成）最輕的服務器，由于考慮到了內部服務器的處理能力及當前網絡運行狀況，所以此種均衡算法相對來說更加精確，尤其適合運用到第七層（應用層）負載均衡的情況下。

DNS響應均衡（Flash DNS）：在Internet上，無論是HTTP、FTP或是其它的服務請求，客戶端一般都是通過域名解析來找到服務器確切的IP地址的。在此均衡算法下，分處在不同地理位置的負載均衡設備收到同一個客戶端的域名解析請求，并在同一時間內把此域名解析成各自相對應服務器的IP地址（即與此負載均衡設備在同一位地理位置的服務器的IP地址）并返回給客戶端，則客戶端將以***收到的域名解析IP地址來繼續請求服務，而忽略其它的IP地址響應。在種均衡策略適合應用在全局負載均衡的情況下，對本地負載均衡是沒有意義的。

盡管有多種的負載均衡算法可以較好的把數據流量分配給服務器去負載，但如果負載均衡策略沒有對網絡系統狀況的檢測方式和能力，一旦在某臺服務器或某段負載均衡設備與服務器網絡間出現故障的情況下，負載均衡設備依然把一部分數據流量引向那臺服務器，這勢必造成大量的服務請求被丟失，達不到不間斷可用性的要求。所以良好的負載均衡策略應有對網絡故障、服務器系統故障、應用服務故障的檢測方式和能力：

Ping偵測：通過ping的方式檢測服務器及網絡系統狀況，此種方式簡單快速，但只能大致檢測出網絡及服務器上的操作系統是否正常，對服務器上的應用服務檢測就無能為力了。

TCP Open偵測：每個服務都會開放某個通過TCP連接，檢測服務器上某個TCP端口（如Telnet的23口，HTTP的80口等）是否開放來判斷服務是否正常。

HTTP URL偵測：比如向HTTP服務器發出一個對main.html文件的訪問請求，如果收到錯誤信息，則認為服務器出現故障。

負載均衡策略的優劣除受上面所講的兩個因素影響外，在有些應用情況下，我們需要將來自同一客戶端的所有請求都分配給同一臺服務器去負擔，例如服務器將客戶端注冊、購物等服務請求信息保存的本地數據庫的情況下，把客戶端的子請求分配給同一臺服務器來處理就顯的至關重要了。有兩種方式可以解決此問題，一是根據IP地址把來自同一客戶端的多次請求分配給同一臺服務器處理，客戶端IP地址與服務器的對應信息是保存在負載均衡設備上的；二是在客戶端瀏覽器cookie內做***的標識來把多次請求分配給同一臺服務器處理，適合通過代理服務器上網的客戶端。

還有一種路徑外返回模式（Out of Path Return），當客戶端連接請求發送給負載均衡設備的時候，中心負載均衡設備將請求引向某個服務器，服務器的回應請求不再返回給中心負載均衡設備，即繞過流量分配器，直接返回給客戶端，因此中心負載均衡設備只負責接受并轉發請求，其網絡負擔就減少了很多，并且給客戶端提供了更快的響應時間。此種模式一般用于HTTP服務器群，在各服務器上要安裝一塊虛擬網絡適配器，并將其IP地址設為服務器群的VIP，這樣才能在服務器直接回應客戶端請求時順利的達成三次握手。