負載平衡的基本（常用）演算法

這篇部落格轉載自： http://blog.csdn.net/u014649204/article/details/25115039

        平衡演算法設計的好壞直接決定了叢集在負載平衡上的表現，設計不好的演算法，會導致叢集的負載失衡。一般的平衡演算法主要任務是決定如何選擇下一個叢集節點，然後將新的服務要求轉寄給它。有些簡單平衡方法可以獨立使用，有些必須和其它簡單或進階方法組合使用。而一個好的負載平衡演算法也並不是萬能的，它一般只在某些特殊的應用環境下才能發揮最大效用。因此在考察負載平衡演算法的同時，也要注意演算法本身的適用面，並在採取叢集部署的時候根據叢集自身的特點進行綜合考慮，把不同的演算法和技術結合起來使用。

3．1 輪轉法：

    輪轉演算法是所有調度演算法中最簡單也最容易實現的一種方法。在一個任務隊列裡，隊列的每個成員（節點）都具有相同的地位，輪轉法簡單的在這群組成員中順序輪轉選擇。在Server Load Balancer環境中，均衡器將新的請求輪流發給節點隊列中的下一節點，如此連續、周而復始，每個叢集的節點都在相等的地位下被輪流選擇。這個演算法在DNS網域名稱輪詢中被廣泛使用。

    輪轉法的活動是可預知的，每個節點被選擇的機會是1/N，因此很容易計算出節點的負載分布。輪轉法典型的適用於叢集中所有節點的處理能力和效能均相同的情況，在實際應用中，一般將它與其他簡單方法聯合使用時比較有效。

3．2 散列法

    散列法也叫雜湊法（HASH），通過單射無法復原的HASH函數，按照某種規則將網路請求發往叢集節點。雜湊法在其他幾類平衡演算法不是很有效時會顯示出特別的威力。例如，在前面提到的UDP會話的情況下，由於輪轉法和其他幾類基於串連資訊的演算法，無法識別出會話的起止標記，會引起應用混亂。

    而採取基於資料包源地址的雜湊映射可以在一定程度上解決這個問題：將具有相同源地址的資料包發給同一伺服器節點，這使得基於高層會話的事務可以以適當的方式運行。相對稱的是，基於目的地址的雜湊調度演算法可以用在Web Cache叢集中，指向同一個目標網站的訪問請求都被Server Load Balancer器發送到同一個Cache服務節點上，以避免頁面缺失而帶來的更新Cache問題。

3．3 最少串連法

    在最少串連法中，平衡器紀錄目前所有活躍串連，把下一個新的請求發給當前含有最少串連數的節點。這種演算法針對TCP串連進行，但由於不同應用對系統資源的消耗可能差異很大，而串連數無法反映出真實的應用負載，因此在使用重型Web伺服器作為叢集節點服務時（例如Apache伺服器），該演算法在平衡負載的效果上要打個折扣。為了減少這個不利的影響，可以對每個節點設定最大的串連數上限（通過閾值設定體現）。

3．4 最低缺失法

    在最低缺失法中，平衡器長期紀錄到各節點的請求情況，把下個請求發給曆史上處理請求最少的節點。與最少串連法不同的是，最低缺失記錄過去的串連數而不是當前的串連數。

3．5 最快響應法

    平衡器記錄自身到每一個叢集節點的網路回應時間，並將下一個到達的串連請求分配給回應時間最短的節點，這種方法要求使用ICMP包或基於UDP包的專用技術來主動探測各節點。

    在大多數基於LAN的叢集中，最快響應演算法工作的並不是很好，因為LAN中的ICMP包基本上都在10ms內完成回應，體現不出節點之間的差異；如果在 WAN上進行平衡的話，回應時間對於使用者就近選擇伺服器而言還是具有現實意義的；而且叢集的拓撲越分散這種方法越能體現出效果來。這種方法是進階平衡基於拓撲結構重新導向用到的主要方法。

