一篇文章完全瞭解清楚什麼是負載均衡

本文轉載自：一篇文章完全瞭解清楚什麼是負載均衡

負載均衡是高可用網絡基礎架構的的一個關鍵組成部分，有了負載均衡，咱們一般能夠將咱們的應用服務器部署多臺，而後經過負載均衡將用戶的請求分發到不一樣的服務器用來提升網站、應用、數據庫或其餘服務的性能以及可靠性。

爲何要引入負載均衡

 

先看一個沒有負載均衡機制的web架構：

上圖中的架構有什麼缺陷了？首先，用戶是經過網絡直接和web服務器相連，想象一下，若是這個服務器掛了（這種狀況隨時均可能發生的)，那麼用戶的請求就會得不到響應，將沒法訪問該網站，這就是著名的單點故障問題，這確定是不行的，通常而言，商業上的網站其可靠性須要達到至少4個9，也就是99.99&以上。

其次，即便服務器是正常工做的狀況，可是若是不少用戶在同一時間內訪問服務器，超過了服務器的處理能力，那麼會出現響應速度慢甚至沒法鏈接的狀況，這也是用戶沒法接受的。

負載均衡的出現能夠很好的解決上面兩個問題，經過引入一個負載均衡器和至少兩個web 服務器，能夠有效的解決上面兩個問題。注：一般狀況下，全部的後端服務器會保證提供相同的內容，以便用戶不管哪一個服務器響應，都能收到一致的內容。

如上圖架構，如今，即便App 01即便掛了，負載均衡會將用戶的請求轉發到正常工做的App 02上，這解決了上面的第一個問題；其次，根據業務須要，負載均衡後端的App能夠很方便的擴展，這樣就能解決第上面的第二個問題。可是，如今單點故障問題轉移到了負載均衡器，能夠經過引入第二個負載均衡器來緩解，後面還會講到。

 

負載均衡如何選擇要轉發的後端服務器

負載均衡器通常根據兩個因素來決定要將請求轉發到哪一個服務器。

1：確保所選擇的後端服務器是正常工做的，能給對用戶的請求作出響應；

2：根據預先設置的負載均衡算法從健康服務器池中進行選擇。

因爲負載均衡器只應當選擇能正常作出響應的後端服務器，所以就須要有一種機制能判斷它所連的後端服務器是否正常工做。爲了監視後臺服務器的運行情況，運行狀態檢查服務會按期嘗試使用轉發規則定義的協議和端口去鏈接後端服務器。若是某個服務器沒有經過健康檢查，就會從健康池中剔除，保證流量不會被轉發到該服務器，直到其再次經過健康檢查爲止。

 

負載均衡算法

負載均衡算法決定了後端的哪些健康服務器會被選中。下面是幾個經常使用的算法，這裏只是簡單介紹，不具體研究其算法實現了，後面會專門用一篇文章來總結：

輪詢：爲第一個請求選擇健康池中的第一個後端服務器，而後按順序日後依次選擇，直到最後一個，而後循環。

最小鏈接：優先選擇鏈接數最少，也就是壓力最小的後端服務器，在會話較長的狀況下能夠考慮採起這種方式。

散列：根據請求源的 IP 的散列（hash）來選擇要轉發的服務器。這種方式能夠必定程度上保證特定用戶能鏈接到相同的服務器。若是你的應用須要處理狀態而要求用戶能鏈接到和以前相同的服務器，能夠考慮採起這種方式。

最後，想要解決負載均衡器的單點故障問題，能夠將第二個負載均衡器鏈接到第一個上，從而造成一個集羣。以下圖所示：

當主負載均衡器發生了故障，就須要將用戶請求轉到第二個負載均衡器。因爲 DNS 更改一般會在較長的時間才能生效，所以須要有一種能靈活解決 IP 地址從新映射的方法，好比浮動 IP（floating IP）。這樣域名能夠保持和相同的 IP 相關聯，而 IP 自己則能在服務器之間移動。下面就是一個使用浮動 IP 的負載均衡架構動態示意圖：