我們都對高可用有一個基本的認識，其中負載均衡是高可用的核心工作。本文將通過如下幾個方面，讓你妥妥的吃透“負載均衡”。
1、負載均衡是什麼
2、常用負載均衡策略圖解
3、常用負載均衡策略優缺點和適用場景
4、用健康探測來保障高可用
5、結語
歡迎工作一到五年的Java工程師朋友們加入Java程序員開發： 854393687
群內提供免費的Java架構學習資料（裡面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
負載均衡是什麼
正如上圖所示的這樣，由一個獨立的統一入口來收斂流量，再做二次分發的過程就是負載均衡，它的本質和分佈式系統一樣，是分治。
如果大家習慣了開車的時候用一些導航軟件，我們會發現，導航軟件的推薦路線方案會有一個數量的上限，比如 3 條、5 條。
因此，其實本質上它也起到了一個類似負載均衡的作用，因為如果只能取 Top3 的通暢路線，自然擁堵嚴重的路線就無法推薦給你了，使得車流的壓力被分攤到了相對空閒的路線上。
在軟件系統中也是一樣的道理，為了避免流量分攤不均，造成局部節點負載過大(如 CPU 吃緊等)，所以引入一個獨立的統一入口來做類似上面的“導航”的工作。
但是，軟件系統中的負載均衡與導航的不同在於：導航是一個柔性策略，最終還是需要使用者做選擇，而前者則不同。
怎麼均衡的背後是策略在起作用，而策略的背後是由某些算法或者說邏輯來組成的。
比如，導航中的算法屬於路徑規劃範疇，在這個範疇內又細分為靜態路徑規劃和動態路徑規劃，並且，在不同的分支下還有各種具體計算的算法實現，如 Dijikstra、A* 等。
同樣的，在軟件系統中的負載均衡，也有很多算法或者說邏輯在支撐著這些策略，巧的是也有靜態和動態之分。
常用負載均衡策略圖解
下面來羅列一下日常工作中最常見的 5 種策略。
輪詢
這是最常用也最簡單策略，平均分配，人人都有、一人一次。大致的代碼如下：
int globalIndex = 0; //注意是全局變量，不是局部變量。
try
{
return servers[globalIndex];
}
finally
{
globalIndex++;
if (globalIndex == 3)
globalIndex = 0;
}
加權輪詢
在輪詢的基礎上，增加了一個權重的概念。權重是一個泛化後的概念，可以用任意方式來體現，本質上是一個能者多勞思想。
比如，可以根據宿主的性能差異配置不同的權重。大致的代碼如下：
int matchedIndex = -1;
int total = 0;
for (int i = 0; i < servers.Length; i++)
{
servers[i].cur_weight += servers[i].weight;//①每次循環的時候做自增（步長=權重值）
total += servers[i].weight;//②將每個節點的權重值累加到彙總值中
if (matchedIndex == -1 || servers[matchedIndex].cur_weight < servers[i].cur_weight) //③如果 當前節點的自增數 > 當前待返回節點的自增數，則覆蓋。
{
matchedIndex = i;
}
}
servers[matchedIndex].cur_weight -= total;//④被選取的節點減去②的彙總值，以降低下一次被選舉時的初始權重值。
return servers[matchedIndex];
這段代碼的過程如下圖的表格。"()"中的數字就是自增數，即代碼中的 cur_weight。
[i][i][i]
[/i][/i][/i]
值得注意的是，加權輪詢本身還有不同的實現方式，雖說最終的比例都是 2：1：2。
但是在請求送達的先後順序上可以有所不同。比如「5-4，3，2-1」和上面的案例相比，最終比例是一樣的，但是效果不同。
「5-4，3，2-1」更容易產生併發問題，導致服務端擁塞，且這個問題隨著權重數字越大越嚴重。
例子：10：5：3 的結果是「18-17-16-15-14-13-12-11-10-9，8-7-6-5-4，3-2-1」
最少連接數
這是一種根據實時的負載情況，進行動態負載均衡的方式。維護好活動中的連接數量，然後取最小的返回即可。大致的代碼如下：[i][i][i] [/i][/i][/i]
var matchedServer = servers.orderBy(e => e.active_conns).first();
matchedServer.active_conns += 1;
return matchedServer;
//在連接關閉時還需對active_conns做減1的動作。
最快響應
[i][i][i]
這也是一種動態負載均衡策略，它的本質是根據每個節點對過去一段時間內的響應情況來分配，響應越快分配的越多。[/i][/i][/i]
[i][i][i]具體的運作方式也有很多，上圖的這種可以理解為，將最近一段時間的請求耗時的平均值記錄下來，結合前面的加權輪詢來處理，所以等價於 2：1：3 的加權輪詢。[/i][/i][/i]
[i][i][i]題外話：一般來說，同機房下的延遲基本沒什麼差異，響應時間的差異主要在服務的處理能力上。[/i][/i][/i]
[i][i][i]如果在跨地域(例：浙江->上海，還是浙江->北京)的一些請求處理中運用，大多數情況會使用定時「Ping」的方式來獲取延遲情況，因為是 OSI 的 L3 轉發，數據更乾淨，準確性更高。[/i][/i][/i]
Hash 法
[i][i][i]
[/i][/i][/i]
Hash 法的負載均衡與之前的幾種不同在於，它的結果是由客戶端決定的。通過客戶端帶來的某個標識經過一個標準化的散列函數進行打散分攤。上圖中的散列函數運用的是最簡單粗暴的取餘法。
題外話：散列函數除了取餘之外，還有諸如變基、摺疊、平方取中法等等，此處不做展開，有興趣的小夥伴可自行查閱資料。
另外，被求餘的參數其實可以是任意的，只要最終轉化成一個整數參與運算即可。
最常用的應該是用來源 IP 地址作為參數，這樣可以確保相同的客戶端請求儘可能落在同一臺服務器上。
常用負載均衡策略優缺點和適用場景
我們知道，沒有完美的事物，負載均衡策略也是一樣。上面列舉的這些最常用的策略也有各自的優缺點和適用場景，我稍作了整理，如下。
這些負載均衡算法之所以常用也是因為簡單，想要更優的效果，必然就需要更高的複雜度。
比如，可以將簡單的策略組合使用、或者通過更多維度的數據採樣來綜合評估、甚至是基於進行數據挖掘後的預測算法來做。
用健康探測來保障高可用
不管是什麼樣的策略，難免會遇到機器故障或者程序故障的情況。所以要確保負載均衡能更好的起到效果，還需要結合一些健康探測機制。定時的去探測服務端是不是還能連上，響應是不是超出預期的慢。
如果節點屬於“不可用”的狀態的話，需要將這個節點臨時從待選取列表中移除，以提高可用性。一般常用的健康探測方式有 3 種。
HTTP 探測
使用 Get/Post 的方式請求服務端的某個固定的 URL，判斷返回的內容是否符合預期。一般使用 HTTP 狀態碼、Response 中的內容來判斷。
TCP 探測
基於 TCP 的三次握手機制來探測指定的 IP + 端口。最佳實踐可以借鑑阿里雲的 SLB 機制，如下圖：
值得注意的是，為了儘早釋放連接，在三次握手結束後立馬跟上 RST 來中斷 TCP 連接。
UDP 探測
可能有部分應用使用的是 UDP 協議。在此協議下可以通過報文來進行探測指定的 IP + 端口。最佳實踐同樣可以借鑑阿里雲的 SLB 機制，如下圖：
結果的判定方式是：在服務端沒有返回任何信息的情況下，默認是正常狀態。否則會返回一個 ICMP 的報錯信息。
結語
用一句話來概括負載均衡的本質是：將請求或者說流量，以期望的規則分攤到多個操作單元上進行執行。
通過它可以實現橫向擴展(scale out)，將冗餘的作用發揮為高可用。另外，還可以物盡其用，提升資源使用率。、
閱讀更多 JAVA柯尼塞克丶 的文章