3．6 加權法

    加權方法只能與其他方法合用，是它們的一個很好的補充。加權演算法根據節點的優先順序或當前的負載狀況（即權值）來構成Server Load Balancer的多優先順序隊列，隊列中的每個等待處理的串連都具有相同處理等級，這樣在同一個隊列裡可以按照前面的輪轉法或者最少串連法進行均衡，而隊列之間按照優先順序的先後順序進行均衡處理。在這裡權值是基於各節點能力的一個估計值。

網上比較詳細的說明

實現負載平衡的演算法

　　我們知道，負載平衡器在負載平衡裝置中的作用是至關重要的，它起著承上啟下的作用。一方面接收使用者的網路請求，一方面把請求按照某種演算法轉接到特定的應用伺服器中，實現負載平衡。所以，負載平衡器中的演算法是至關重要的。大多數負載平衡裝置實現了以下多種演算法。

　　 1、輪詢調度

　　輪詢調度(Round Robin Scheduling)演算法就是以輪詢的方式依次將請求調度到不同的伺服器，即每次調度執行i = (i + 1) mod n，並選出第i台伺服器。演算法的優點是其簡潔性，它無需記錄當前所有串連的狀態，所以它是一種無狀態調度。

　　在實際實現過程中，一般會為每台伺服器設定一個權重值，這就是權重輪詢調度演算法。

　    2、最小串連調度(Least-Connection Scheduling)

　　最小串連調度(Least-Connection Scheduling)演算法是把新的串連請求分配到當前串連數最小的伺服器。最小串連調度是一種動態調度演算法，它通過伺服器當前所活躍的串連數來估計伺服器的負載情況。

　　在實際實現過程中，一般會為每台伺服器設定一個權重值，這就是加權最小串連調度(Weighted Least-Connection Scheduling)

　　 3、 基於局部性的最少連結(LBLC)

　　基於局部性的最少連結調度(Locality-Based Least Connections Scheduling，以下簡稱為LBLC)演算法是針對請求報文的目標IP地址的負載平衡調度，目前主要用於Cache叢集系統，因為在Cache叢集中客戶請求報文的目標IP地址是變化的。

　　LBLC調度演算法先根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器是可用的且沒有超載，將請求發送到該伺服器; 若伺服器不存在，或伺服器超載或有伺服器處於其一半的工作負載，則用“最少連結”的原則選出一個可用的伺服器，將請求發送到該伺服器。

　　  4、帶複製的基於局部性最少連結(LBLCR)

　　帶複製的基於局部性最少連結調度(Locality-Based Least Connections with Replication Scheduling，以下簡稱為LBLCR)演算法也是針對目標IP地址的負載平衡，目前主要用於Cache叢集系統。它與LBLC演算法的不同之處是它要維護從一個目標IP地址到一組伺服器的映射，而LBLC演算法維護從一個目標IP地址到一台伺服器的映射。

　　LBLCR調度演算法將“熱門”網站映射到一組Cache伺服器(伺服器集合)，當該“熱門”網站的請求負載增加時，會增加集合裡的Cache伺服器，來處理不斷增長的負載; 當該“熱門”網站的請求負載降低時，會減少集合裡的Cache伺服器數目。這樣，該“熱門”網站的映像不太可能出現在所有的Cache伺服器上，從而提供Cache叢集系統的使用效率。

　　 5、目標地址散列調度(Destination Hashing Scheduling)

　　目標地址散列調度(Destination Hashing Scheduling)演算法是針對目標IP地址的負載平衡，但它是一種靜態映射演算法，通過一個散列(Hash)函數將一個目標IP地址映射到一台伺服器。

　　目標地址散列調度演算法先根據請求的目標IP地址，作為散列鍵(Hash Key)從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

　　 6、 源地址散列調度(Source Hashing Scheduling)

　　和目標地址散列調度類似，唯一的區別是按照源地址為散列函數的散列鍵。

　　在實際應用中，源地址散列調度和目標地址散列調度可以結合使用在防火牆叢集中，它們可以保證整個系統的唯一出入口。