dubbo 負載均衡

在系統中能夠啓動多個 provider 實例，consumer 發起遠程調用時，根據指定的負載均衡算法選擇一個 provider。

在本機配置多個 provider，使用不一樣的端口：

<dubbo:protocol name="dubbo" port="20880"/>

<dubbo:protocol name="dubbo" port="20881"/>

<dubbo:protocol name="dubbo" port="20882"/>

consumer 配置 loadbalance：

<dubbo:reference id="hello" loadbalance="roundrobin" interface="com.zhang.HelloService" />

dubbo 2.1.2 提供了4種不一樣的負載均衡算法，在 /META-INF/dubbo/com.alibaba.dubbo.rpc.cluster.LoadBalance 文件中：

adptive=com.alibaba.dubbo.rpc.cluster.loadbalance.LoadBalanceAdptive
random=com.alibaba.dubbo.rpc.cluster.loadbalance.RandomLoadBalance
roundrobin=com.alibaba.dubbo.rpc.cluster.loadbalance.RoundRobinLoadBalance
leastactive=com.alibaba.dubbo.rpc.cluster.loadbalance.LeastActiveLoadBalance
consistenthash=com.alibaba.dubbo.rpc.cluster.loadbalance.ConsistentHashLoadBalance

分別對應隨機、輪詢、最少活躍、一致性哈希。
隨機、輪訓都是先考慮權重，若是沒有設置權重或者每一個 provider 的權重相同，則退化成徹底的隨機和輪訓，最少活躍沒看明白。

負載均衡的粒度是單個方法，例： com.zhang.HelloService.sayHello() 有一個負載均衡的 selector。

輪詢思想就是：維持一個 map，「接口名 + 方法名」做爲建，一個計數器做爲值，每次調用接口時，增長計數器而後取模。

public class RoundRobinLoadBalance extends AbstractLoadBalance {
    public static final String NAME = "roundrobin"; 
    private final ConcurrentMap<String, AtomicPositiveInteger> sequences = new ConcurrentHashMap<String, AtomicPositiveInteger>();
    private final ConcurrentMap<String, AtomicPositiveInteger> weightSequences = new ConcurrentHashMap<String, AtomicPositiveInteger>();

    protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, Invocation invocation) {
        String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
        // 省略權重部分代碼
        AtomicPositiveInteger sequence = sequences.get(key);
        if (sequence == null) {
            sequences.putIfAbsent(key, new AtomicPositiveInteger());
            sequence = sequences.get(key);
        }
        // 取模輪循
        return invokers.get(sequence.getAndIncrement() % length);
    }

}

 

重點分析下一致性哈希吧，它的思想和jedis一模一樣。假定如今有invoker1，invoker2，invoker3，從invoker1衍生出160個符號，根據這些符號計算哈希值，而後把哈希值和 invoker 做爲鍵值對放到 TreeMap 上。一樣操做invoker2和invoker3。在選擇invoker時，根據調用參數獲取哈希值，而後從TreeMap上搜索對應的鍵值。

// com.alibaba.dubbo.rpc.cluster.loadbalance.ConsistentHashLoadBalance.ConsistentHashSelector
public ConsistentHashSelector(List<Invoker<T>> invokers, String methodName, int identityHashCode) {
    this.virtualInvokers = new TreeMap<Long, Invoker<T>>();
    this.identityHashCode = System.identityHashCode(invokers);
    URL url = invokers.get(0).getUrl();
    
    // hash.nodes 默認爲160，表示1個invoker對應160個符號，或者說160個符號指向這個invoker
    this.replicaNumber = url.getMethodParameter(methodName, "hash.nodes", 160);
    // hash.arguments 默認爲0，默認取調用方法的第1個參數值計算哈希值
    String[] index = Constants.COMMA_SPLIT_PATTERN.split(url.getMethodParameter(methodName, "hash.arguments", "0"));
    argumentIndex = new int[index.length];
    for (int i = 0; i < index.length; i ++) {
        argumentIndex[i] = Integer.parseInt(index[i]);
    }
    for (Invoker<T> invoker : invokers) {
        for (int i = 0; i < replicaNumber / 4; i++) {
            byte[] digest = md5(invoker.getUrl().toFullString() + i);
            for (int h = 0; h < 4; h++) {
                long m = hash(digest, h);
                // 把鍵值對掛到TreeMap上
                virtualInvokers.put(m, invoker);
            }
        }
    }
}

public Invoker<T> select(Invocation invocation) {
    //獲取參數值
    String key = toKey(invocation.getArguments());
    //md5計算
    byte[] digest = md5(key);
    //計算哈希值，從TreeMap上取invoker
    Invoker<T> invoker = sekectForKey(hash(digest, 0));
    return invoker;
}

private String toKey(Object[] args) {
    StringBuilder buf = new StringBuilder();
    for (int i : argumentIndex) {
        if (i >= 0 && i < args.length) {
            buf.append(args[i]);
        }
    }
    return buf.toString();
}

private Invoker<T> sekectForKey(long hash) {
    Invoker<T> invoker;
    Long key = hash;
    if (!virtualInvokers.containsKey(key)) {
        SortedMap<Long, Invoker<T>> tailMap = virtualInvokers.tailMap(key);
        if (tailMap.isEmpty()) {
            key = virtualInvokers.firstKey();
        } else {
            key = tailMap.firstKey();
        }
    }
    invoker = virtualInvokers.get(key);
    return invoker;
}

假定存在方法：

void com.zhang.HelloService.f1(int userid);
void com.zhang.HelloService.f2(int userid);
void com.zhang.HelloService.f3(int userid, Object param);

若是採用一致性哈希負載均衡，能夠確定的是，f1(10086) 的調用都會被轉發到同一個的 provider，那 f1(10086) 和 f2(10086) 是否會轉發到同一個 provider 呢？若是但願 f3(10086, param1) 和 f3(10086, param2) 都轉發到相同的 provider，應該怎麼作？

固然，咱們也能夠實現 AbstractLoadBalance 接口，使用自定義的負載均衡算法。

 

 若是考慮到 provider 會下線，或者有新的 porvider 上線，則一致性哈希的 virtualInvokers 會從新計算。爲何要使用這種一致性哈希算法？