下文給大家分析描述每一種負(fù)載均衡的完整樣貌，希望能夠給大家在實(shí)際運(yùn)用中帶來一定的幫助，負(fù)載均衡涉及的東西比較多，理論也不多，網(wǎng)上有很多書籍，今天我們就用創(chuàng)新互聯(lián)建站在行業(yè)內(nèi)累計(jì)的經(jīng)驗(yàn)來做一個(gè)解答。

創(chuàng)新互聯(lián)2013年至今，先為城子河等服務(wù)建站，城子河等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為城子河企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

一、「負(fù)載均衡」是什么

      正如題圖所示的這樣，由一個(gè)獨(dú)立的統(tǒng)一入口來收斂流量，再做二次分發(fā)的過程就是「負(fù)載均衡」，它的本質(zhì)和「分布式系統(tǒng)」一樣，是「分治」。

       如果大家習(xí)慣了開車的時(shí)候用一些導(dǎo)航軟件，我們會發(fā)現(xiàn)，導(dǎo)航軟件的推薦路線方案會有一個(gè)數(shù)量的上限，比如3條、5條。因此，其實(shí)本質(zhì)上它也起到了一個(gè)類似「負(fù)載均衡」的作用，因?yàn)槿绻荒苋op3的通暢路線，自然擁堵嚴(yán)重的路線就無法推薦給你了，使得車流的壓力被分?jǐn)偟搅讼鄬臻e的路線上。

       在軟件系統(tǒng)中也是一樣的道理，為了避免流量分?jǐn)偛痪斐删植抗?jié)點(diǎn)負(fù)載過大（如CPU吃緊等），所以引入一個(gè)獨(dú)立的統(tǒng)一入口來做類似上面的“導(dǎo)航”的工作。但是，軟件系統(tǒng)中的「負(fù)載均衡」與導(dǎo)航的不同在于，導(dǎo)航是一個(gè)柔性策略，最終還是需要使用者做選擇，而前者則不同。

      怎么均衡的背后是策略在起作用，而策略的背后是由某些算法或者說邏輯來組成的。比如，導(dǎo)航中的算法屬于「路徑規(guī)劃」范疇，在這個(gè)范疇內(nèi)又細(xì)分為「靜態(tài)路徑規(guī)劃」和「動態(tài)路徑規(guī)劃」，并且，在不同的分支下還有各種具體計(jì)算的算法實(shí)現(xiàn)，如Dijikstra、A*等。同樣的，在軟件系統(tǒng)中的負(fù)載均衡，也有很多算法或者說邏輯在支撐著這些策略，巧的是也有靜態(tài)和動態(tài)之分。

二、常用「負(fù)載均衡」策略圖解

      下面來羅列一下日常工作中最常見的5種策略。

01  輪詢

這是最常用也最簡單策略，平均分配，人人都有、一人一次。大致的代碼如下。

int  globalIndex = 0;   //注意是全局變量，不是局部變量。
try
{
    return servers[globalIndex];
}
finally
{
    globalIndex++;
    if (globalIndex == 3)
        globalIndex = 0;
}

02  加權(quán)輪詢

      在輪詢的基礎(chǔ)上，增加了一個(gè)權(quán)重的概念。權(quán)重是一個(gè)泛化后的概念，可以用任意方式來體現(xiàn)，本質(zhì)上是一個(gè)能者多勞思想。比如，可以根據(jù)宿主的性能差異配置不同的權(quán)重。大致的代碼如下。

 matchedIndex = -; total = ;
 ( i = ; i < servers.Length; i++)
{
      servers[i].cur_weight += servers[i].weight;
      total += servers[i].weight;
       (matchedIndex == - || servers[matchedIndex].cur_weight < servers[i].cur_weight) 
      {
            matchedIndex = i;
      }
}

servers[matchedIndex].cur_weight -= total; servers[matchedIndex];

      這段代碼的過程如下圖的表格。"()"中的數(shù)字就是自增數(shù)，代碼中的cur_weight。

      值得注意的是，加權(quán)輪詢本身還有不同的實(shí)現(xiàn)方式，雖說最終的比例都是2：1：2。但是在請求送達(dá)的先后順序上可以所有不同。比如「5-4，3，2-1」和上面的案例相比，最終比例是一樣的，但是效果不同。「5-4，3，2-1」更容易產(chǎn)生并發(fā)問題，導(dǎo)致服務(wù)端擁塞，且這個(gè)問題隨著權(quán)重?cái)?shù)字越大越嚴(yán)重。例子：10：5：3的結(jié)果是「18-17-16-15-14-13-12-11-10-9，8-7-6-5-4，3-2-1」

03  最少連接數(shù)

      這是一種根據(jù)實(shí)時(shí)的負(fù)載情況，進(jìn)行動態(tài)負(fù)載均衡的方式。維護(hù)好活動中的連接數(shù)量，然后取最小的返回即可。大致的代碼如下。

var matchedServer = servers.orderBy(e => e.active_conns).first();
matchedServer.active_conns += 1;
return matchedServer;
//在連接關(guān)閉時(shí)還需對active_conns做減1的動作。

