軟負載、硬負載，這些負載均衡知識你都會了嗎？

什麼是負載均衡？

負載均衡，英文名稱爲Load Balance，其含義就是指將負載（工作任務）進行平衡、分攤到多個操作單元上進行運行，例如FTP服務器、Web服務器、企業核心應用服務器和其它主要任務服務器等，從而協同完成工作任務。

負載均衡通常有兩種目的：均攤壓力和提供冗餘（也可以理解爲備份）。

生活案列

上面還看不懂的話，我們繼續用生活案列來說：

高速路出口處，如果只有一個出口時，突然有一天出現大量車輛（假設大家都沒有辦理ETC）這個高速出口下高速， 比如有幾百兩這會都要下高速，但是下高速要交過路費，每輛車至少也要耽擱幾分鐘，幾百輛！！！意味着後面的可能要等幾個小時，如果有多個出口呢？那就沒必要等那麼久了。

如果在增加一個出口，這時候就是兩個出口可以均攤車輛下高速，還得分收費員快慢，車輛3看到車1那邊要快點，然後就跟上車1。

如果再增加n個就可以想象效果了。但是太多了，貌似也會造成資源浪費，很多出口一天都沒有幾輛車出入，如果搞得太多豈不浪費，所以我們一般看到大多數都是兩個，可以理解備用急用。

「我們就把司機理解爲負載均衡器，可以根據前方路況進行判別走哪個出口。判別的方法就可以理解爲負載均衡算法。」

用我們技術領域的術語叫做冗餘。收費員的速度我就可以理解爲我們系統某個服務的性能。

技術領域

下面用一張圖來描述我們技術領域的負載均衡：

結合生活中的場景和技術領域的場景一起理解更酸爽。

注意：集羣指的是我們同一個App應用服務的部署多個節點，集羣的主要目的就是爲了分擔壓力的。負載均衡器（系統）就可以理解爲指揮員。來一個請求，指揮員把這個請求根據一定方法交給集羣中的某個服務。指揮員就可以按照各種方式進行分配請求到集羣中的某個服務。隨機給、排隊給、誰反應快給誰等方法，也就是形成了負載均衡算法。

以上比喻僅僅是個人理解。

負載均衡的種類

DNS

（Domain Name System 域名系統 ）它作爲將域名和IP地址相互映射的一個分佈式數據庫，能夠使人更方便地訪問互聯網。DNS使用TCP和UDP端口53。當前，對於每一級域名長度的限制是63個字符，域名總長度則不能超過253個字符。DNS是最簡單也是最常見的負載均衡方式，一般用來實現“地理級別”的負載均衡，比如說：北方人訪問北京的機房，南方人訪問廣州的機房，西方人訪問成都的機房。DNS負載均衡的本質是DNS解析同一個域名可以返回不同的IP地址。比如說： www.sina.com.cn/在北方的用戶使用時會解…

DNS簡單示意圖

優點

• 配置簡單，無成本費用
• 將負載均衡的工作交給了DNS服務器，省去了管理的麻煩。

缺點

• 記錄的添加與修改是需要一定時間才能夠生效的(因爲DNS緩存了A記錄)。一旦有一臺服務器壞了需要下線，即使修改了A記錄，要使其生效也需要較長的時間，這段時間，DNS仍然會將域名解析到已下線的服務器上，最終導致用戶訪問失敗。
• 不能按需分配負載，DNS並不知道各服務器的真實負載情況，所以負載效果不是很好

實際的情況：在實際的項目部署，我們一般會將部分服務器使用DNS解析，利用域名解析作爲第一級負載均衡.再在服務器中使用nginx負載均衡作爲第二級負載均衡。

硬件負載均衡

硬件負載均衡是通過單獨的設備來實現負載均衡的功能，這類設備和路由器交換機有那麼一些類似，更或者可以理解爲一個用於負載均衡的基礎網絡設備。目前業界主要有兩款硬件負載均衡：F5和A10。這類設備性能好，功能強大，但是價格可以用昂貴來形容，一般只有銀行，國企等大型有錢的企業開會考慮使用此類設備，本人也只是在銀行裏見識過F5。至於A10沒接觸過就不撤了。

