負載均衡器–系統設計面試問題

許多人在日常生活中使用不同的Web服務，他們也從這些服務中獲得快速響應。但是，大多數用戶並不了解負責通過Internet傳遞內容的過程的規模。他們沒有意識到在後台擴展系統所需的漫長過程。這個漫長的過程涉及到當成千上萬的用戶同時在網站上發出請求時，跨多個服務器分配請求。

當網站變得非常流行時，該網站上的流量會增加，並且單個服務器上的負載也會增加。並發流量使單個服務器不堪重負，網站對用戶而言變慢了。為了滿足這些海量數據的要求並以快速可靠的方式返回正確的響應，我們需要擴展服務器。這可以通過向網絡添加更多服務器並將所有請求分佈在這些服務器上來完成。但…。誰將決定哪個請求應該路由到哪個服務器…？
答案是…負載均衡器。讓我們詳細了解負載均衡器的概念…

什麼是負載均衡器？

負載均衡器充當坐在服務器前面的“交通警察”，並在所有服務器之間路由客戶端請求。它只是簡單地將請求的操作集（數據庫寫請求，緩存查詢）有效地分佈在多個服務器上，並確保沒有一個服務器承擔太多的請求，從而導致應用程序的整體性能下降。負載均衡器可以是物理設備，也可以是在專用硬件或軟件進程上運行的虛擬實例。
考慮一個應用程序在單個服務器上運行並且客戶端直接連接到該服務器而沒有負載平衡的情況。如下圖所示。

我們需要討論此模型的兩個主要問題……

我們需要討論此模型的兩個主要問題……

• 單點故障：如果服務器出現故障或某事發生在整個應用程序將被中斷的服務器，它會為用戶不可用的一個特定時期。這將給 用戶帶來糟糕的體驗，而這是服務提供商無法接受的。
• 服務器超載：Web服務器可以處理的請求數量受到限制。如果業務增長且請求數量增加，則服務器將過載。為了解決請求的數量不斷增加，我們需要增加一個數更多的服務器，我們需要分發請求到服務器集群。

為了解決上述問題並分配請求數量，我們可以在Web服務器之前添加負載均衡器，並通過在網絡中添加任意數量的Web服務器來使我們的服務處理任意數量的請求。我們可以將請求分散到多個服務器上。由於某些原因，如果其中一台服務器脫機，則該服務將繼續。而且，每個請求的等待時間將減少，因為每個服務器不再成為RAM /磁盤/ CPU的瓶頸。

• 負載平衡器可最大程度地縮短服務器響應時間，並最大程度地提高吞吐量。
• 負載均衡器通過僅向在線服務器發送請求來確保高可用性和可靠性
• 負載平衡器會進行連續的運行狀況檢查，以監視服務器處理請求的能力。
• 根據請求數或需求量，負載均衡器添加或刪除服務器數。

负载均衡器通常放置在哪里？

下圖是可以放置負載均衡器的圖像…

• 在客戶端應用程序/用戶和服務器之間
• 在服務器和應用程序/作業服務器之間
• 在應用程序服務器和緩存服務器之間
• 在緩存服務器之間，數據庫服務器

負載均衡器的類型

我們可以通過三種方式實現負載平衡。這些是…

1.客戶端中的軟件負載平衡器

顧名思義，負載平衡的所有邏輯都駐留在客戶端應用程序（例如手機應用程序）上。客戶端應用程序將提供與Web服務器/應用程序服務器進行交互 的列表。應用程序選擇列表中的第一個，並從服務器請求數據。如果持續發生任何故障（重試的配置數量後）和服務器變得不可用，則 丟棄該服務器，並選擇另一個從列表中繼續處理。這是實現負載平衡的最便宜的方法之一。

2.服務中的軟件負載平衡器

這些負載平衡器是接收一組請求並根據一組規則重定向這些請求的軟件。此負載平衡器可提供更多的靈活性，因為它可以安裝在任何標准設備（例如Windows或Linux計算機）上。它也更便宜，因為與硬件負載平衡器不同，它無需購買或維護物理設備。您可以選擇使用現成的軟件負載平衡器，也可以編寫自定義軟件（例如：Microsoft Office365的負載平衡Active Directory查詢）來進行負載平衡。

3.硬件負載平衡器

顧名思義，我們使用物理設備在網絡服務器群集之間分配流量。這些負載平衡器也被稱為第4-7層路由器和它們能夠處理所有類型的HTTP，HTTPS，TCP的，和UDP通信。 HLD為外部世界提供虛擬服務器地址。當客戶端應用程序發出請求時，它將連接轉發到最合適的真實服務器，進行雙向網絡地址轉換（NAT）。 HLDS可以處理大量的流量，但它帶有一個沉重的價格標籤，它也具有靈活性有限。

