這裡相同顏色的節點均屬於同一個服務提供者，比如 Invoker1-1，Invoker1-2，……, Invoker1-160。這樣做的目的是通過引入虛擬節點，讓 Invoker 在圓環上分散開來，避免數據傾斜問題。所謂數據傾斜是指，由於節點不夠分散，導致大量請求落到了同一個節點上，而其他節點只會接收到了少量請求的情況。比如：

如上，由於 Invoker-1 和 Invoker-2 在圓環上分布不均，導致系統中75%的請求都會落到 Invoker-1 上，只有 25% 的請求會落到 Invoker-2 上。解決這個問題辦法是引入虛擬節點，通過虛擬節點均衡各個節點的請求量。

到這裡背景知識就普及完了，接下來開始分析源碼。我們先從 ConsistentHashLoadBalance 的 doSelect 方法開始看起，如下：

public class ConsistentHashLoadBalance extends AbstractLoadBalance {
?
private final ConcurrentMap<String, ConsistentHashSelector<?>> selectors =
new ConcurrentHashMap<String, ConsistentHashSelector<?>>();
?
@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;
?
// 獲取 invokers 原始的 hashcode
int identityHashCode = System.identityHashCode(invokers);
ConsistentHashSelector<T> selector = (ConsistentHashSelector<T>) selectors.get(key);
// 如果 invokers 是一個新的 List 對象，意味著服務提供者數量發生了變化，可能新增也可能減少了。
// 此時 selector.identityHashCode != identityHashCode 條件成立
if (selector == null || selector.identityHashCode != identityHashCode) {
// 創建新的 ConsistentHashSelector
selectors.put(key, new ConsistentHashSelector<T>(invokers, methodName, identityHashCode));
selector = (ConsistentHashSelector<T>) selectors.get(key);
}
?
// 調用 ConsistentHashSelector 的 select 方法選擇 Invoker
return selector.select(invocation);
}

private static final class ConsistentHashSelector<T> {...}
}

如上，doSelect 方法主要做了一些前置工作，比如檢測 invokers 列表是不是變動過，以及創建 ConsistentHashSelector。這些工作做完後，接下來開始調用 ConsistentHashSelector 的 select 方法執行負載均衡邏輯。在分析 select 方法之前，我們先來看一下一致性 hash 選擇器 ConsistentHashSelector 的初始化過程，如下：

private static final class ConsistentHashSelector<T> {
?
// 使用 TreeMap 存儲 Invoker 虛擬節點
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();
// 獲取虛擬節點數，默認為160
this.replicaNumber = url.getMethodParameter(methodName, "hash.nodes", 160);
// 獲取參與 hash 計算的參數下標值，默認對第一個參數進行 hash 運算
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) {
String address = invoker.getUrl().getAddress();
for (int i = 0; i < replicaNumber / 4; i++) {
// 對 address + i 進行 md5 運算，得到一個長度為16的位元組數組
byte[] digest = md5(address + i);
// 對 digest 部分位元組進行4次 hash 運算，得到四個不同的 long 型正整數
for (int h = 0; h < 4; h++) {
// h = 0 時，取 digest 中下標為 0 ~ 3 的4個位元組進行位運算
// h = 1 時，取 digest 中下標為 4 ~ 7 的4個位元組進行位運算
// h = 2, h = 3 時過程同上
long m = hash(digest, h);
// 將 hash 到 invoker 的映射關係存儲到 virtualInvokers 中，
// virtualInvokers 需要提供高效的查詢操作，因此選用 TreeMap 作為存儲結構
virtualInvokers.put(m, invoker);
}
}
}
}
}

ConsistentHashSelector 的構造方法執行了一系列的初始化邏輯，比如從配置中獲取虛擬節點數以及參與 hash 計算的參數下標，默認情況下只使用第一個參數進行 hash。需要特別說明的是，ConsistentHashLoadBalance 的負載均衡邏輯只受參數值影響，具有相同參數值的請求將會被分配給同一個服務提供者。ConsistentHashLoadBalance 不 關係權重，因此使用時需要注意一下。

