關於叢集、分散式和負載平衡的差異有哪些？ （圖文）

php中叢集、分散式和負載平衡之間是有很大的區別的，下面這篇文章我將給大家具體的來寫出叢集、分散式和負載平衡之間的具體的區別，話不多說，讓我們來看看。

集群的概念

　　電腦集群透過一組鬆散整合的電腦軟體和/或硬體連接起來高度緊密地協作完成計算工作。在某種意義上，他們可以被視為一台計算機。群集系統中的單一電腦通常稱為節點，通常透過區域網路連接，但也有其它的可能連接方式。叢集計算機通常用來改進單一計算機的計算速度和/或可靠性。一般情況下集群計算機比單一計算機，例如工作站或超級計算機性能價格比要高得多。
　　例如單一重負載的運算分擔到多台節點設備上做並行處理，每個節點設備處理結束後，將結果匯總，返回給用戶，系統處理能力得到大幅度提高。一般分為幾種：

• 高可用性叢集：一般是指當叢集中有某個節點失效的情況下，其上的任務會自動轉移到其他正常的節點上。也指可以將叢集中的某節點進行離線維護再上線，該過程並不影響整個叢集的運作。

• 負載平衡叢集：負載平衡叢集運行時，一般透過一個或多個前端負載平衡器，將工作負載分發到後端的一組伺服器上，從而達到整個系統的高效能和高可用性。

• 高效能運算叢集：高效能運算叢集採用將運算任務指派到叢集的不同運算節點而提高運算能力，因而主要應用在科學計算領域。

分散式

　　叢集：同一個業務，部署在多個伺服器上。分散式：一個業務分拆成多個子業務，或本身就是不同的業務，部署在不同的伺服器上。
　　簡單說，分散式是以縮短單一任務的執行時間來提升效率的，而群集則是透過提高單位時間內執行的任務數來提升效率。舉例：就例如新浪網，訪問的人多了，他可以做一個群集，前面放一個均衡伺服器，後面幾台伺服器完成同一業務，如果有業務訪問的時候，響應伺服器看哪台伺服器的負載不是很重，就將給哪一台去完成，並且一台伺服器垮了，其它的伺服器可以頂上來。分散式的每個節點，都完成不同的業務，一個節點垮了，那麼這個業務可能就失敗了。

負載平衡

概念

　　隨著業務量的提高，現有網路的各個核心部分訪問量和資料流量的快速成長，其處理能力和運算強度也相應地增加，使得單一的伺服器設備根本無法承擔。在此情況下，如果丟掉現有設備去做大量的硬體升級，這樣將造成現有資源的浪費，而且如果再面臨下一次業務量的提升時，這又將導致再一次硬體升級的高額成本投入，甚至性能再卓越的設備也無法滿足當前業務量成長的需求。
　　負載平衡技術透過設定虛擬伺服器IP（VIP），將後端多台真實伺服器的應用資源虛擬成一台高效能的應用伺服器，透過負載平衡演算法，將使用者的請求轉送給後台內網伺服器，內網伺服器將請求的回應傳回給負載平衡器，負載平衡器再將回應傳送到用戶，這樣就向網際網路用戶隱藏了內網結構，阻止了用戶直接存取後台（內網）伺服器，使得伺服器更加安全，可以阻止對核心網路堆疊和運行在其它連接埠服務的攻擊。並且負載平衡設備（軟體或硬體）會持續的對伺服器上的應用狀態進行檢查，並自動對無效的應用伺服器進行隔離，實現了一個簡單、擴展性強、可靠性高的應用解決方案，解決了單一伺服器處理效能不足，擴充性不夠，可靠性較低的問題。
　　系統的擴展可分為縱向（垂直）擴展和橫向（水平）擴展。縱向擴展，是從單機的角度透過增加硬體處理能力，例如CPU處理能力，記憶體容量，磁碟等方面，實現伺服器處理能力的提升，無法滿足大型分散式系統（網站），大流量，高並發，海量數據的問題。因此需要採用橫向擴展的方式，透過添加機器來滿足大型網站服務的處理能力。例如：一台機器不能滿足，則增加兩台或多台機器，共同承擔存取壓力。