優點

• 功能強大：全面支持各層級的負載均衡，支持各種負載均衡算法，支持全局負載均衡。
• 性能好：一般軟件負載均衡能支撐10w+併發已經很不錯了，但是硬件的負載均衡卻可以支持100w+以上的併發。
• 高穩定性：因爲是商業品，所以經過了良好嚴格的測試，經過大規模的使用，所以穩定非常高。
• 安全性高：硬件負載均衡設備除了能處理負載均衡以外，還具有防火牆、防DDOS攻擊等效果。

缺點

• 價格昂貴：我記得之前銀行購買F5花了上百萬，據說還有更貴的，所以價格可想而知。
• 擴展性不好：硬件設備可以根據業務進行配置，但無法進行擴展和定製化。

軟件負載均衡

軟件負載均衡是通過負載均衡軟件來實現負載均衡功能的。常見的負載均衡軟件有LVS和Nginx。其中LVS是Linux內核的四層負載均衡，四層和七層的區別在於他們協議和靈活性的不同。Nginx是7層負載均衡，支持HTTP，E-mail協議，而LVS是四層負載均衡，所以和協議無關，基本上所有應用都可以做到，比如說：聊天、數據庫等。

以下是Nginx的負載均衡簡單示意圖：

優點

• nginx由C編寫，同樣的web服務器，佔用的資源和內存低性能高。
• 當啓動nginx服務器，會生成一個master進程，master進程會fork出多個worker進程，由worker線程處理客戶端的請求。
• nginx支持高併發，每個worker子進程是獨立平等的，當有客戶端請求時，worker進程公平競爭，搶到的worker進程會把請求提交給後端服務器，當後端服務器沒有及時響應時，此worker進程會繼續接收下一個request,當上一個請求有響應後會觸發事件，此worker進程繼續之前的執行，知道響應結束。一個request不會被兩個worker進程執行。
• nginx支持反向代理（用戶有感知的訪問叫正向代理如使用vpn訪問youtube，用戶無感知訪問叫反向代理如負載均衡），支持7層負載均衡（拓展負載均衡的好處）。
• nginx是異步非阻塞型處理請求（第三點印證），採用的epollandqueue模式，apache是阻塞型處理請求。
• nginx處理靜態文件速度快（原因：
• nginx高度模塊化，配置簡單。
• nginx是單進程多線程）。

缺點

• 對比apache不穩定，由於是單進程多線程，進程死掉會影響很多用戶。

負載均衡有什麼用？

• **「流量分發」**負載均衡能對多臺主機流量進行分發，提高用戶系統的業務處理能力，提升服務可用性
• **「會話保持」**在會話週期內，會話保持可使來自同一IP或網段的請求被分發到同一臺後端服務器上。
• **「健康檢查」**支持自定義健康檢查方式和頻率，可定時檢查後端主機運行狀態，提供故障轉移，實現高可用；
• **「負載均衡」**解決併發壓力，提高應用處理性能（增加吞吐量，加強網絡處理能力）；
• 提高擴展性通過添加或減少服務器數量，提供網站伸縮性（擴展性）；
• 提高安全性安全防護，在負載均衡器上做一些過濾，黑白名單、防盜鏈等處理；

常用負載均衡算法

輪訓

負載均衡系統接收到請求後，按照一定順序將請求分發給服務器上。輪訓是一種簡單的負載均衡算法策略，不會去關注服務器狀態。

優點：如果服務器都是正常的，那麼輪訓是最理想的，因爲它會使得每個服務都得到相等量的請求，可以用"雨露均沾"來形容。

缺點：上面的有點是理想狀態的，但是現實往往不是那樣的，現實還是很骨感滴，線上系統往往出現各種各樣的問題，比如：當有一臺服務器掛了，輪訓算法不會管服務器狀態，就是會導致大量的請求到一臺已經掛掉的服務器上，從而導致系統不可用，進而造成用戶流失。另外一種常見的問題就是有的服務器響應快，有的響應慢（比如32核的服務器和16核的服務器），輪訓算法也不關注相應快慢，所以會導致很多服務請求響應時間慢，簡單的導致用戶體驗不好，由於響應時間慢甚至可能拖垮其他系統。

