負載均衡是高可用網路基礎架構的的乙個關鍵組成部分，有了負載均衡，我們通常可以將我們的應用伺服器部署多台，然後通過負載均衡將使用者的請求分發到不同的伺服器用來提高**、應用、資料庫或其他服務的效能以及可靠性。
為什麼要引入負載均衡
先看乙個沒有負載均衡機制的web架構：
上圖中的架構有什麼缺陷了？首先，使用者是通過網路直接和web伺服器相連，想象一下，如果這個伺服器掛了（這種情況隨時都可能發生的)，那麼使用者的請求就會得不到響應，將無法訪問該**，這就是著名的單點故障問題，這肯定是不行的，一般而言，商業上的**其可靠性需要達到至少4個9，也就是99.99&以上。
其次，即使伺服器是正常工作的情況，但是如果很多使用者在同一時間內訪問伺服器，超過了伺服器的處理能力，那麼會出現響應速度慢甚至無法連線的情況，這也是使用者無法接受的。
負載均衡的出現可以很好的解決上面兩個問題，通過引入乙個負載均衡器和至少兩個web 伺服器，可以有效的解決上面兩個問題。注：通常情況下，所有的後端伺服器會保證提供相同的內容，以便使用者無論哪個伺服器響應，都能收到一致的內容。
負載均衡如何選擇要**的後端伺服器
負載均衡器一般根據兩個因素來決定要將請求**到哪個伺服器。
1：確保所選擇的後端伺服器是正常工作的，能給對使用者的請求做出響應；
2：根據預先設定的負載均衡演算法從健康伺服器池中進行選擇。
由於負載均衡器只應當選擇能正常做出響應的後端伺服器，因此就需要有一種機制能判斷它所連的後端伺服器是否正常工作。為了監視後台伺服器的執行狀況，執行狀態檢查服務會定期嘗試使用**規則定義的協議和埠去連線後端伺服器。如果某個伺服器沒有通過健康檢查，就會從健康池中剔除，保證流量不會被**到該伺服器，直到其再次通過健康檢查為止。
負載均衡演算法
輪詢：為第乙個請求選擇健康池中的第乙個後端伺服器，然後按順序往後依次選擇，直到最後乙個，然後迴圈。
最小連線：優先選擇連線數最少，也就是壓力最小的後端伺服器，在會話較長的情況下可以考慮採取這種方式。
雜湊：根據請求源的 ip 的雜湊（hash）來選擇要**的伺服器。這種方式可以一定程度上保證特定使用者能連線到相同的伺服器。如果你的應用需要處理狀態而要求使用者能連線到和之前相同的伺服器，可以考慮採取這種方式。
最後，想要解決負載均衡器的單點故障問題，可以將第二個負載均衡器連線到第乙個上，從而形成乙個集群。如下圖所示：
當主負載均衡器發生了故障，就需要將使用者請求轉到第二個負載均衡器。由於 dns 更改通常會在較長的時間才能生效，因此需要有一種能靈活解決 ip 位址重新對映的方法，比如浮動 ip（floating ip）。這樣網域名稱可以保持和相同的 ip 相關聯，而 ip 本身則能在伺服器之間移動。下面就是乙個使用浮動 ip 的負載均衡架構動態示意圖：
如何理解AWS ELB（負載均衡）
通俗來說，elb類似於nginx lvs haproxy等等 elastic load balancing 跨多個可用區中的多個目標 如 amazon ec2 例項 容器和 ip 位址 分發傳入應用程式或網路流量。elastic load balancing 會在應用程式的傳入流量隨時間的推移發生更...
簡單理解各層的負載均衡
在實現haproxy的負載均衡時，看到它支援四層和七層，然後就先簡單的理解了一下不同層的負載均衡。從二層 資料鏈路層 就開始可以有負載均衡，是基於mac位址的，用乙個虛擬的mac位址接收，再 到乙個真實的mac位址上面去，三層 網路層 是基於ip位址的乙個 就是用乙個虛擬的vip來實現流量的乙個分攤...
Linux企業實戰 負載均衡（理解）
為什麼需要負載均衡 例項 我們在日常生活中經常免不了要去一些比較擁擠的地方，比如地鐵站 火車站 電影院 銀行等。無論是買票，還是排隊入場，這些場所一般都會設定多個服務點或者入口的。如果沒有人引導的話，大多數情況下，最近的入口會擠滿人。其實，的建設也是一樣的。為了提公升 的服務能力，很多 採用集群部署...