　　負載平衡最重要的一個應用是利用多台伺服器提供單一服務，這種方案有時也稱之為伺服器農場。通常，負載平衡主要應用於Web網站，大型的Internet Relay Chat網絡，高流量的文件下載網站，NNTP（Network News Transfer Protocol）服務和DNS服務。現在負載平衡器也開始支援資料庫服務，稱為資料庫負載平衡器。
　　伺服器負載平衡有三個基本Feature：負載平衡演算法，健康檢查和會話保持，這三個Feature是保證負載平衡正常運作的基本要素。其他一些功能都是在這三個功能之上的一些深化。以下我們具體介紹一下各個功能的作用和原理。
　　在沒有部署負載平衡設備之前，使用者直接存取伺服器位址（中間或許有在防火牆上將伺服器位址對應成別的位址，但本質上還是一對一的存取）。當單一伺服器因效能不足而無法處理眾多使用者的存取權時，就要考慮用多台伺服器來提供服務，實現的方式就是負載平衡。負載平衡設備的實作原理是把多台伺服器的位址對應成一個對外的服務IP（我們通常稱之為VIP，關於伺服器的映射可以直接將伺服器IP對應成VIP位址，也可以將伺服器IP:Port映射成VIP:Port，不同的映射方式會採取相應的健康檢查，在端口映射時，伺服器端口與VIP端口可以不相同）,這個過程對用戶端是不可見的，用戶實際上不知道伺服器是做了負載平衡的，因為他們訪問的還是一個目的IP，那麼用戶的訪問到達負載平衡設備後，如何把用戶的訪問分發到合適的伺服器就是負載平衡設備要做的工作了，具體來說用到的就是上述的三大Feature。
我們來做一個詳細的存取流程分析:

　　用戶(IP:207.17.117.20)造訪網域名稱www.a10networks.com，首先會透過DNS查詢解析出這個網域的公網位址：199.237.202.124，接下來使用者207.17.117.20會存取199.237.202.124這個位址，因此封包會到達負載平衡設備，接下來負載平衡設備會把封包分送到適當的伺服器，看下圖：

　　負載平衡設備在將封包發給伺服器時，封包是做了一些變化的，如上圖所示，封包到達負載平衡在設備之前，來源位址是：207.17.117.20，目的位址是：199.237.202.124，當負載平衡設備將封包轉送給選取的伺服器時，來源位址還是：207.17.117.20，目的位址轉為172.16.20.1，我們稱這種方式為目的位址NAT(DNAT，目的位址轉換)。一般來說，在伺服器負載平衡中DNAT是一定要做的（還有另一種模式叫做伺服器直接回傳-DSR，是不做DNAT的，我們將另行討論），而來源位址依部署模式的不同，有時候也需要轉換成別的位址，我們稱之為：來源位址NAT(SNAT)，一般來說，旁路模式需要做SNAT，而串接模式不需要，本示意圖為串接模式，所以來源位址沒做NAT。
　　我們再看伺服器的回傳包，如下圖所示，也經過了IP位址的轉換過程，不過應答包中來源/目的位址與請求包正好對調，從伺服器回來的套件來源位址為172.16.20.1 ，目的位址為207.17.117.20，到達負載平衡設備後，負載平衡設備將來源位址改為199.237.202.124，然後轉發給用戶，保證了存取的一致性。

負載平衡演算法

　　一般來說負載平衡設備都會預設支援多種負載平衡分發策略，例如：

• 輪詢（RoundRobin）將請求順序循環地傳送到每個伺服器。當其中某台伺服器發生故障，AX就把其從順序循環隊列中拿出，不參加下一次的輪詢，直到其恢復正常。

• 比率（Ratio）：給每個伺服器一個加權值為比例，根椐這個比例，把使用者的請求分配到每個伺服器。當其中某台伺服器發生故障，AX就把其從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。

• 優先權（Priority）：給所有伺服器分組，給每個群組定義優先權，將使用者的請求分配給優先等級最高的伺服器群組（在同一群組內，採用預先設定的輪詢或比率演算法，分配使用者的請求）；當最高優先權中所有伺服器或指定數量的伺服器發生故障，AX會將請求送給次優先順序的伺服器群組。這種方式，實際上為使用者提供一種熱備份的方式。