在獲取虛擬節點數和參數下標配置後，接下來要做的事情是計算虛擬節點 hash 值，並將虛擬節點存儲到 TreeMap 中。到此，ConsistentHashSelector 初始化工作就完成了。接下來，我們來看看 select 方法的邏輯。

public Invoker<T> select(Invocation invocation) {
// 將參數轉為 key
String key = toKey(invocation.getArguments());
// 對參數 key 進行 md5 運算
byte[] digest = md5(key);
// 取 digest 數組的前四個位元組進行 hash 運算，再將 hash 值傳給 selectForKey 方法，
// 尋找合適的 Invoker
return selectForKey(hash(digest, 0));
}
?
private Invoker<T> selectForKey(long hash) {
// 到 TreeMap 中查找第一個節點值大於或等於當前 hash 的 Invoker
Map.Entry<Long, Invoker<T>> entry = virtualInvokers.tailMap(hash, true).firstEntry();
// 如果 hash 大於 Invoker 在圓環上最大的位置，此時 entry = null，
// 需要將 TreeMap 的頭節點賦值給 entry
if (entry == null) {
entry = virtualInvokers.firstEntry();
}
?
// 返回 Invoker
return entry.getValue();
}

如上，選擇的過程相對比較簡單了。首先是對參數進行 md5 以及 hash 運算，得到一個 hash 值。然後再拿這個值到 TreeMap 中查找目標 Invoker 即可。

到此關於 ConsistentHashLoadBalance 就分析完了。在閱讀 ConsistentHashLoadBalance 源碼之前，大家一定要先補充背景知識，不然很難看懂代碼邏輯。

4. RoundRobinLoadBalance

本節，我們來看一下 Dubbo 中加權輪詢負載均衡的實現 RoundRobinLoadBalance。在詳細分析源碼前，我們先來了解一下什麼是加權輪詢。這裡從最簡單的輪詢開始講起，所謂輪詢是指將請求輪流分配給每台伺服器。舉個例子，我們有三台伺服器 A、B、C。我們將第一個請求分配給伺服器 A，第二個請求分配給伺服器 B，第三個請求分配給伺服器 C，第四個請求再次分配給伺服器 A。這個過程就叫做輪詢。輪詢是一種無狀態負載均衡演算法，實現簡單，適用於每台伺服器性能相近的場景下。但現實情況下，我們並不能保證每台伺服器性能均相近。如果我們將等量的請求分配給性能較差的伺服器，這顯然是不合理的。因此，這個時候我們需要對輪詢過程進行加權，以調控每台伺服器的負載。經過加權後，每台伺服器能夠得到的請求數比例，接近或等於他們的權重比。比如伺服器 A、B、C 權重比為 5:2:1。那麼在8次請求中，伺服器 A 將收到其中的5次請求，伺服器 B 會收到其中的2次請求，伺服器 C 則收到其中的1次請求。

以上就是加權輪詢的演算法思想，搞懂了這個思想，接下來我們就可以分析源碼了。我們先來看一下 2.6.4 版本的 RoundRobinLoadBalance。