加權輪訓

負載均衡系統根據服務器權重進行請求任務分派到對應的服務器上，這裏的權重一般是根據系統硬件配置進行靜態配置的，採用動態的方式計算會更加適合業務，但是複雜度相比簡單的輪訓就高很多。

加權輪訓是輪訓的一種特殊方式，主要目的是解決服務器處理能力的差異問題，比如：集羣中有的服務器是32核，有的老系統卻是16核，那麼理論上我們可以對其進行權重配置值，即就是32核服務器的處理能力是16核的兩倍，負載均衡算法權重比例調整爲2:1，讓更多的請求分發給32核的服務器。

加權輪訓解決了輪訓算法中誤服根據服務器的配置的差異任務進行更好的分配的問題，其實還是會存在無法根據服務器的狀態差異性進行請求任務分配的問題。

負載最低優先

負載系統將請求分配給當前負載最低的服務器，這裏的負載根據不同請求類型和業務處理場景，可以用不同的指標來衡量。比如以下幾個場景，

• LVS這種4層網絡負載均衡設備，可以以連接數來判斷服務器的狀態，服務器連接數量越大，表明服務器壓力就越大。
• Nginx這種7層網絡負載均衡系統，可以以HTTP請求數量判斷服務器的狀態（Nginx內置的負載均衡算法不支持這種方式，需要自行進行擴展）。
• 如果我們是自己研發負載均衡系統，可以根據業務特點來選擇衡量系統壓力的指標。如果CPU是密集型，可以以CPU負載來衡量系統的壓力；如果是IO密集型，則可以以IO負載來衡量系統壓力。

負載最低優先算法解決了輪訓算法中無法感知服務器狀態的問題，但是由此帶來的代價是複雜度增加很多，比如：

• 最少鏈接數優先的算法要求負載系統統計每個服務器當前簡歷的鏈接，其應用場景僅限於負載均衡接收的任何請求都會轉發給服務器進行處理，否則如果負載均衡系統和服務之間是固定的連接池方式，就不適合採取這種算法。LVS可以採取這種算法進行負載均衡，而一個通過連接池的方式鏈接數據庫Mysql集羣的負載均衡系統就不適合採取這種算法進行負載均衡了。
• CPU負載均衡最低優先的算法要求負載均衡系統以某種方式收集每個服務器的CPU的具體負載情況，同時要確定是以一分鐘的負載標準，還是以10分鐘、15分鐘的負載標準，不存在1分鐘肯定比15分鐘的好或差。不同業務最優的時間間隔也是不一樣的，時間間隔太短容易造成頻繁波動，時間太長可能造成峯值來臨時響應緩慢。

負載最低優先的算法基板上能夠很完美解決了輪訓算法的缺點，也因爲採用負載最低優先算法後，負載均衡系統需要感知服務器當前運行狀態，此時，同樣造成代價上升很多。對於開發者來說也許輪訓算法只要簡短的代碼就可以實現，然而負載最低優先算法需要大量的代碼來實現。

負載最低優先看起來是解決了輪訓中的缺點，然後由於其複雜度的提升，導致真正使用中比例還不如輪訓或者輪訓加權算法。

性能最優

負載最低優先算法是站在服務器的角度來進行請求分配的，而性能最優算法是站在客戶端的角度進行分配的，優先將請求分配給處理速度快的服務器，通過這種方式達到了最快響應給客戶端。

性能優先其實也負載最低優先有點類似，都是需要感知服務器的狀態，與之不同的是性能最優是通過響應時間這個標準，在外部進行感應服務器狀態而已，同樣的實現複雜度也很高，主要體現在以下方面：