• #

• 最少連線數（LeastConnection）：AX會記錄目前每台伺服器或服務連接埠上的連線數，新的連線將傳遞給連線數最少的伺服器。當其中某台伺服器發生故障，AX就把其從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。

• 最快回應時間（Fast Reponse time）：新的連線傳遞給那些回應最快的伺服器。當其中某台伺服器發生故障，AX就把其從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。

• #哈希演算法( hash): 將客戶端的來源位址，連接埠進行哈希運算，根據運算的結果轉送給一台伺服器進行處理，當其中某個伺服器發生故障，就把其從伺服器佇列中拿出，不參加下一次的使用者請求的分配，直到其恢復正常。

• 基於封包的內容分發：例如判斷HTTP的URL，如果URL中帶有.jpg的副檔名，就把資料包轉送到指定的伺服器。

健康檢查

　　健康檢查用於檢查伺服器開放的各種服務的可用狀態。負載平衡設備一般會配置各種健康檢查方法，例如Ping，TCP，UDP，HTTP，FTP，DNS等。 Ping屬於第三層的健康檢查，用於檢查伺服器IP的連通性，而TCP/UDP屬於第四層的健康檢查，用於檢查服務端口的UP/DOWN，如果要檢查的更準確，就要用到基於7層的健康檢查，例如建立HTTP健康檢查，Get一個頁面回來，並且檢查頁面內容是否包含一個指定的字串，如果包含，則服務是UP的，如果不包含或取不回頁面，就認為該伺服器的Web服務是不可用（DOWN）的。例如，負載平衡設備檢查到172.16.20.3這台伺服器的80連接埠是DOWN的，負載平衡設備將不會把後面的連線轉送到這台伺服器，而是根據演算法將封包轉送到別的伺服器。建立健康檢查時可以設定檢查的間隔時間和嘗試次數，例如設定間隔時間為5秒，嘗試次數為3，那麼負載平衡設備每隔5秒發起一次健康檢查，如果檢查失敗，則嘗試3次，如果3次都檢查失敗，則把該服務標記為DOWN，然後伺服器仍然會每隔5秒對DOWN的伺服器進行檢查，當某個時刻發現該伺服器健康檢查又成功了，則把該伺服器重新標記為UP。健康檢查的間隔時間和嘗試次數要根據綜合情況來設置，原則是既不會對業務產生影響，又不會對負載平衡設備造成較大負擔。

會話保持

　　如何保證一個使用者的兩次http請求轉送到同一個伺服器，這就要求負載平衡設備配置會話保持。
　　會話保持用於保持會話的連續性和一致性，由於伺服器之間很難做到實時同步用戶訪問信息，這就要求把用戶的前後訪問會話保持到一台伺服器上來處理。舉個例子，使用者造訪一個電子商務網站，如果使用者登入時是由第一台伺服器來處理的，但使用者購買商品的動作卻由第二台伺服器來處理，第二台伺服器由於不知道使用者訊息，所以本次購買就不會成功。這種情況就需要會話保持，把使用者的操作都透過第一台伺服器來處理才能成功。當然不是所有的訪問都需要會話保持，例如伺服器提供的是靜態頁面例如網站的新聞頻道，各台伺服器都有相同的內容，這種訪問就不需要會話保持。
　　絕大多數的負載平衡產品都支援兩類基本的會話保持方式：來源/目的位址會話保持和cookie會話保持，另外像hash，URL Persist等也是比較常用的方式，但不是所有裝置都支援。基於不同的應用程式要配置不同的會話保持，否則會造成負載的不均衡甚至存取異常。我們主要分析B/S結構的會話保持。

基於B/S結構的應用：