HLD會繼續對每台服務器進行運行狀況檢查，並確保每台服務器都能正確響應。如果任何服務器均未產生所需的響應， 它將立即停止將流量發送到服務器。這些負載均衡是昂貴的獲取和配置，這就是原因很多服務提供商使用它作為唯一的用戶請求的第一個切入點。後來，內部軟件負載平衡器用於將數據重定向到基礎結構牆後面。

不同類別的負載平衡

通常，負載均衡器分為三類：

1.第4層（L4）負載均衡器

在OSI模型層4是傳輸層（其中的路由（TCP / SSL）作出決定。第4層負載平衡器也被稱為網絡負載平衡和顧名思義它利用網絡層信息，以使所述路由決定為L4負載平衡器每秒可以控制數百萬個請求，並處理所有形式的TCP / UDP流量，該決定將基於數據包使用的TCP或UDP端口以及它們的源IP地址和目標IP地址。也對請求數據包執行網絡地址轉換（NAT），但不執行檢查每個數據包的實際內容。本的類別負載平衡器最大化通過分發跨IP地址，交換機和路由器的業務的利用率和可用性。

2.第7層（L7）負載均衡器

第7層負載平衡器也稱為應用程序負載平衡器或HTTP（S）負載平衡器。它是最古老的負載平衡形式之一。在OSI模型中，第7層是執行路由決策的應用程序層（HTTP / HTTPS）。7層增加了內容切換到負載平衡和它使用的信息，諸如HTTP標頭，餅乾，統一資源標識符，SSL會話ID，和HTML表單數據來決定的服務器之間進行的路由請求。

3.全局服務器負載平衡（GSLB）

如今，許多應用程序都託管在多個地理位置的雲數據中心中。這就是許多組織遷移到不同的負載平衡器的原因，該負載平衡器可以為任何設備或位置提供具有更高可靠性和更低延遲的應用程序。 w ^第i個在負載均衡的能力顯著變化， GSLB滿足 這些 IT組織的期望。 GSLB擴展了不同地理位置的L4和L7服務器的功能，並有效地在多個數據中心之間分配 了大量流量。它還可以確保最終用戶獲得一致的體驗 當他們在數字工作空間中瀏覽多個應用程序和服務時。

負載均衡算法

1.循環賽

請求以順序或輪流方式分佈在服務器之間。例如， 在第一個請求進入第一個服務器，在第二個進入到第二個服務器，第三個請求轉到第三個服務器，它進一步持續所有牛逼他的請求。這很容易實現，但是它不考慮服務器上已經存在的負載，因此存在其中一台服務器 接收大量請求並變得過載的風險。

2.加權循環賽

它與循環技術非常相似。唯一的區別是，為列表中的每個資源提供了一個加權分數。根據加權分數，請求將分配到這些服務器。因此，在這種方法中，某些服務器在整體請求中獲得了更大的份額。

3.最少連接方法

在這種方法中，請求將以最少數量的請求或活動連接被定向到服務器。為此，負載均衡器需要做一些額外的計算，以識別連接數最少的服務器。與輪詢方法相比，這可能要花一些錢，但評估是基於服務器上的當前負載。當服務器之間的流量分佈不均時，存在大量持久連接時，此算法最有用。

4.最小響應時間方法

這種技術比更複雜的最小連接方法。在該方法中，所述請求 被轉發至服務器以最少的活動連接和所述至少平均響應時間。服務器花費的響應時間代表服務器的負載以及整體預期的用戶體驗。

5.源IP哈希

在這種方法中，請求是根據客戶端的IP地址發送到服務器的。客戶端的IP地址和接收的計算實例是使用密碼算法計算的。

在系統設計面試期間如何使用負載平衡？

在系統設計面試中，系統將詢問您一些可伸縮性問題，您必須在其中解釋 負載平衡器如何幫助分配流量以及如何確保應用程序中服務的可伸縮性和可用性。您需要在 本文中牢記的總體概念是…

• 負載平衡器可實現彈性可伸縮性，從而提高性能和數據吞吐量。它允許您保留許多數據副本（冗餘）以確保系統的可用性。我ñ情況下，如果一台服務器出現故障或失敗，你將有備份恢復服務。
• 負載均衡器可以放在任何軟件層。
• 許多公司利用兩者的硬件和軟件來實現負載均衡，取決於在其系統中不同規模的點。