• 負載均衡系統需要收集每次請求的響應時間，如果在大量請求處理的場景下，這種收集再加上響應時間的統計本身也會消耗系統的性能。
• 爲了減少這種統計上的消耗，可以採取採樣的方式進行統計，即就是不用很完全的去統計所有服務器的所有請求時間，而是抽樣統計部分任務的響應時間來估算整體請求所花的響應時間。採樣統計雖然能減輕性能的消耗，但使得實現的複雜度增加了很多，因爲要確定合適的採樣率，採樣率太低會導致數據的正確性，採樣率高同樣會造成性能的消耗，要找到一個合適的採樣率的複雜度也是可想而知的。
• 無論全部統計，還是採樣統計，都需要選擇合適的週期，是30秒性能最優還是1分鐘最優？目前是沒有標準的週期，都是需要具體業務場景進行決策，是不是感覺到了其複雜性，尤其是線上系統需要不斷的調試，然後找出相對合適的標準。

Hash類

負載均衡系統根據請求中某些關鍵字進行hash運算，得到的相同值得分發到同一臺服務器上去，這樣做的目的主要是爲了滿足特定的業務需求，比如：

• 源地址Hash：將來源於同一個IP地址的請求分配給同一個服務器進行處理，適合於存在事務、會話的業務。例如：當我們通過瀏覽器登錄網上銀行時，會生成一個會話信息，這個會話是臨時的，關閉瀏覽器後就會失效。網上銀行後臺無須持久會話信息，只需要在某臺服務器臨時保留這個會話就可以了，但需要保證用戶在會話存在期間，每次請求都能訪問在同一個服務器，這種業務場景就是通過源地址hash來實現的。
• ID hash ：將某個ID表示的業務分配到同一臺服務器上進行處理，比如：userId session id。上述的網上銀行登錄的例子，用session id hash可以實現同一個會話期間，用戶每次都是訪問同一臺服務器上的目的。

負載均衡算法應用

Dubbo中使用了哪些負載均衡算法？

• Random LoadBalance(隨機算法，默認)
• RoundRobin LoadBalance(權重輪訓算法)
• LeastAction LoadBalance(最少活躍調用數算法)
• ConsistentHash LoadBalance(一致性Hash法)

類圖

nginx中使用了哪些負載均衡算法?

「round robin（默認）」:輪詢方式，依次將請求分配到各個後臺服務器中，默認的負載均衡方式。適用於後臺機器性能一致的情況。掛掉的機器可以自動從服務列表中剔除。

「weight」：根據權重來分發請求到不同的機器中，指定輪詢機率，weight和訪問比率成正比，用於後端服務器性能不均的情況。例如：

  
  
  

   
   
   
upstream bakend {    server 192.168.0.14 weight=10;    server 192.168.0.15 weight=10;    }

  
  
  
  
  
  

   
   
   
   
   
   

  
  
  

「IP_hash」：根據請求者ip的hash值將請求發送到後臺服務器中，可以保證來自同一ip的請求被打到固定的機器上，可以解決session問題。例如：

  
  
  

   
   
   
upstream bakend {    ip_hash;    server 192.168.0.14:88;    server 192.168.0.15:80;    }   

  
  
  
  
  
  

   
   
   
   
   
   

  
  
  

「url_hash（第三方）」：根據請求的url的hash值將請求分到不同的機器中，當後臺服務器爲緩存的時候效率高。

例如：在upstream中加入hash語句，server語句中不能寫入weight等其他的參數，hash_method是使用的hash算法 。

「fair（第三方）」：根據後臺響應時間來分發請求，響應時間短的分發的請求多。例如：

  
  
  

   
   
   
upstream backend {    server server1;    server server2;    fair;    }  
  
  
  

總結

我們用生活中的故事來講述了負載均衡，講述了什麼是負載均衡，負載均衡的作用，負載均衡的種類，負載均衡算法種類，以及我們在Dubbo和nginx中負載均衡算法的應用。

回覆【 乾貨】 獲取精選乾貨視頻教程

回覆【 加羣】 加入疑難問題攻堅交流羣

回覆【 mat】 獲取內存溢出問題分析詳細文檔教程

回覆【 賺錢】 獲取用java寫一個能賺錢的微信機器人

回覆【 副業】 獲取程序員副業攻略一份

都收藏了，就點個「在看」支持一下吧！

點下在看，你最好看

本文分享自微信公衆號 - 俠夢的開發筆記（xmdevnote）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。