　　對於普通B/S結構的應用內容，例如網站的靜態頁面，可以不用配置任何的會話保持，但是對於一個基於B/S結構尤其是中間件平台的業務系統來說，必須配置會話保持，一般情況下，我們配置來源位址會話保持可以滿足需求，但是考慮到客戶端可能有上述不利於來源位址會話保持的環境，採用Cookie會話保持是一個更好的方式。 Cookie會話保持會把負載平衡設備選擇的Server資訊保存在Cookie中傳送到客戶端，客戶端持續存取時，會把該Cookie帶來，負載平衡器透過分析Cookie把會話保持到先前選定的伺服器。 Cookie分為檔案Cookie和記憶體cookie，檔案cookie會儲存在客戶端電腦硬碟上，只要該cookie檔案不過期，則無論是否重複關閉開放瀏覽器都能保持到同一台伺服器。記憶體Cookie則是把Cookie資訊儲存在記憶體中，Cookie的生存時間從開啟瀏覽器存取開始，關閉瀏覽器結束。由於現在的瀏覽器對Cookie都有一定預設的安全設置，有些客戶端可能規定不准使用檔案Cookie，所以現在的應用程式開發多使用記憶體Cookie。
　　然而，記憶體Cookie也不是萬能的，例如瀏覽器為了安全可能會完全停用Cookie，這樣Cookie會話保持就失去了作用。我們可以透過Session-id來實現會話保持，即將session-id作為url參數或放在隱藏字段<input type="hidden">中，然後分析Session-id進行分發。
　　另一個方案是：將每個會話資訊儲存到一個資料庫中。由於這個方案會增加資料庫的負載，所以這個方案對效能的提升並不好。資料庫最好是用來儲存會話時間比較長的會話資料。為了避免資料庫出現單點故障，並且提高其擴展性，資料庫通常會複製到多台伺服器上，透過負載平衡器來分發請求到資料庫伺服器上。
　　基於來源/目的位址會話保持其實不太好用，因為客戶可能是透過DHCP，NAT或Web代理來連接Internet的，其IP位址可能經常變換，這使得這個方案的服務品質無法保障。
NAT(Network Address Translation，網路位址轉換):當在專用網內部的一些主機本來已經分配到了本地IP位址(即僅在本專用網內使用的專用位址)，但現在又想和因特網上的主機通訊(並不需要加密)時，可使用NAT方法。這種方法需要在專用網路連接到網際網路的路由器上安裝NAT軟體。裝有NAT軟體的路由器叫做NAT路由器，它至少有一個有效的外部全球IP位址。這樣，所有使用本地位址的主機在和外界通訊時，都要在NAT路由器上將其本地位址轉換成全球IP位址，才能和網際網路連線。

負載平衡的其他好處

高擴展性

　　透過新增或減少伺服器數量，可以更好的應對高並發請求。

（伺服器）健康檢查

　　負載平衡器可以檢查後台伺服器應用程式層的健康狀況並從伺服器集區移除那些故障的伺服器，提高可靠性。

TCP 連線複用（TCP Connection Reuse）

　　TCP連線複用技術透過將前端多個客戶的HTTP請求復用到後端與伺服器建立的一個TCP連線。這種技術能夠大幅減小伺服器的效能負載，減少與伺服器之間新建TCP連線所帶來的延時，並最大限度的降低客戶端對後端伺服器的並發連線數請求，減少伺服器的資源佔用。
　　一般情況下，客戶端在發送HTTP請求之前需要先與伺服器進行TCP三次握手，建立TCP連接，然後發送HTTP請求。伺服器收到HTTP請求後進行處理，並將處理的結果傳回客戶端，然後客戶端和伺服器互相傳送FIN並在收到FIN的ACK確認後關閉連線。在這種方式下，一個簡單的HTTP請求需要十幾個TCP封包才能處理完成。
　　採用TCP連線復用技術後，客戶端（如：ClientA）與負載平衡設備之間進行三次握手並發送HTTP請求。負載平衡設備收到請求後，會偵測伺服器是否存在空閒的長連接，如果不存在，伺服器將建立一個新連接。當HTTP請求回應完成後，用戶端則與負載平衡設備協商關閉連接，而負載平衡則保持與伺服器之間的這個連接。當有其它客戶端（如：ClientB）需要發送HTTP請求時，負載平衡設備會直接向與伺服器之間保持的這個空閒連線發送HTTP請求，避免了由於新建TCP連線造成的延遲和伺服器資源耗費。

#