public class RoundRobinLoadBalance extends AbstractLoadBalance {
?
public static final String NAME = "roundrobin";
?
private final ConcurrentMap<String, AtomicPositiveInteger> sequences =
new ConcurrentHashMap<String, AtomicPositiveInteger>();
?
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
// key = 全限定類名 + "." + 方法名，比如 com.xxx.DemoService.sayHello
String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
int length = invokers.size();
// 最大權重
int maxWeight = 0;
// 最小權重
int minWeight = Integer.MAX_VALUE;
final LinkedHashMap<Invoker<T>, IntegerWrapper> invokerToWeightMap = new LinkedHashMap<Invoker<T>, IntegerWrapper>();
// 權重總和
int weightSum = 0;
?
// 下面這個循環主要用於查找最大和最小權重，計算權重總和等
for (int i = 0; i < length; i++) {
int weight = getWeight(invokers.get(i), invocation);
// 獲取最大和最小權重
maxWeight = Math.max(maxWeight, weight);
minWeight = Math.min(minWeight, weight);
if (weight > 0) {
// 將 weight 封裝到 IntegerWrapper 中
invokerToWeightMap.put(invokers.get(i), new IntegerWrapper(weight));
// 累加權重
weightSum += weight;
}
}
?
// 查找 key 對應的對應 AtomicPositiveInteger 實例，為空則創建。
// 這裡可以把 AtomicPositiveInteger 看成一個黑盒，大家只要知道
// AtomicPositiveInteger 用於記錄服務的調用編號即可。至於細節，
// 大家如果感興趣，可以自行分析
AtomicPositiveInteger sequence = sequences.get(key);
if (sequence == null) {
sequences.putIfAbsent(key, new AtomicPositiveInteger());
sequence = sequences.get(key);
}
?
// 獲取當前的調用編號
int currentSequence = sequence.getAndIncrement();
// 如果最小權重小於最大權重，表明服務提供者之間的權重是不相等的
if (maxWeight > 0 && minWeight < maxWeight) {
// 使用調用編號對權重總和進行取余操作
int mod = currentSequence % weightSum;
// 進行 maxWeight 次遍歷
for (int i = 0; i < maxWeight; i++) {
// 遍歷 invokerToWeightMap
for (Map.Entry<Invoker<T>, IntegerWrapper> each : invokerToWeightMap.entrySet()) {
// 獲取 Invoker
final Invoker<T> k = each.getKey();
// 獲取權重包裝類 IntegerWrapper
final IntegerWrapper v = each.getValue();

// 如果 mod = 0，且權重大於0，此時返回相應的 Invoker
if (mod == 0 && v.getValue() > 0) {
return k;
}

// mod != 0，且權重大於0，此時對權重和 mod 分別進行自減操作
if (v.getValue() > 0) {
v.decrement();
mod--;
}
}
}
}

// 服務提供者之間的權重相等，此時通過輪詢選擇 Invoker
return invokers.get(currentSequence % length);
}
?
// IntegerWrapper 是一個 int 包裝類，主要包含了一個自減方法。
private static final class IntegerWrapper {
private int value;
?
public void decrement() {
this.value--;
}

// 省略部分代碼
}
}

如上，RoundRobinLoadBalance 的每行代碼都不是很難理解，但是將它們組合在一起之後，就不是很好理解了。所以下面我們舉例進行說明，假設我們有三台伺服器 servers = [A, B, C]，對應的權重為 weights = [2, 5, 1]。接下來對上面的邏輯進行簡單的模擬。

mod = 0：滿足條件，此時直接返回伺服器 A

mod = 1：需要進行一次遞減操作才能滿足條件，此時返回伺服器 B

mod = 2：需要進行兩次遞減操作才能滿足條件，此時返回伺服器 C

mod = 3：需要進行三次遞減操作才能滿足條件，經過遞減後，伺服器權重為 [1, 4, 0]，此時返回伺服器 A

mod = 4：需要進行四次遞減操作才能滿足條件，經過遞減後，伺服器權重為 [0, 4, 0]，此時返回伺服器 B

mod = 5：需要進行五次遞減操作才能滿足條件，經過遞減後，伺服器權重為 [0, 3, 0]，此時返回伺服器 B

mod = 6：需要進行六次遞減操作才能滿足條件，經過遞減後，伺服器權重為 [0, 2, 0]，此時返回伺服器 B

mod = 7：需要進行七次遞減操作才能滿足條件，經過遞減後，伺服器權重為 [0, 1, 0]，此時返回伺服器 B

經過8次調用後，我們得到的負載均衡結果為 [A, B, C, A, B, B, B, B]，次數比 A:B:C = 2:5:1，等於權重比。當 sequence = 8 時，mod = 0，此時重頭再來。從上面的模擬過程可以看出，當 mod >= 3 後，伺服器 C 就不會被選中了，因為它的權重被減為0了。當 mod >= 4 後，伺服器 A 的權重被減為0，此後 A 就不會再被選中。

