一文秒懂分散式架構下的“負載均衡”
在網站創立初期，我們一般都使用單臺機器提供集中式服務，但隨著業務量越來越大，無論效能還是穩定性上都有了更大的挑戰。這時候我們就會想到通過擴容的方式來提供更好的服務。
什麼是負載均衡
我們一般會把多臺機器組成一個叢集對外提供服務。然而，我們的網站對外提供的訪問入口都是一個，比如 www.taobao.com。
那麼當用戶在瀏覽器輸入 www.taobao.com 的時候如何將使用者的請求分發到叢集中不同的機器上呢，這就是負載均衡在做的事情。
當前大多數的網際網路系統都使用了伺服器叢集技術，叢集即將相同服務部署在多臺伺服器上構成一個叢集整體對外提供服務。
這些叢集可以是 Web 應用伺服器叢集，也可以是資料庫伺服器叢集，還可以是分散式快取伺服器叢集等。
在實際應用中，在 Web 伺服器叢集之前總會有一臺負載均衡伺服器，負載均衡裝置的任務就是作為 Web 伺服器流量的入口，挑選最合適的一臺 Web 伺服器，將客戶端的請求轉發給它處理，實現客戶端到真實服務端的透明轉發。
最近幾年很火的「雲端計算」以及分散式架構，本質上也是將後端伺服器作為計算資源、儲存資源，由某臺管理伺服器封裝成一個服務對外提供。
客戶端不需要關心真正提供服務的是哪臺機器，在它看來，就好像它面對的是一臺擁有近乎無限能力的伺服器，而本質上，真正提供服務的是後端的叢集。
軟體負載解決的兩個核心問題是：選誰、轉發，其中最著名的是 LVS（Linux Virtual Server）。
一個典型的網際網路應用的拓撲結構是這樣的：
負載均衡分類
現在我們知道，負載均衡就是一種計算機網路技術，用來在多個計算機（計算機叢集）、網路連線、CPU、磁碟驅動器或其他資源中分配負載，以達到最佳化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。
那麼，這種計算機技術的實現方式有多種。大致可以分為以下幾種，其中最常用的是四層和七層負載均衡。
二層負載均衡
負載均衡伺服器對外依然提供一個 VIP（虛 IP），叢集中不同的機器採用相同 IP 地址，但機器的 MAC 地址不一樣。
當負載均衡伺服器接受到請求之後，通過改寫報文的目標 MAC 地址的方式將請求轉發到目標機器實現負載均衡。
三層負載均衡
三層負載均衡和二層負載均衡類似，負載均衡伺服器對外依然提供一個 VIP（虛IP），但叢集中不同的機器採用不同的 IP 地址。
當負載均衡伺服器接受到請求之後，根據不同的負載均衡演算法，通過 IP 將請求轉發至不同的真實伺服器。
四層負載均衡
四層負載均衡工作在 OSI 模型的傳輸層，由於在傳輸層，只有 TCP/UDP 協議，這兩種協議中除了包含源 IP、目標 IP 以外，還包含源埠號及目的埠號。
四層負載均衡伺服器在接受到客戶端請求後，之後通過修改資料包的地址資訊（IP+埠號）將流量轉發到應用伺服器。
七層負載均衡
七層負載均衡工作在 OSI 模型的應用層，應用層協議較多，常用 http、radius、DNS 等。
七層負載就可以基於這些協議來負載。這些應用層協議中會包含很多有意義的內容。
比如同一個 Web 伺服器的負載均衡，除了根據 IP 加埠進行負載外，還可根據七層的 URL、瀏覽器類別、語言來決定是否要進行負載均衡。
四層和七層負載均衡
對於一般的應用來說，有了 Nginx 就夠了。Nginx 可以用於七層負載均衡。但是對於一些大的網站，一般會採用 DNS+四層負載+七層負載的方式進行多層次負載均衡。
阿里雲的 SLB
常用負載均衡工具
硬體負載均衡效能優越，功能全面，但價格昂貴，一般適合初期或者土豪級公司長期使用。
因此軟體負載均衡在網際網路領域大量使用。常用的軟體負載均衡軟體有 LVS、Nginx、HAProxy 等。LVS/Nginx/HAProxy 是目前使用最廣泛的三種負載均衡軟體。
LVS
LVS（Linux Virtual Server），也就是 Linux 虛擬伺服器，是一個由章文嵩博士發起的自由軟體專案。
使用 LVS 技術要達到的目標是：通過 LVS 提供的負載均衡技術和 Linux 作業系統實現一個高效能、高可用的伺服器群集。
它具有良好可靠性、可擴充套件性和可操作性，從而以低廉的成本實現最優的服務效能。LVS 主要用來做四層負載均衡。
LVS 架構
LVS 架設的伺服器集群系統由三個部分組成：
最前端的負載均衡層（Loader Balancer）。
中間的伺服器群組層，用 Server Array 表示。
最底層的資料共享儲存層，用 Shared Storage 表示。
在使用者看來所有的應用都是透明的，使用者只是在使用一個虛擬伺服器提供的高效能服務。
LVS 的各個層次的詳細介紹：
Load Balancer 層：位於整個集群系統的最前端，有一臺或者多臺負載排程器（Director Server）組成，LVS 模組就安裝在 Director Server 上。
而 Director 的主要作用類似於一個路由器，它含有完成 LVS 功能所設定的路由表，通過這些路由表把使用者的請求分發給 Server Array 層的應用伺服器（Real Server）上。
同時，在 Director Server 上還要安裝對 Real Server 服務的監控模組 Ldirectord，此模組用於監測各個 Real Server 服務的健康狀況。在 Real Server 不可用時把它從 LVS 路由表中剔除，恢復時重新加入。
Server Array 層：由一組實際執行應用服務的機器組成，Real Server 可以是 Web 伺服器、Mail 伺服器、FTP 伺服器、DNS 伺服器、視訊伺服器中的一個或者多個。
每個 Real Server 之間通過高速的 LAN 或分佈在各地的 WAN 相連線。在實際的應用中，Director Server 也可以同時兼任 Real Server 的角色。
Shared Storage 層：是為所有 Real Server 提供共享儲存空間和內容一致性的儲存區域，在物理上一般由磁碟陣列裝置組成。
為了提供內容的一致性，一般可以通過 NFS 網路檔案系統共享資料，但 NFS 在繁忙的業務系統中，效能並不是很好。
此時可以採用叢集檔案系統，例如 Red hat 的 GFS 檔案系統、Oracle 提供的 OCFS2 檔案系統等。
從整個 LVS 結構可以看出，Director Server 是整個 LVS 的核心，目前用於 Director Server 的作業系統只能是 Linux 和 FreeBSD。
Linux2.6 核心不用任何設定就可以支援 LVS 功能，而 FreeBSD 作為 Director Server 的應用還不是很多，效能也不是很好。
對於 Real Server，幾乎可以是所有的系統平臺，Linux、Windows、Solaris、AIX、BSD 系列都能很好地支援。
Nginx
Nginx 是一個網頁伺服器，它能反向代理 HTTP、HTTPS、SMTP、POP3、IMAP 的協議連結，以及一個負載均衡器和一個 HTTP 快取。Nginx 主要用來做七層負載均衡。
併發效能：官方支援每秒 5 萬併發，實際國內一般到每秒 2 萬併發，有優化到每秒 10 萬併發的，具體效能看應用場景。
特點：
模組化設計：良好的擴充套件性，可以通過模組方式進行功能擴充套件。
高可靠性：主控程序和 worker 是同步實現的，一個 worker 出現問題，會立刻啟動另一個 worker。
記憶體消耗低：一萬個長連線（keep-alive），僅消耗 2.5MB 記憶體。
支援熱部署：不用停止伺服器，實現更新配置檔案，更換日誌檔案、更新伺服器程式版本。
併發能力強：官方資料每秒支援 5 萬併發。
功能豐富：優秀的反向代理功能和靈活的負載均衡策略。
Nginx 的基本工作模式如下圖：
一個 Master 程序，生成一個或者多個 Worker 程序。但這裡 Master 是使用 Root 身份啟動的，因為 Nginx 要工作在 80 埠。
而只有管理員才有許可權啟動小於低於 1023 的埠。Master 主要負責的作用只是啟動 Worker，載入配置檔案，負責系統的平滑升級。其他的工作是交給 Worker。
那當 Worker 被啟動之後，也只是負責一些 Web 最簡單的工作，而其他的工作都是由 Worker 中呼叫的模組來實現的。
模組之間是以流水線的方式實現功能的。流水線，指的是一個使用者請求，由多個模組組合各自的功能依次實現完成的。
比如：第一個模組只負責分析請求首部，第二個模組只負責查詢資料，第三個模組只負責壓縮資料，依次完成各自工作來實現整個工作的完成。
它們是如何實現熱部署的呢？我們前面說 Master 不負責具體的工作，而是呼叫 Worker 工作，它只是負責讀取配置檔案。
因此當一個模組修改或者配置檔案發生變化，是由 Master 進行讀取，此時不會影響到 Worker 工作。
在 Master 進行讀取配置檔案之後，不會立即把修改的配置檔案告知 Worker。
而是讓被修改的 Worker 繼續使用老的配置檔案工作，當 Worker 工作完畢之後，直接宕掉這個子程序，更換新的子程序，使用新的規則。
HAProxy
HAProxy 也是使用較多的一款負載均衡軟體。HAProxy 提供高可用性、負載均衡以及基於 TCP 和 HTTP 應用的代理，支援虛擬主機，是免費、快速並且可靠的一種解決方案。
它特別適用於那些負載特大的 Web 站點。執行模式使得它可以很簡單安全的整合到當前的架構中，同時可以保護你的 Web 伺服器不被暴露到網路上。
HAProxy 是一個使用 C 語言編寫的自由及開放原始碼軟體，它提供高可用性、負載均衡，以及基於 TCP 和 HTTP 的應用程式代理。HAProxy 主要用來做七層負載均衡。
常見負載均衡演算法
上面介紹負載均衡技術的時候提到過，負載均衡伺服器在決定將請求轉發到具體哪臺真實伺服器時，是通過負載均衡演算法來實現的。
負載均衡演算法可以分為兩類：
靜態負載均衡演算法，包括輪詢、比率、優先權。
動態負載均衡演算法，包括最少連線數、最快響應速度、觀察方法、預測法、動態效能分配、動態伺服器補充、服務質量、服務型別、規則模式。
輪詢（Round Robin）：順序迴圈將請求一次順序迴圈地連線每個伺服器。當其中某個伺服器發生第二到第七層的故障，BIG-IP 就把它從順序迴圈佇列中拿出，不參加下一次的輪詢，直到其恢復正常。
以輪詢的方式依次請求排程不同的伺服器；實現時，一般為伺服器帶上權重，這樣有兩個好處：
針對伺服器的效能差異可分配不同的負載。
當需要將某個結點剔除時，只需要將其權重設定為 0 即可。
優點：實現簡單、高效；易水平擴充套件。
缺點：請求到目的結點的不確定，造成其無法適用於有寫的場景（快取，資料庫寫）。
應用場景：資料庫或應用服務層中只有讀的場景。
隨機方式：請求隨機分佈到各個結點；在資料足夠大的場景能達到一個均衡分佈。
優點：實現簡單、易水平擴充套件。
缺點：同 Round Robin，無法用於有寫的場景。
應用場景：資料庫負載均衡，也是隻有讀的場景。
雜湊方式：根據 key 來計算需要落在的結點上，可以保證一個同一個鍵一定落在相同的伺服器上。
優點：相同 key 一定落在同一個結點上，這樣就可用於有寫有讀的快取場景。
缺點：在某個結點故障後，會導致雜湊鍵重新分佈，造成命中率大幅度下降。
解決：一致性雜湊 or 使用 keepalived 保證任何一個結點的高可用性，故障後會有其他結點頂上來。
應用場景：快取，有讀有寫。
一致性雜湊：在伺服器一個結點出現故障時，受影響的只有這個結點上的 key，最大程度的保證命中率。
例如 twemproxy 中的 ketama 方案；生產實現中還可以規劃指定子 key 雜湊，從而保證區域性相似特徵的鍵能分佈在同一個伺服器上。
優點：結點故障後命中率下降有限。
應用場景：快取。
根據鍵的範圍來負載：根據鍵的範圍來負載，前 1 億個鍵都存放到第一個伺服器，1~2 億在第二個結點。
優點：水平擴充套件容易，儲存不夠用時，加伺服器存放後續新增資料。
缺點：負載不均；資料庫的分佈不均衡。（資料有冷熱區分，一般最近註冊的使用者更加活躍，這樣造成後續的伺服器非常繁忙，而前期的結點空閒很多）
適用場景：資料庫分片負載均衡。
根據鍵對伺服器結點數取模來負載：根據鍵對伺服器結點數取模來負載；比如有 4 臺伺服器，key 取模為 0 的落在第一個結點，1 落在第二個結點上。
優點：資料冷熱分佈均衡，資料庫結點負載均衡分佈。
缺點：水平擴充套件較難。
適用場景：資料庫分片負載均衡。
純動態結點負載均衡：根據 CPU、IO、網路的處理能力來決策接下來的請求如何排程。
優點：充分利用伺服器的資源，保證多個結點上負載處理均衡。
缺點：實現起來複雜，真實使用較少。
不用主動負載均衡：使用訊息佇列轉為非同步模型，將負載均衡的問題消滅；負載均衡是一種推模型，一直向你發資料。
那麼將所有的使用者請求發到訊息佇列中，所有的下游結點誰空閒，誰上來取資料處理；轉為拉模型之後，消除了對下行結點負載的問題。
優點：通過訊息佇列的緩衝，保護後端系統，請求劇增時不會沖垮後端伺服器；水平擴充套件容易，加入新結點後，直接取 queue 即可。
缺點：不具有實時性。
應用場景：不需要實時返回的場景。比如，12036 下訂單後，立刻返回提示資訊：您的訂單進去排隊了...等處理完畢後，再非同步通知。
比率（Ratio）：給每個伺服器分配一個加權值為比例，根椐這個比例，把使用者的請求分配到每個伺服器。
當其中某個伺服器發生第 2 到第 7 層的故障，BIG-IP 就把其從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。
優先權（Priority）：給所有伺服器分組，給每個組定義優先權，BIG-IP 使用者的請求，分配給優先順序最高的伺服器組（在同一組內，採用輪詢或比率演算法，分配使用者的請求）。
當最高優先順序中所有伺服器出現故障，BIG-IP 才將請求送給次優先順序的伺服器組。這種方式，實際為使用者提供一種熱備份的方式。
最少的連線方式（Least Connection）：傳遞新的連線給那些進行最少連線處理的伺服器。
當其中某個伺服器發生第二到第七層的故障，BIG-IP 就把它從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。
最快模式（Fastest）：傳遞連線給那些響應最快的伺服器。當其中某個伺服器發生第二到第七層的故障，BIG-IP 就把它從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。
觀察模式（Observed）：連線數目和響應時間以這兩項的最佳平衡為依據為新的請求選擇伺服器。
當其中某個伺服器發生第二到第七層的故障，BIG-IP 就把它從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。
預測模式（Predictive）：BIG-IP 利用收集到的伺服器當前的效能指標，進行預測分析，選擇一臺伺服器在下一個時間片內，其效能將達到最佳的伺服器相應使用者的請求(被 BIG-IP 進行檢測)。
動態效能分配(Dynamic Ratio-APM)：根據 BIG-IP 收集到的應用程式和應用伺服器的各項效能引數，動態調整流量分配。
動態伺服器補充(Dynamic Server Act)：當主伺服器群中因故障導致數量減少時，動態地將備份伺服器補充至主伺服器群。
服務質量(QoS）：按不同的優先順序對資料流進行分配。
服務型別(ToS)：按不同的服務型別（在 Type of Field 中標識）負載均衡對資料流進行分配。
規則模式：針對不同的資料流設定導向規則，使用者可自行調整。
負載均衡的幾種演算法 Java 實現程式碼
輪詢
加權隨機負載均衡演算法
隨機負載均衡演算法
負載均衡 ip_hash 演算法
作者：陳千平，13年軟體研發從業經驗，快速學習新鮮事物，自我驅動追求卓越，積極應對問題和變化。熟練掌握.NET、Java服務端開發、iOS、BI資料庫開發，多年的移動平臺和網際網路平臺研發管理經驗。
出處：轉載自DBAplus社群
推薦閱讀：
溫馨提示：
請識別二維碼關注公眾號，點選原文連結獲取更多技術資料和文章。