　　在HTTP 1.1中，客戶端可以在一個TCP連線中傳送多個HTTP請求，這種技術叫做HTTP復用（HTTP Multiplexing）。它與TCP連線複用最根本的區別在於，TCP連線複用是將多個客戶端的HTTP請求復用到一個伺服器端TCP連線上，而HTTP複用則是一個客戶端的多個HTTP請求透過一個TCP連接進行處理。前者是負載平衡設備的獨特功能；而後者是HTTP 1.1協定所支援的新功能，目前由大多數瀏覽器所支援。

HTTP快取

　　負載平衡器可以儲存靜態內容，當使用者請求它們時可以直接回應使用者而不必再向背景伺服器請求。

TCP緩衝

　　TCP緩衝是為了解決後端伺服器網速與客戶的前端網路速度不符而造成的伺服器資源浪費的問題。客戶端與負載平衡之間所採用的連結具有較高的延遲和較低的頻寬，而負載平衡與伺服器之間採用時延較低和高頻寬的區域網路連線。由於負載平衡器可以暫存後台伺服器對客戶的回應數據，再將它們轉發給那些回應時間較長網速較慢的客戶，如此後台Web伺服器就可以釋放相應的執行緒去處理其它任務。

SSL加速

　　一般情況下，HTTP採用明文的方式在網路上傳輸，有可能被非法竊聽，尤其是用於認證的口令資訊等。為了避免這樣的安全問題，一般採用SSL協定（即：HTTPS）對HTTP協定進行加密，以確保整個傳輸過程的安全性。在SSL通訊中，首先採用非對稱金鑰技術交換認證訊息，並交換伺服器和瀏覽器之間用於加密資料的會話金鑰，然後利用該金鑰對通訊過程中的資訊進行加密和解密。
　　SSL是一種需要耗費大量CPU資源的安全技術。目前，大多數負載平衡設備均採用SSL加速晶片（硬體負載平衡器）進行SSL資訊的處理。這種方式比傳統的採用伺服器的SSL加密方式提供更高的SSL處理效能，從而節省大量的伺服器資源，使伺服器能夠專注於業務請求的處理。另外，採用集中的SSL處理，也能簡化憑證的管理，減少日常管理的工作量。

內容過濾

　　有些負載平衡器可以依要求修改通過它的資料。

入侵阻止功能

　　在防火牆保障網路層/傳輸層安全的基礎上，提供應用層安全防範。

分類

　　下面從不同層次討論負載平衡的實作：

DNS 負載平衡

　　DNS負責提供網域解析服務，當造訪某個站點時，實際上首先需要透過該網站網域名稱的DNS伺服器來取得網域名稱指向的IP位址，在這過程中，DNS伺服器完成了網域到IP位址的映射，同樣，這樣映射也可以是一對多的，這時候，DNS伺服器便充當了負載平衡調度器，將使用者的請求分散到多台伺服器上。使用dig指令來看下”baidu”的DNS設定：

　　可見baidu擁有三個A記錄。

　　這種技術的優點是，實現簡單、實施容易、成本低、適用於大多數TCP/IP應用，並且DNS伺服器可以在所有可用的A記錄中尋找離用戶最近的一台伺服器。但是，其缺點也非常明顯，首先這種方案不是真正意義上的負載平衡，DNS伺服器將Http請求平均地分配到後台的Web伺服器上（或根據地理位置），而不考慮每個Web伺服器目前的負載狀況；如果後台的Web伺服器的設定和處理能力不同，最慢的Web伺服器將成為系統的瓶頸，處理能力強的伺服器無法充分發揮作用；其次未考慮容錯，如果後台的某台Web伺服器發生故障，DNS伺服器仍然會把DNS請求分配到這台故障伺服器上，導致無法回應客戶端。最後一點是致命的，有可能造成相當一部分客戶不能享受Web服務，並且由於DNS緩存的原因，所造成的後果要持續相當長一段時間(一般DNS的刷新周期約為24小時)。所以在國外最新的建設中心Web站點方案中，已經很少採用這種方案了。

連結層（OSI 第二層）負載平衡

　　在通訊協定的資料鏈結層修改mac位址，進行負載平衡。
　　資料分發時，不修改ip位址（因為還看不到ip位址），只修改目標mac位址，並且配置所有後端伺服器虛擬ip和負載平衡器ip位址一致，達到不修改封包的來源地址和目標地址，進行資料分發的目的。
　　實際處理伺服器ip和資料請求目的ip一致，不需要經過負載平衡伺服器進行位址轉換，可將回應資料包直接回傳給使用者瀏覽器，避免負載平衡伺服器網路卡頻寬成為瓶頸。也稱為直接路由模式（DR模式）。如下圖：