以上是 2.6.4 版本的 RoundRobinLoadBalance 分析過程，2.6.4 版本的 RoundRobinLoadBalance 在某些情況下存在著比較嚴重的性能問題，該問題最初是在 issue #2578 中被反饋出來。問題出在了 Invoker 的返回時機上，RoundRobinLoadBalance 需要在mod == 0 && v.getValue() > 0 條件成立的情況下才會被返回相應的 Invoker。假如 mod 很大，比如 10000，50000，甚至更大時，doSelect 方法需要進行很多次計算才能將 mod 減為0。由此可知，doSelect 的效率與 mod 有關，時間複雜度為 O(mod)。mod 又受最大權重 maxWeight 的影響，因此當某個服務提供者配置了非常大的權重，此時 RoundRobinLoadBalance 會產生比較嚴重的性能問題。這個問題被反饋後，社區很快做了回應。並對 RoundRobinLoadBalance 的代碼進行了重構，將時間複雜度優化至了常量級別。這個優化可以說很好了，下面我們來學習一下優化後的代碼。

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> indexSeqs = new ConcurrentHashMap<String, AtomicPositiveInteger>();
?
@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
int length = invokers.size();
int maxWeight = 0;
int minWeight = Integer.MAX_VALUE;
final List<Invoker<T>> invokerToWeightList = new ArrayList<>();

// 查找最大和最小權重
for (int i = 0; i < length; i++) {
int weight = getWeight(invokers.get(i), invocation);
maxWeight = Math.max(maxWeight, weight);
minWeight = Math.min(minWeight, weight);
if (weight > 0) {
invokerToWeightList.add(invokers.get(i));
}
}

// 獲取當前服務對應的調用序列對象 AtomicPositiveInteger
AtomicPositiveInteger sequence = sequences.get(key);
if (sequence == null) {
// 創建 AtomicPositiveInteger，默認值為0
sequences.putIfAbsent(key, new AtomicPositiveInteger());
sequence = sequences.get(key);
}

// 獲取下標序列對象 AtomicPositiveInteger
AtomicPositiveInteger indexSeq = indexSeqs.get(key);
if (indexSeq == null) {
// 創建 AtomicPositiveInteger，默認值為 -1
indexSeqs.putIfAbsent(key, new AtomicPositiveInteger(-1));
indexSeq = indexSeqs.get(key);
}
?
if (maxWeight > 0 && minWeight < maxWeight) {
length = invokerToWeightList.size();
while (true) {
int index = indexSeq.incrementAndGet() % length;
int currentWeight = sequence.get() % maxWeight;
?
// 每循環一輪（index = 0），重新計算 currentWeight
if (index == 0) {
currentWeight = sequence.incrementAndGet() % maxWeight;
}

// 檢測 Invoker 的權重是否大於 currentWeight，大於則返回
if (getWeight(invokerToWeightList.get(index), invocation) > currentWeight) {
return invokerToWeightList.get(index);
}
}
}

// 所有 Invoker 權重相等，此時進行普通的輪詢即可
return invokers.get(sequence.incrementAndGet() % length);
}
}

上面代碼的邏輯是這樣的，每進行一輪循環，重新計算 currentWeight。如果當前 Invoker 權重大於 currentWeight，則返回該 Invoker。下面舉例說明，假設伺服器 [A, B, C] 對應權重 [5, 2, 1]。

第一輪循環，currentWeight = 1，可返回 A 和 B

第二輪循環，currentWeight = 2，返回 A

第三輪循環，currentWeight = 3，返回 A

第四輪循環，currentWeight = 4，返回 A

第五輪循環，currentWeight = 0，返回 A, B, C

如上，這裡的一輪循環是指 index 再次變為0所經歷過的循環，這裡可以把 index = 0 看做是一輪循環的開始。每一輪循環的次數與 Invoker 的數量有關，Invoker 數量通常不會太多，所以我們可以認為上面代碼的時間複雜度為常數級。