04  最快響應(yīng)

      這也是一種動態(tài)負(fù)載均衡策略，它的本質(zhì)是根據(jù)每個(gè)節(jié)點(diǎn)對過去一段時(shí)間內(nèi)的響應(yīng)情況來分配，響應(yīng)越快分配的越多。具體的運(yùn)作方式也有很多，上圖的這種可以理解為，將最近一段時(shí)間的請求耗時(shí)的平均值記錄下來，結(jié)合前面的「加權(quán)輪詢」來處理，所以等價(jià)于2：1：3的加權(quán)輪詢。

       題外話：一般來說，同機(jī)房下的延遲基本沒什么差異，響應(yīng)時(shí)間的差異主要在服務(wù)的處理能力上。如果在跨地域（例：浙江->上海，還是浙江->北京）的一些請求處理中運(yùn)用，大多數(shù)情況會使用定時(shí)「ping」的方式來獲取延遲情況，因?yàn)槭荗SI的L3轉(zhuǎn)發(fā)，數(shù)據(jù)更干凈，準(zhǔn)確性更高。

05  Hash法

      hash法的負(fù)載均衡與之前的幾種不同在于，它的結(jié)果是由客戶端決定的。通過客戶端帶來的某個(gè)標(biāo)識經(jīng)過一個(gè)標(biāo)準(zhǔn)化的散列函數(shù)進(jìn)行打散分?jǐn)?/strong>。

       上圖中的散列函數(shù)運(yùn)用的是最簡單粗暴的「取余法」。

       題外話：散列函數(shù)除了取余之外，還有諸如「變基」、「折疊」、「平方取中法」等等，此處不做展開，有興趣的小伙伴可自行查閱資料。

       另外，被求余的參數(shù)其實(shí)可以是任意的，只要最終轉(zhuǎn)化成一個(gè)整數(shù)參與運(yùn)算即可。最常用的應(yīng)該是用來源ip地址作為參數(shù)，這樣可以確保相同的客戶端請求盡可能落在同一臺云服務(wù)器上。

三、常用「負(fù)載均衡」策略優(yōu)缺點(diǎn)和適用場景

      我們知道，沒有完美的事物，負(fù)載均衡策略也是一樣。上面列舉的這些最常用的策略也有各自的優(yōu)缺點(diǎn)和適用場景，我稍作了整理，如下。

      這些負(fù)載均衡算法之所以常用也是因?yàn)楹唵危胍鼉?yōu)的效果，必然就需要更高的復(fù)雜度。比如，可以將簡單的策略組合使用、或者通過更多維度的數(shù)據(jù)采樣來綜合評估、甚至是基于進(jìn)行數(shù)據(jù)挖掘后的預(yù)測算法來做。

四、用「健康探測」來保障高可用

      不管是什么樣的策略，難免會遇到機(jī)器故障或者程序故障的情況。所以要確保負(fù)載均衡能更好的起到效果，還需要結(jié)合一些「健康探測」機(jī)制。定時(shí)的去探測服務(wù)端是不是還能連上，響應(yīng)是不是超出預(yù)期的慢。如果節(jié)點(diǎn)屬于“不可用”的狀態(tài)的話，需要將這個(gè)節(jié)點(diǎn)臨時(shí)從待選取列表中移除，以提高可用性。一般常用的「健康探測」方式有3種。

01  HTTP探測

       使用Get/Post的方式請求服務(wù)端的某個(gè)固定的URL，判斷返回的內(nèi)容是否符合預(yù)期。一般使用Http狀態(tài)碼、response中的內(nèi)容來判斷。

02  TCP探測

       基于Tcp的三次握手機(jī)制來探測指定的IP + 端口。最佳實(shí)踐可以借鑒阿里云的SLB機(jī)制，如下圖。

▲

      值得注意的是，為了盡早釋放連接，在三次握手結(jié)束后立馬跟上RST來中斷TCP連接。

03  UDP探測

      可能有部分應(yīng)用使用的UDP協(xié)議。在此協(xié)議下可以通過報(bào)文來進(jìn)行探測指定的IP + 端口。最佳實(shí)踐同樣可以借鑒阿里云的SLB機(jī)制，如下圖。

      結(jié)果的判定方式是：在服務(wù)端沒有返回任何信息的情況下，默認(rèn)正常狀態(tài)。否則會返回一個(gè)ICMP的報(bào)錯(cuò)信息。

看了以上關(guān)于分析描述每一種負(fù)載均衡的完整樣貌，如果大家還有什么地方需要了解的可以在創(chuàng)新互聯(lián)建站行業(yè)資訊里查找自己感興趣的或者找我們的專業(yè)技術(shù)工程師解答的，創(chuàng)新互聯(lián)建站技術(shù)工程師在行業(yè)內(nèi)擁有十幾年的經(jīng)驗(yàn)了。

當(dāng)前題目：分析描述每一種負(fù)載均衡的完整樣貌-創(chuàng)新互聯(lián)
網(wǎng)址分享：http://chinadenli.net/article36/hgppg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、網(wǎng)站設(shè)計(jì)、軟件開發(fā)、商城網(wǎng)站、網(wǎng)站營銷、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)