　　效能很好，但是配置複雜，目前應用比較廣泛。

傳輸層（OSI 第四層）負載平衡

　　傳輸層是 OSI 第四層，包括 TCP 和 UDP。流行的傳輸層負載平衡器有 HAProxy（這個也用於應用層負載平衡）和 IPVS。
　　主要透過封包中的目標位址和連接埠，再加上負載平衡設備設定的伺服器選擇方式，決定最終選擇的內部伺服器。
　　以常見的TCP為例，負載平衡設備在接收到第一個來自客戶端的SYN 請求時，即透過上述方式選擇一個最佳的伺服器，並對封包中目標IP位址進行修改(改為後端伺服器IP），直接轉送該伺服器。 TCP的連線建立，即三次握手是客戶端和伺服器直接建立的，負載平衡設備只是起到一個類似路由器的轉發動作。在某些部署情況下，為確保伺服器回包可以正確傳回給負載平衡設備，在轉送封包的同時可能也會對封包原來的來源位址進行修改。

應用層（OSI 第七層）負載平衡

　　應用層是 OSI 第七層。它包括 HTTP、HTTPS 和 WebSockets。一款非常流行又久經考驗的應用層負載平衡器就是 Nginx[恩靜埃克斯 = Engine X]。
　　所謂七層負載平衡，也稱為“內容交換”，也就是主要透過封包中的真正有意義的應用層內容，再加上負載平衡設備設定的伺服器選擇方式，決定最終選擇的內部伺服器.注意此時可以看到具體的http請求的完整url，因此可以實現下圖所示的分發：

#　　以常見的TCP為例，負載平衡設備如果要根據真正的應用層內容再選擇伺服器，只能先代理最終的伺服器和客戶端建立連線(三次握手)後，才能看到客戶端發送的真正應用層內容的封包，然後再根據該封包中的特定字段，再加上負載平衡設備設定的伺服器選擇方式，決定最終選擇的內部伺服器。負載平衡設備在這種情況下，更類似於一個代理伺服器。負載平衡和前端的客戶端以及後端的伺服器會分別建立TCP連線。所以從這個技術原理來看，七層負載平衡明顯的對負載平衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。那麼，為什麼還需要七層負載平衡呢？

　　七層負載平衡的好處，是使得整個網路更"智慧化"，例如上面列舉的負載平衡的好處，大部分都基於七層負載平衡。例如訪問一個網站的使用者流量，可以透過七層的方式，將對圖片類別的請求轉發到特定的圖片伺服器並可以使用快取技術；將對文字類別的請求可以轉發到特定的文字伺服器並可以使用壓縮技術。當然這只是七層應用的小案例，從技術原理上，這種方式可以對客戶端的請求和伺服器的回應進行任意意義上的修改，極大的提升了應用系統在網路層的靈活性。
　　另外一個常常被提到功能就是安全性。網路中最常見的SYN Flood攻擊，即駭客控制眾多來源客戶端，使用虛假IP位址對相同目標發送SYN攻擊，通常這種攻擊會大量發送SYN封包，耗盡伺服器上的相關資源，以達到Denial of Service(DoS)的目的。從技術原理上也可以看出，四層模式下這些SYN攻擊都會被轉發到後端的伺服器上；而七層模式下這些SYN攻擊自然在負載平衡設備上就截止，不會影響後台伺服器的正常運作。另外負載平衡設備可在七層層面設定多種策略，過濾特定封包，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提升系統整體安全。
　　現在的七層負載平衡，主要還是著重於應用廣泛的HTTP協議，所以其應用範圍主要是眾多的網站或者內部資訊平台等基於B/S開發的系統。四層負載平衡則對應其他TCP應用，例如基於C/S開發的ERP等系統。

相關推薦：

總結關於分散式叢集注意點

#

以上是關於叢集、分散式和負載平衡的差異有哪些？ （圖文）的詳細內容。更多資訊請關注PHP中文網其他相關文章！