本篇內(nèi)容介紹了“web分布式系統(tǒng)的負(fù)載均衡怎么實(shí)現(xiàn)”的有關(guān)知識(shí),在實(shí)際案例的操作過程中,不少人都會(huì)遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!
站在用戶的角度思考問題,與客戶深入溝通,找到商城網(wǎng)站設(shè)計(jì)與商城網(wǎng)站推廣的解決方案,憑借多年的經(jīng)驗(yàn),讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合,創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品,建站類型包括:成都網(wǎng)站制作、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)站空間、企業(yè)郵箱。業(yè)務(wù)覆蓋商城地區(qū)。
正如題圖所示的這樣,由一個(gè)獨(dú)立的統(tǒng)一入口來收斂流量,再做二次分發(fā)的過程就是「負(fù)載均衡」,它的本質(zhì)和「分布式系統(tǒng)」一樣,是「分治」。
如果大家習(xí)慣了開車的時(shí)候用一些導(dǎo)航軟件,我們會(huì)發(fā)現(xiàn),導(dǎo)航軟件的推薦路線方案會(huì)有一個(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ī)劃」和「動(dòng)態(tài)路徑規(guī)劃」,并且,在不同的分支下還有各種具體計(jì)算的算法實(shí)現(xiàn),如Dijikstra、A*等。同樣的,在軟件系統(tǒng)中的負(fù)載均衡,也有很多算法或者說邏輯在支撐著這些策略,巧的是也有靜態(tài)和動(dòng)態(tài)之分。
下面來羅列一下日常工作中最常見的5種策略。
這是最常用也最簡單策略,平均分配,人人都有、一人一次。大致的代碼如下。
int globalIndex = 0; //注意是全局變量,不是局部變量。 try { return servers[globalIndex]; } finally { globalIndex++; if (globalIndex == 3) globalIndex = 0; }
在輪詢的基礎(chǔ)上,增加了一個(gè)權(quán)重的概念。權(quán)重是一個(gè)泛化后的概念,可以用任意方式來體現(xiàn),本質(zhì)上是一個(gè)能者多勞思想。比如,可以根據(jù)宿主的性能差異配置不同的權(quán)重。大致的代碼如下。
int matchedIndex = -1; int total = 0; for (int i = 0; i < servers.Length; i++) { servers[i].cur_weight += servers[i].weight;//①每次循環(huán)的時(shí)候做自增(步長=權(quán)重值) total += servers[i].weight;//②將每個(gè)節(jié)點(diǎn)的權(quán)重值累加到匯總值中 if (matchedIndex == -1 || servers[matchedIndex].cur_weight < servers[i].cur_weight) //③如果 當(dāng)前節(jié)點(diǎn)的自增數(shù) > 當(dāng)前待返回節(jié)點(diǎn)的自增數(shù),則覆蓋。 { matchedIndex = i; } } servers[matchedIndex].cur_weight -= total;//④被選取的節(jié)點(diǎn)減去②的匯總值,以降低下一次被選舉時(shí)的初始權(quán)重值。 return 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」
這是一種根據(jù)實(shí)時(shí)的負(fù)載情況,進(jìn)行動(dòng)態(tài)負(fù)載均衡的方式。維護(hù)好活動(dòng)中的連接數(shù)量,然后取最小的返回即可。大致的代碼如下。
var matchedServer = servers.orderBy(e => e.active_conns).first(); matchedServer.active_conns += 1; return matchedServer; //在連接關(guān)閉時(shí)還需對active_conns做減1的動(dòng)作。
這也是一種動(dò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ù)情況會(huì)使用定時(shí)「ping」的方式來獲取延遲情況,因?yàn)槭荗SI的L3轉(zhuǎn)發(fā),數(shù)據(jù)更干凈,準(zhǔn)確性更高。
hash法的負(fù)載均衡與之前的幾種不同在于,它的結(jié)果是由客戶端決定的。通過客戶端帶來的某個(gè)標(biāo)識(shí)經(jīng)過一個(gè)標(biāo)準(zhǔn)化的散列函數(shù)進(jìn)行打散分?jǐn)偂?/p>
上圖中的散列函數(shù)運(yùn)用的是最簡單粗暴的「取余法」。
題外話:散列函數(shù)除了取余之外,還有諸如「變基」、「折疊」、「平方取中法」等等,此處不做展開,有興趣的小伙伴可自行查閱資料。
另外,被求余的參數(shù)其實(shí)可以是任意的,只要最終轉(zhuǎn)化成一個(gè)整數(shù)參與運(yùn)算即可。最常用的應(yīng)該是用來源ip地址作為參數(shù),這樣可以確保相同的客戶端請求盡可能落在同一臺(tái)服務(wù)器上。
我們知道,沒有完美的事物,負(fù)載均衡策略也是一樣。上面列舉的這些最常用的策略也有各自的優(yōu)缺點(diǎn)和適用場景,我稍作了整理,如下。
這些負(fù)載均衡算法之所以常用也是因?yàn)楹唵?,想要更?yōu)的效果,必然就需要更高的復(fù)雜度。比如,可以將簡單的策略組合使用、或者通過更多維度的數(shù)據(jù)采樣來綜合評估、甚至是基于進(jìn)行數(shù)據(jù)挖掘后的預(yù)測算法來做。
不管是什么樣的策略,難免會(huì)遇到機(jī)器故障或者程序故障的情況。所以要確保負(fù)載均衡能更好的起到效果,還需要結(jié)合一些「健康探測」機(jī)制。定時(shí)的去探測服務(wù)端是不是還能連上,響應(yīng)是不是超出預(yù)期的慢。如果節(jié)點(diǎn)屬于“不可用”的狀態(tài)的話,需要將這個(gè)節(jié)點(diǎn)臨時(shí)從待選取列表中移除,以提高可用性。一般常用的「健康探測」方式有3種。
使用Get/Post的方式請求服務(wù)端的某個(gè)固定的URL,判斷返回的內(nèi)容是否符合預(yù)期。一般使用Http狀態(tài)碼、response中的內(nèi)容來判斷。
基于Tcp的三次握手機(jī)制來探測指定的IP + 端口。最佳實(shí)踐可以借鑒阿里云的SLB機(jī)制,如下圖。
值得注意的是,為了盡早釋放連接,在三次握手結(jié)束后立馬跟上RST來中斷TCP連接。
可能有部分應(yīng)用使用的UDP協(xié)議。在此協(xié)議下可以通過報(bào)文來進(jìn)行探測指定的IP + 端口。最佳實(shí)踐同樣可以借鑒阿里云的SLB機(jī)制,如下圖。
結(jié)果的判定方式是:在服務(wù)端沒有返回任何信息的情況下,默認(rèn)正常狀態(tài)。否則會(huì)返回一個(gè)ICMP的報(bào)錯(cuò)信息。
“web分布式系統(tǒng)的負(fù)載均衡怎么實(shí)現(xiàn)”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!