负载均衡算法及其Java代码实现

时间 2019-12-05

原文原文链接

什么是负载均衡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数组越界。session

轮询法的优势在于：试图作到请求转移的绝对均衡。并发

轮询法的缺点在于：为了作到请求转移的绝对均衡，必须付出至关大的代价，由于为了保证pos变量修改的互斥性，须要引入重量级的悲观锁synchronized，这将会致使该段轮询代码的并发吞吐量发生明显的降低。负载均衡

随机（Random）法dom

经过系统随机函数，根据后端服务器列表的大小值来随机选择其中一台进行访问。由几率统计理论能够得知，随着调用量的增大，其实际效果愈来愈接近于平均分配流量到每一台后端服务器，也就是轮询的效果。

随机法的代码实现大体以下：

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）法

前面几种方法费尽心思来实现服务消费者请求次数分配的均衡，固然这么作是没错的，能够为后端的多台服务器平均分配工做量，最大程度地提升服务器的利用率，可是实际状况是否真的如此？实际状况中，请求次数的均衡真的能表明负载的均衡吗？这是一个值得思考的问题。

上面的问题，再换一个角度来讲就是：之后端服务器的视角来观察系统的负载，而非请求发起方来观察。最小链接数法便属于此类。

最小链接数算法比较灵活和智能，因为后端服务器的配置不尽相同，对于请求的处理有快有慢，它正是根据后端服务器当前的链接状况，动态地选取其中当前积压链接数最少的一台服务器来处理当前请求，尽量地提升后端服务器的利用效率，将负载合理地分流到每一台机器。因为最小链接数设计服务器链接数的汇总和感知，设计与实现较为繁琐，此处就不说它的实现了。