Dubbo源碼解析實戰 - 負載均衡算法LoadBalance
1 簡介
本篇儘可能用一些簡單的數學式子和流程圖和你們一塊兒梳理一下這些集羣容錯算法.java
2 靈魂拷問
- 談談dubbo中的負載均衡算法及特色
- 最小活躍數算法中是如何統計這個活躍數的
- 簡單談談你對一致性哈希算法的認識
3 接口的繼承體系
4 RandomLoadBalance(隨機)
隨機，按權重設置隨機機率node
在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。面試
默認策略,可是這個隨機和咱們理解上的隨機仍是不同的,由於他還有個概念叫weight(權重),就是用來控制這個隨機的機率的,咱們來看代碼實現.算法
package org.apache.dubbo.rpc.cluster.loadbalance;
import org.apache.dubbo.common.URL;
import org.apache.dubbo.rpc.Invocation;
import org.apache.dubbo.rpc.Invoker;
import java.util.List;
import java.util.concurrent.ThreadLocalRandom;
/**
* 此類從多個提供者中隨機選擇一個提供者。
* 能夠爲每一個提供商定義權重：
* 若是權重都相同，則將使用random.nextInt（調用者數）。
* 若是權重不一樣，則將使用random.nextInt（w1 + w2 + ... + wn）
* 請注意，若是機器的性能優於其餘機器，則能夠設置更大的重量。
* 若是性能不是很好，則能夠設置較小的重量。
*/
public class RandomLoadBalance extends AbstractLoadBalance {
public static final String NAME = "random";
/**
* 使用隨機條件在列表之間選擇一個invoker
* @param invokers 可能的invoker列表
* @param url URL
* @param invocation Invocation
* @param <T>
* @return 被選的invoker
*/
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
// invoker的數量
int length = invokers.size();
// 每一個 invoker 有相同權重
boolean sameWeight = true;
// 每一個invoker的權重
int[] weights = new int[length];
// 第一個 invoker 的權重
int firstWeight = getWeight(invokers.get(0), invocation);
weights[0] = firstWeight;
// 權重之和
int totalWeight = firstWeight;
for (int i = 1; i < length; i++) {
int weight = getWeight(invokers.get(i), invocation);
// 保存以待後用
weights[i] = weight;
// Sum
totalWeight += weight;
if (sameWeight && weight != firstWeight) {
sameWeight = false;
}
}
if (totalWeight > 0 && !sameWeight) {
// 若是並不是每一個invoker都具備相同的權重且至少一個invoker的權重大於0，請根據totalWeight隨機選擇
int offset = ThreadLocalRandom.current().nextInt(totalWeight);
// 根據隨機值返回invoker
for (int i = 0; i < length; i++) {
offset -= weights[i];
if (offset < 0) {
return invokers.get(i);
}
}
}
// 若是全部invoker都具備相同的權重值或totalWeight = 0，則平均返回。
return invokers.get(ThreadLocalRandom.current().nextInt(length));
}
}
複製代碼
分析
- 流程圖
假設有四個集羣節點A,B,C,D,對應的權重分別是1,2,3,4,那麼請求到A節點的機率就爲1/(1+2+3+4) = 10%.B,C,D節點依次類推爲20%,30%,40%.apache
雖然這個隨機算法理解起來是比較容易的,面試通常不會問這個,可是假如咱們要實現相似的功能,他這個代碼實現的思路仍是很優雅的,很是具備借鑑意義他這個實現思路從純數學角度是很好理解的,咱們仍是按照上面數學分析中的前提條件.咱們知道總權重爲10(1+2+3+4),那麼怎麼作到按權重隨機呢?根據10隨機出一個整數,假如爲隨機出來的是2.而後依次和權重相減,好比2(隨機數)-1(A的權重) = 1,而後1(上一步計算的結果)-2(B的權重) = -1,此時-1 < 0,那麼則調用B,其餘的以此類推數組
5 RoundRobinLoadBalance(輪詢)
輪詢，按公約後的權重設置輪循比率緩存
存在慢的提供者累積請求的問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上服務器
package org.apache.dubbo.rpc.cluster.loadbalance;
import org.apache.dubbo.common.URL;
import org.apache.dubbo.rpc.Invocation;
import org.apache.dubbo.rpc.Invoker;
import java.util.Collection;
import java.util.List;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicLong;
/**
* Round robin load balance.
*/
public class RoundRobinLoadBalance extends AbstractLoadBalance {
public static final String NAME = "roundrobin";
private static final int RECYCLE_PERIOD = 60000;
protected static class WeightedRoundRobin {
private int weight;
private AtomicLong current = new AtomicLong(0);
private long lastUpdate;
public int getWeight() {
return weight;
}
public void setWeight(int weight) {
this.weight = weight;
current.set(0);
}
public long increaseCurrent() {
return current.addAndGet(weight);
}
public void sel(int total) {
current.addAndGet(-1 * total);
}
public long getLastUpdate() {
return lastUpdate;
}
public void setLastUpdate(long lastUpdate) {
this.lastUpdate = lastUpdate;
}
}
private ConcurrentMap<String, ConcurrentMap<String, WeightedRoundRobin>> methodWeightMap = new ConcurrentHashMap<String, ConcurrentMap<String, WeightedRoundRobin>>();
private AtomicBoolean updateLock = new AtomicBoolean();
/**
* 獲取爲指定invocation緩存的invocation地址列表
* for unit test only
*/
protected <T> Collection<String> getInvokerAddrList(List<Invoker<T>> invokers, Invocation invocation) {
String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
Map<String, WeightedRoundRobin> map = methodWeightMap.get(key);
if (map != null) {
return map.keySet();
}
return null;
}
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
ConcurrentMap<String, WeightedRoundRobin> map = methodWeightMap.get(key);
if (map == null) {
methodWeightMap.putIfAbsent(key, new ConcurrentHashMap<String, WeightedRoundRobin>());
map = methodWeightMap.get(key);
}
int totalWeight = 0;
long maxCurrent = Long.MIN_VALUE;
long now = System.currentTimeMillis();
Invoker<T> selectedInvoker = null;
WeightedRoundRobin selectedWRR = null;
for (Invoker<T> invoker : invokers) {
String identifyString = invoker.getUrl().toIdentityString();
WeightedRoundRobin weightedRoundRobin = map.get(identifyString);
int weight = getWeight(invoker, invocation);
if (weightedRoundRobin == null) {
weightedRoundRobin = new WeightedRoundRobin();
weightedRoundRobin.setWeight(weight);
map.putIfAbsent(identifyString, weightedRoundRobin);
}
if (weight != weightedRoundRobin.getWeight()) {
//weight changed
weightedRoundRobin.setWeight(weight);
}
long cur = weightedRoundRobin.increaseCurrent();
weightedRoundRobin.setLastUpdate(now);
if (cur > maxCurrent) {
maxCurrent = cur;
selectedInvoker = invoker;
selectedWRR = weightedRoundRobin;
}
totalWeight += weight;
}
if (!updateLock.get() && invokers.size() != map.size()) {
if (updateLock.compareAndSet(false, true)) {
try {
// copy -> modify -> update reference
ConcurrentMap<String, WeightedRoundRobin> newMap = new ConcurrentHashMap<>(map);
newMap.entrySet().removeIf(item -> now - item.getValue().getLastUpdate() > RECYCLE_PERIOD);
methodWeightMap.put(key, newMap);
} finally {
updateLock.set(false);
}
}
}
if (selectedInvoker != null) {
selectedWRR.sel(totalWeight);
return selectedInvoker;
}
// should not happen here
return invokers.get(0);
}
}
複製代碼
Nginx的負載均衡默認就是輪詢app
6 LeastActiveLoadBalance(最少活躍數)
- 最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差
- 使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。
舉個例子.每一個服務有一個活躍計數器那麼咱們假若有A,B兩個提供者.計數初始均爲0當A提供者開始處理請求,該計數+1,此時A還沒處理完,當處理完後則計數-1而B請求接收到請求處理得很快.B處理完後A還沒處理完,因此此時A,B的計數爲1,0那麼當有新的請求來的時候,就會選擇B提供者(B的活躍計數比A小)這就是文檔說的,使慢的提供者收到更少請求負載均衡
package org.apache.dubbo.rpc.cluster.loadbalance;
import org.apache.dubbo.common.URL;
import org.apache.dubbo.rpc.Invocation;
import org.apache.dubbo.rpc.Invoker;
import org.apache.dubbo.rpc.RpcStatus;
import java.util.List;
import java.util.concurrent.ThreadLocalRandom;
/**
* 過濾活動調用次數最少的調用者數量，並計算這些調用者的權重和數量。
* 若是隻有一個調用程序，則直接使用該調用程序；
* 若是有多個調用者而且權重不相同，則根據總權重隨機；
* 若是有多個調用者且權重相同，則將其隨機調用。
*/
public class LeastActiveLoadBalance extends AbstractLoadBalance {
public static final String NAME = "leastactive";
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
// invoker的總個數
int length = invokers.size();
// invoker最小的活躍數
int leastActive = -1;
// 相同最小活躍數(leastActive)的invoker個數
int leastCount = 0;
// 相同最小活躍數(leastActive)的下標
int[] leastIndexes = new int[length];
// the weight of every invokers
int[] weights = new int[length];
// 全部最不活躍invoker的預熱權重之和
int totalWeight = 0;
// 第一個最不活躍的invoker的權重, 用於於計算是否相同
int firstWeight = 0;
// 每一個最不活躍的調用者都具備相同的權重值？
boolean sameWeight = true;
// Filter out all the least active invokers
for (int i = 0; i < length; i++) {
Invoker<T> invoker = invokers.get(i);
// Get the active number of the invoker
int active = RpcStatus.getStatus(invoker.getUrl(), invocation.getMethodName()).getActive();
// Get the weight of the invoker's configuration. The default value is 100.
int afterWarmup = getWeight(invoker, invocation);
// save for later use
weights[i] = afterWarmup;
// If it is the first invoker or the active number of the invoker is less than the current least active number
if (leastActive == -1 || active < leastActive) {
// Reset the active number of the current invoker to the least active number
leastActive = active;
// Reset the number of least active invokers
leastCount = 1;
// Put the first least active invoker first in leastIndexes
leastIndexes[0] = i;
// Reset totalWeight
totalWeight = afterWarmup;
// Record the weight the first least active invoker
firstWeight = afterWarmup;
// Each invoke has the same weight (only one invoker here)
sameWeight = true;
// If current invoker's active value equals with leaseActive, then accumulating.
} else if (active == leastActive) {
// 記錄leastIndexes order最小活躍數下標
leastIndexes[leastCount++] = i;
// 累計總權重
totalWeight += afterWarmup;
// If every invoker has the same weight?
if (sameWeight && i > 0
&& afterWarmup != firstWeight) {
sameWeight = false;
}
}
}
// Choose an invoker from all the least active invokers
if (leastCount == 1) {
// 若是隻有一個最小則直接返回
return invokers.get(leastIndexes[0]);
}
if (!sameWeight && totalWeight > 0) {
// 若是權重不相同且權重大於0則按總權重數隨機
int offsetWeight = ThreadLocalRandom.current().nextInt(totalWeight);
// 並肯定隨機值落在哪一個片段上
for (int i = 0; i < leastCount; i++) {
int leastIndex = leastIndexes[i];
offsetWeight -= weights[leastIndex];
if (offsetWeight < 0) {
return invokers.get(leastIndex);
}
}
}
// 若是權重相同或權重爲0則均等隨機
return invokers.get(leastIndexes[ThreadLocalRandom.current().nextInt(leastCount)]);
}
}
複製代碼
分析
這部分代碼歸納起來就兩部分
- 活躍數和權重的統計
- 選擇invoker.也就是他把最小活躍數的invoker統計到leastIndexs數組中,若是權重一致(這個一致的規則參考上面的隨機算法)或者總權重爲0,則均等隨機調用,若是不一樣,則從leastIndexs數組中按照權重比例調用(仍是和隨機算法中的那個依次相減的思路同樣).還不明白不要緊,看下面的流程圖和數學分析
- 流程圖
理論
假設A,B,C,D節點的最小活躍數分別是1,1,2,3,權重爲1,2,3,4.則leastIndexs(該數組是最小活躍數組,由於A,B的活躍數是1,均爲最小)數組內容爲[A,B].A,B的權重是1和2,因此調用A的機率爲 1/(1+2) = 1/3,B的機率爲 2/(1+2) = 2/3
活躍數的變化是在org.apache.dubbo.rpc.filter.ActiveLimitFilter中若是沒有配置dubbo:reference的actives屬性,默認是調用前活躍數+1,調用結束-1鑑於不少人可能沒用過這個屬性,因此我把文檔截圖貼出來
另外若是使用該種負載均衡算法,則dubbo:service中還須要配置filter="activelimit"
7 ConsistentHashLoadBalance(一致性哈希)
- 一致性 Hash，相同參數的請求老是發到同一提供者
- 當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。
- 推薦閱讀
http://en.wikipedia.org/wiki/Consistent_hashing
缺省只對第一個參數 Hash，若是要修改，請配置
<dubbo:parameter key="hash.arguments" value="0,1" />複製代碼
缺省用 160 份虛擬節點，若是要修改，請配置
<dubbo:parameter key="hash.nodes" value="320" />複製代碼
package org.apache.dubbo.rpc.cluster.loadbalance;
import org.apache.dubbo.common.URL;
import org.apache.dubbo.rpc.Invocation;
import org.apache.dubbo.rpc.Invoker;
import org.apache.dubbo.rpc.support.RpcUtils;
import java.nio.charset.StandardCharsets;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.List;
import java.util.Map;
import java.util.TreeMap;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;
import static org.apache.dubbo.common.constants.CommonConstants.COMMA_SPLIT_PATTERN;
public class ConsistentHashLoadBalance extends AbstractLoadBalance {
public static final String NAME = "consistenthash";
/**
* Hash nodes name
*/
public static final String HASH_NODES = "hash.nodes";
/**
* Hash arguments name
*/
public static final String HASH_ARGUMENTS = "hash.arguments";
private final ConcurrentMap<String, ConsistentHashSelector<?>> selectors = new ConcurrentHashMap<String, ConsistentHashSelector<?>>();
@SuppressWarnings("unchecked")
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
String methodName = RpcUtils.getMethodName(invocation);
String key = invokers.get(0).getUrl().getServiceKey() + "." + methodName;
int identityHashCode = System.identityHashCode(invokers);
ConsistentHashSelector<T> selector = (ConsistentHashSelector<T>) selectors.get(key);
if (selector == null || selector.identityHashCode != identityHashCode) {
selectors.put(key, new ConsistentHashSelector<T>(invokers, methodName, identityHashCode));
selector = (ConsistentHashSelector<T>) selectors.get(key);
}
return selector.select(invocation);
}
private static final class ConsistentHashSelector<T> {
private final TreeMap<Long, Invoker<T>> virtualInvokers;
private final int replicaNumber;
private final int identityHashCode;
private final int[] argumentIndex;
ConsistentHashSelector(List<Invoker<T>> invokers, String methodName, int identityHashCode) {
this.virtualInvokers = new TreeMap<Long, Invoker<T>>();
this.identityHashCode = identityHashCode;
URL url = invokers.get(0).getUrl();
this.replicaNumber = url.getMethodParameter(methodName, HASH_NODES, 160);
String[] index = 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) {
String address = invoker.getUrl().getAddress();
for (int i = 0; i < replicaNumber / 4; i++) {
byte[] digest = md5(address + i);
for (int h = 0; h < 4; h++) {
long m = hash(digest, h);
virtualInvokers.put(m, invoker);
}
}
}
}
public Invoker<T> select(Invocation invocation) {
String key = toKey(invocation.getArguments());
byte[] digest = md5(key);
return selectForKey(hash(digest, 0));
}
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> selectForKey(long hash) {
Map.Entry<Long, Invoker<T>> entry = virtualInvokers.ceilingEntry(hash);
if (entry == null) {
entry = virtualInvokers.firstEntry();
}
return entry.getValue();
}
private long hash(byte[] digest, int number) {
return (((long) (digest[3 + number * 4] & 0xFF) << 24)
| ((long) (digest[2 + number * 4] & 0xFF) << 16)
| ((long) (digest[1 + number * 4] & 0xFF) << 8)
| (digest[number * 4] & 0xFF))
& 0xFFFFFFFFL;
}
private byte[] md5(String value) {
MessageDigest md5;
try {
md5 = MessageDigest.getInstance("MD5");
} catch (NoSuchAlgorithmException e) {
throw new IllegalStateException(e.getMessage(), e);
}
md5.reset();
byte[] bytes = value.getBytes(StandardCharsets.UTF_8);
md5.update(bytes);
return md5.digest();
}
}
}
複製代碼
該算法的代碼實現拿出來說的話篇幅較大,主要講三個關鍵詞,原理,down機影響,虛擬節點
原理
簡單講就是,假設咱們有個時鐘,各服務器節點映射放在鐘錶的時刻上,把key也映射到鐘錶的某個時刻上,而後key順時針走,碰到的第一個節點則爲咱們須要找的服務器節點
仍是假如咱們有a,b,c,d四個節點(感受整篇文章都在作這個假如....),把他們經過某種規則轉成整數,分別爲0,3,6,9.因此按照時鐘分佈以下圖
假設這個key經過某種規則轉化成1,那麼他順時針碰到的第一個節點就是b,也就是b是咱們要找的節點
這個規則你能夠本身設計,可是要注意的是,不一樣的節點名,轉換爲相同的整數的機率就是衡量這個規則的好壞,若是你能作到不一樣的節點名惟一對應一個整數,那就是棒棒噠.固然java裏面的CRC32這個類你能夠了解一下.
說到這裏可能又會有另個疑問,時鐘點數有限,萬一裝不下怎麼辦
其實這個時鐘只是方便你們理解作的比喻而已,在實際中,咱們能夠在圓環上分佈[0,2^32-1]的數字,這量級全世界的服務器均可以裝得下.
down機影響
經過上圖咱們能夠看出,當b節點掛了以後,根據順時針的規則,那麼目標節點就是c,也就是說,隻影響了一個節點,其餘節點不受影響.
若是是輪詢的取模算法,假設從N臺服務器變成了N-1臺,那麼命中率就變成1/(N-1),所以服務器越多,影響也就越大.
虛擬節點
爲何要有虛擬節點的概念呢?咱們仍是回到第一個假設,咱們仍是有a,b,c,d四個節點,他們經過某個規則轉化成0,3,6,9這種天然是均勻的.可是萬一是0,1,2,3這樣,那就是很是不均勻了.事實上, 通常的Hash函數對於節點在圓環上的映射,並不均勻.因此咱們須要引入虛擬節點,那麼什麼是虛擬節點呢?
假若有N個真實節點,把每一個真實節點映射成M個虛擬節點,再把 M*N 個虛擬節點, 散列在圓環上. 各真實節點對應的虛擬節點相互交錯分佈這樣,某真實節點down後,則把其影響平均分擔到其餘全部節點上.
也就是a,b,c,d的虛擬節點a0,a1,a2,b0,b1,b2,c0,c1,c2,d0,d1,d2散落在圓環上,假設C號節點down,則c0,c1,c2的壓力分別傳給d0,a1,b1,以下圖
參考
- https://www.jianshu.com/p/53feb7f5f5d9
- Dubbo官網
歡迎關注全是乾貨的技術公衆號:JavaEdge
相關文章
- 1. 深刻Dubbo 源碼解析 — 負載均衡LoadBalance
- 2. 深入Dubbo 源碼解析 — 負載均衡LoadBalance
- 3. Dubbo 源碼解析四 —— 負載均衡LoadBalance
- 4. dubbo源碼分析之負載均衡LoadBalance-16
- 5. dubbo負載均衡算法
- 6. Dubbo 源碼分析08 負載均衡算法
- 7. dubbo（三）：負載均衡實現解析
- 8. Dubbo剖析-負載均衡
- 9. dubbo負載均衡源碼閱讀
- 10. dubbo負載均衡
- 更多相關文章...
- • XML DOM 解析器 - XML DOM 教程
- • C# 運算符重載 - C#教程
- • Java Agent入門實戰（二）-Instrumentation源碼概述
- • 互聯網組織的未來：剖析GitHub員工的任性之源
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. 「插件」Runner更新Pro版，幫助設計師遠離996
- 2. 錯誤 707 Could not load file or assembly ‘Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKe
- 3. Jenkins 2018 報告速覽，Kubernetes使用率躍升235%！
- 4. TVI-Android技術篇之註解Annotation
- 5. android studio啓動項目
- 6. Android的ADIL
- 7. Android卡頓的檢測及優化方法彙總（線下+線上）
- 8. 登錄註冊的業務邏輯流程梳理
- 9. NDK(1)創建自己的C/C++文件
- 10. 小菜的系統框架界面設計-你的評估是我的決策
歡迎關注本站公眾號,獲取更多信息