重構後的 RoundRobinLoadBalance 看起來已經很不錯了，但是在代碼更新不久後，很快又被重構了。這次重構原因是新的 RoundRobinLoadBalance 在某些情況下選出的伺服器序列不夠均勻。比如，伺服器 [A, B, C] 對應權重 [5, 1, 1]。進行7次負載均衡後，選擇出來的序列為 [A, A, A, A, A, B, C]。前5個請求全部都落在了伺服器 A上，這將會使伺服器 A 短時間內接收大量的請求，壓力陡增。而 B 和 C 此時無請求，處於空閑狀態。而我們期望的結果是這樣的 [A, A, B, A, C, A, A]，不同伺服器可以穿插獲取請求。為了增加負載均衡結果的平滑性，社區再次對 RoundRobinLoadBalance 的實現進行了重構，這次重構參考自 Nginx 的平滑加權輪詢負載均衡。每個伺服器對應兩個權重，分別為 weight 和 currentWeight。其中 weight 是固定的，currentWeight 會動態調整，初始值為0。當有新的請求進來時，遍歷伺服器列表，讓它的 currentWeight 加上自身權重。遍歷完成後，找到最大的 currentWeight，並將其減去權重總和，然後返回相應的伺服器即可。

上面描述不是很好理解，下面還是舉例進行說明。這裡仍然使用伺服器 [A, B, C] 對應權重 [5, 1, 1] 的例子說明，現在有7個請求依次進入負載均衡邏輯，選擇過程如下：

請求編號currentWeight 數組選擇結果減去權重總和後的 currentWeight 數組1[5, 1, 1]A[-2, 1, 1]2[3, 2, 2]A[-4, 2, 2]3[1, 3, 3]B[1, -4, 3]4[6, -3, 4]A[-1, -3, 4]5[4, -2, 5]C[4, -2, -2]6[9, -1, -1]A[2, -1, -1]7[7, 0, 0]A[0, 0, 0]

如上，經過平滑性處理後，得到的伺服器序列為 [A, A, B, A, C, A, A]，相比之前的序列 [A, A, A, A, A, B, C]，分布性要好一些。初始情況下 currentWeight = [0, 0, 0]，第7個請求處理完後，currentWeight 再次變為 [0, 0, 0]。

以上就是平滑加權輪詢的計算過程，接下來，我們來看看 Dubbo-2.6.5 是如何實現上面的計算過程的。

