負載均衡算法及其Java代碼實現

什麼是負載均衡

負載均衡，英文 名稱爲Load Balance，指由多臺服務器以對稱的方式組成一個服務器集合，每臺服務器都具備等價的地位，均可以單獨對外提供服務而無須其餘服務器的輔助。經過某種 負載分擔技術，將外部發送來的請求均勻分配到對稱結構中的某一臺服務器上，而接收到請求的服務器獨立地迴應客戶的請求。負載均衡可以平均分配客戶請求到服 務器陣列，藉此提供快速獲取重要數據，解決大量併發訪問服務問題，這種集羣技術能夠用最少的投資得到接近於大型主機的性能。

在進入正題前，先寫一個類來模擬Ip列表：

public class IpMap{
// 待路由的Ip列表，Key表明Ip，Value表明該Ip的權重
  public static HashMap<String, Integer> serverWeightMap = 
          new HashMap<String, Integer>();
 
 static
 {
     serverWeightMap.put("192.168.1.100", 1);
     serverWeightMap.put("192.168.1.101", 1);
    // 權重爲4
     serverWeightMap.put("192.168.1.102", 4);
     serverWeightMap.put("192.168.1.103", 1);
     serverWeightMap.put("192.168.1.104", 1);
     // 權重爲3
     serverWeightMap.put("192.168.1.105", 3);
     serverWeightMap.put("192.168.1.106", 1);
     // 權重爲2
     serverWeightMap.put("192.168.1.107", 2);
     serverWeightMap.put("192.168.1.108", 1);

     serverWeightMap.put("192.168.1.109", 1);
     serverWeightMap.put("192.168.1.110", 1);

輪詢（Round Robin）法

輪詢法即Round Robin法，其代碼實現大體以下：

public class RoundRobin{
private static Integer pos = 0;

public static String getServer()
{
    // 重建一個Map，避免服務器的上下線致使的併發問題
    Map<String, Integer> serverMap = 
            new HashMap<String, Integer>();
    serverMap.putAll(IpMap.serverWeightMap);
    
    // 取得Ip地址List
    Set<String> keySet = serverMap.keySet();
    ArrayList<String> keyList = new ArrayList<String>();
    keyList.addAll(keySet);
    
    String server = null;
    synchronized (pos)
    {
        if (pos > keySet.size())
            pos = 0;
        server = keyList.get(pos);
        pos ++;
    }
        return server;
}
}

因爲serverWeightMap中的地址列表是動態的，隨時可能有機器上線、 下線或者宕機，所以爲了不可能出現的併發問題，方法內部要新建局部變量serverMap，現將serverMap中的內容複製到線程本地，以免被多 個線程修改。這樣可能會引入新的問題，複製之後serverWeightMap的修改沒法反映給serverMap，也就是說這一輪選擇服務器的過程當中， 新增服務器或者下線服務器，負載均衡算法將沒法獲知。新增無所謂，若是有服務器下線或者宕機，那麼可能會訪問到不存在的地址。所以，服務調用端須要有相應的容錯處理，好比從新發起一次SERVER選擇並調用。

對於當前輪詢的位置變量pos，爲了保證服務器選擇的順序性，須要在操做時對其加鎖，使得同一時刻只能有一個線程能夠修改pos的值，不然當pos變量被併發修改，則沒法保證服務器選擇的順序性，甚至有可能致使keyList數組越界。

輪詢法的優勢在於：試圖作到請求轉移的絕對均衡。

輪詢法的缺點在於：爲了作到請求轉移的絕對均衡，必須付出至關大的代價，由於爲了保證pos變量修改的互斥性，須要引入重量級的悲觀鎖synchronized，這將會致使該段輪詢代碼的併發吞吐量發生明顯的降低。

隨機（Random）法

經過系統隨機函數，根據後端服務器列表的大小值來隨機選擇其中一臺進行訪問。由機率統計理論能夠得知，隨着調用量的增大，其實際效果愈來愈接近於平均分配流量到每一臺後端服務器，也就是輪詢的效果。

隨機法的代碼實現大體以下：

public class Random{
public static String getServer()
{
    // 重建一個Map，避免服務器的上下線致使的併發問題
    Map<String, Integer> serverMap = 
            new HashMap<String, Integer>();
    serverMap.putAll(IpMap.serverWeightMap);
    
    // 取得Ip地址List
    Set<String> keySet = serverMap.keySet();
    ArrayList<String> keyList = new ArrayList<String>();
    keyList.addAll(keySet);
    
    java.util.Random random = new java.util.Random();
    int randomPos = random.nextInt(keyList.size());
    
    return keyList.get(randomPos);
}
}

總體代碼思路和輪詢法一致，先重建serverMap，再獲取到server列表。在選取server的時候，經過Random的nextInt方法取0~keyList.size()區間的一個隨機值，從而從服務器列表中隨機獲取到一臺服務器地址進行返回。基於機率統計的理論，吞吐量越大，隨機算法的效果越接近於輪詢算法的效果。

源地址哈希（Hash）法

源地址哈希的思想是獲取客戶端訪問的IP地址值，經過哈希函數計算獲得一個數值，用該數值對服務器列表的大小進行取模運算，獲得的結果即是要訪問的服務器的序號。源地址哈希算法的代碼實現大體以下：

public class Hash{
public static String getServer()
{
    // 重建一個Map，避免服務器的上下線致使的併發問題
    Map<String, Integer> serverMap = 
            new HashMap<String, Integer>();
    serverMap.putAll(IpMap.serverWeightMap);
    
    // 取得Ip地址List
    Set<String> keySet = serverMap.keySet();
    ArrayList<String> keyList = new ArrayList<String>();
    keyList.addAll(keySet);
    
    // 在Web應用中可經過HttpServlet的getRemoteIp方法獲取
    String remoteIp = "127.0.0.1";
    int hashCode = remoteIp.hashCode();
    int serverListSize = keyList.size();
    int serverPos = hashCode % serverListSize;
    
    return keyList.get(serverPos);
}
}

前兩部分和輪詢法、隨機法同樣就不說了，差異在於路由選擇部分。經過客戶端的ip也就是remoteIp，取得它的Hash值，對服務器列表的大小取模，結果即是選用的服務器在服務器列表中的索引值。

源地址哈希法的優勢在於：保證了相同客戶端IP地址將會被哈希到同一臺後端服務器，直到後端服務器列表變動。根據此特性能夠在服務消費者與服務提供者之間創建有狀態的session會話。

源地址哈希算法的缺點在於：**除非集羣中服務器的很是穩定，基本不會上下線，不然一旦有服務器上線、下線，那麼經過源地址哈希算法路由到的服務器是服務器上線、下線前路由到的服務器的機率很是低，若是是session則取不到session，若是是緩存則可能引起"雪崩"。若是這麼解釋不適合明白，能夠看我以前的一篇文章MemCache超詳細解讀，**一致性Hash算法部分。

加權輪詢（Weight Round Robin）法

不一樣的服務器可能機器配置和當前系統的負載並不相同，所以它們的抗壓能力也不盡相 同，給配置高、負載低的機器配置更高的權重，讓其處理更多的請求，而低配置、高負載的機器，則給其分配較低的權重，下降其系統負載。加權輪詢法能夠很好地 處理這一問題，並將請求順序按照權重分配到後端。加權輪詢法的代碼實現大體以下：

public class WeightRoundRobin{
private static Integer pos;

public static String getServer()
{
    // 重建一個Map，避免服務器的上下線致使的併發問題
    Map<String, Integer> serverMap = 
            new HashMap<String, Integer>();
    serverMap.putAll(IpMap.serverWeightMap);
    
    // 取得Ip地址List
    Set<String> keySet = serverMap.keySet();
    Iterator<String> iterator = keySet.iterator();
    
    List<String> serverList = new ArrayList<String>();
    while (iterator.hasNext())
    {
        String server = iterator.next();
        int weight = serverMap.get(server);
        for (int i = 0; i < weight; i++)
            serverList.add(server);
    }
    
    String server = null;
    synchronized (pos)
    {
        if (pos > keySet.size())
            pos = 0;
        server = serverList.get(pos);
        pos ++;
    }
    
    return server;
}
}

與輪詢法相似，只是在獲取服務器地址以前增長了一段權重計算的代碼，根據權重的大小，將地址重複地增長到服務器地址列表中，權重越大，該服務器每輪所得到的請求數量越多。

加權隨機（Weight Random）法

與加權輪詢法相似，加權隨機法也是根據後端服務器不一樣的配置和負載狀況來配置不一樣的權重。不一樣的是，它是按照權重來隨機選擇服務器的，而不是順序。加權隨機法的代碼實現以下：

public class WeightRandom{
public static String getServer()
{
    // 重建一個Map，避免服務器的上下線致使的併發問題
    Map<String, Integer> serverMap = 
            new HashMap<String, Integer>();
    serverMap.putAll(IpMap.serverWeightMap);
    
    // 取得Ip地址List
    Set<String> keySet = serverMap.keySet();
    Iterator<String> iterator = keySet.iterator();
    
    List<String> serverList = new ArrayList<String>();
    while (iterator.hasNext())
    {
        String server = iterator.next();
        int weight = serverMap.get(server);
        for (int i = 0; i < weight; i++)
            serverList.add(server);
    }
    
    java.util.Random random = new java.util.Random();
    int randomPos = random.nextInt(serverList.size());
    
    return serverList.get(randomPos);
}
}

這段代碼至關因而隨機法和加權輪詢法的結合，比較好理解，就不解釋了。

最小鏈接數（Least Connections）法

前面幾種方法費盡心思來實現服務消費者請求次數分配的均衡，固然這麼作是沒錯的，能夠爲後端的多臺服務器平均分配工做量，最大程度地提升服務器的利用率，可是實際狀況是否真的如此？實際狀況中，請求次數的均衡真的能表明負載的均衡嗎？這是一個值得思考的問題。

上面的問題，再換一個角度來講就是：之後端服務器的視角來觀察系統的負載，而非請求發起方來觀察。最小鏈接數法便屬於此類。

最小鏈接數算法比較靈活和智能，因爲後端服務器的配置不盡相同，對於請求的處理有 快有慢，它正是根據後端服務器當前的鏈接狀況，動態地選取其中當前積壓鏈接數最少的一臺服務器來處理當前請求，儘量地提升後端服務器的利用效率，將負載 合理地分流到每一臺機器。因爲最小鏈接數設計服務器鏈接數的彙總和感知，設計與實現較爲繁瑣，此處就不說它的實現了。