public class RoundRobinLoadBalance extends AbstractLoadBalance {
public static final String NAME = "roundrobin";

private static int RECYCLE_PERIOD = 60000;

protected static class WeightedRoundRobin {
// 服務提供者權重
private int weight;
// 當前權重
private AtomicLong current = new AtomicLong(0);
// 最後一次更新時間
private long lastUpdate;

public void setWeight(int weight) {
this.weight = weight;
// 初始情況下，current = 0
current.set(0);
}
public long increaseCurrent() {
// current = current + weight；
return current.addAndGet(weight);
}
public void sel(int total) {
// current = current - total;
current.addAndGet(-1 * total);
}
}
?
// 嵌套 Map 結構，存儲的數據結構示例如下：
// {
// "UserService.query": {
// "url1": WeightedRoundRobin@123,
// "url2": WeightedRoundRobin@456,
// },
// "UserService.update": {
// "url1": WeightedRoundRobin@123,
// "url2": WeightedRoundRobin@456,
// }
// }
// 最外層為服務類名 + 方法名，第二層為 url 到 WeightedRoundRobin 的映射關係。
// 這裡我們可以將 url 看成是服務提供者的 id
private ConcurrentMap<String, ConcurrentMap<String, WeightedRoundRobin>> methodWeightMap = new ConcurrentHashMap<String, ConcurrentMap<String, WeightedRoundRobin>>();

// 原子更新鎖
private AtomicBoolean updateLock = new AtomicBoolean();

@Override
protected <T> Invoker<T> doSelect(List<Invoker<T>> invokers, URL url, Invocation invocation) {
String key = invokers.get(0).getUrl().getServiceKey() + "." + invocation.getMethodName();
// 獲取 url 到 WeightedRoundRobin 映射表，如果為空，則創建一個新的
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;
?
// 下面這個循環主要做了這樣幾件事情：
// 1. 遍歷 Invoker 列表，檢測當前 Invoker 是否有
// 相應的 WeightedRoundRobin，沒有則創建
// 2. 檢測 Invoker 權重是否發生了變化，若變化了，
// 則更新 WeightedRoundRobin 的 weight 欄位
// 3. 讓 current 欄位加上自身權重，等價於 current += weight
// 4. 設置 lastUpdate 欄位，即 lastUpdate = now
// 5. 尋找具有最大 current 的 Invoker，以及 Invoker 對應的 WeightedRoundRobin，
// 暫存起來，留作後用
// 6. 計算權重總和
for (Invoker<T> invoker : invokers) {
String identifyString = invoker.getUrl().toIdentityString();
WeightedRoundRobin weightedRoundRobin = map.get(identifyString);
int weight = getWeight(invoker, invocation);
if (weight < 0) {
weight = 0;
}

// 檢測當前 Invoker 是否有對應的 WeightedRoundRobin，沒有則創建
if (weightedRoundRobin == null) {
weightedRoundRobin = new WeightedRoundRobin();
// 設置 Invoker 權重
weightedRoundRobin.setWeight(weight);
// 存儲 url 唯一標識 identifyString 到 weightedRoundRobin 的映射關係
map.putIfAbsent(identifyString, weightedRoundRobin);
weightedRoundRobin = map.get(identifyString);
}
// Invoker 權重不等於 WeightedRoundRobin 中保存的權重，說明權重變化了，此時進行更新
if (weight != weightedRoundRobin.getWeight()) {
weightedRoundRobin.setWeight(weight);
}

// 讓 current 加上自身權重，等價於 current += weight
long cur = weightedRoundRobin.increaseCurrent();
// 設置 lastUpdate，表示近期更新過
weightedRoundRobin.setLastUpdate(now);
// 找出最大的 current
if (cur > maxCurrent) {
maxCurrent = cur;
// 將具有最大 current 權重的 Invoker 賦值給 selectedInvoker
selectedInvoker = invoker;
// 將 Invoker 對應的 weightedRoundRobin 賦值給 selectedWRR，留作後用
selectedWRR = weightedRoundRobin;
}

// 計算權重總和
totalWeight += weight;
}
?
// 對 <identifyString, WeightedRoundRobin> 進行檢查，過濾掉長時間未被更新的節點。
// 該節點可能掛了，invokers 中不包含該節點，所以該節點的 lastUpdate 長時間無法被更新。
// 若未更新時長超過閾值後，就會被移除掉，默認閾值為60秒。
if (!updateLock.get() && invokers.size() != map.size()) {
if (updateLock.compareAndSet(false, true)) {
try {
ConcurrentMap<String, WeightedRoundRobin> newMap = new ConcurrentHashMap<String, WeightedRoundRobin>();
// 拷貝
newMap.putAll(map);

// 遍歷修改，即移除過期記錄
Iterator<Entry<String, WeightedRoundRobin>> it = newMap.entrySet().iterator();
while (it.hasNext()) {
Entry<String, WeightedRoundRobin> item = it.next();
if (now - item.getValue().getLastUpdate() > RECYCLE_PERIOD) {
it.remove();
}
}

// 更新引用
methodWeightMap.put(key, newMap);
} finally {
updateLock.set(false);
}
}
}
?
if (selectedInvoker != null) {
// 讓 current 減去權重總和，等價於 current -= totalWeight
selectedWRR.sel(totalWeight);
// 返回具有最大 current 的 Invoker
return selectedInvoker;
}

// should not happen here
return invokers.get(0);
}
}

大家如果能夠理解平滑加權輪詢演算法的計算過程，再配合代碼中注釋，理解上面的代碼應該不難。

5. 總結

本篇文章對 Dubbo 中的幾種負載均衡實現進行了詳細的分析，內容比較多，大家慢慢消化。理解負載均衡代碼邏輯的關鍵之處在於對背景知識的理解，因此大家在閱讀源碼前，務必先了解每種負載均衡對應的背景知識。

歡迎大家添加Java高級架構交流群 378461078

關注微信公眾號「托尼的技術成長之路」

推薦閱讀：