概念
負載均衡是高可用架構的一個關鍵組件，主要用來提高性能和可用性，通過負載均衡將流量分發到多個服務器，同時多服務器能夠消除這部分的單點故障。
這部分的單點故障可以通過引入負載均衡器和至少另一個Web Server來緩解。一般來說所有後端服務器會提供相同的內容，以便用戶無論訪問哪個服務器都會收到一致的內容。同時由於有多臺服務器同時提供服務，也加大了系統的負載能力提高了性能。
流量類型
由於一般程序員接觸到的負載均衡可能大多都是處理HTTP、HTTPS流量的，但實際上負載均衡還可以處理TCP和UDP流量（比如對數據庫集羣的訪問、DNS等）。
負載均衡算法
負載均衡算法用於確定流量應該被分發到哪一個健康的服務器上，常見的幾個算法如下：
Round Robin — 輪轉（Round Robin）意味着服務器會被按順序地選擇，比如負載均衡器會將第一個請求分配給第一個服務器，然後下一個請求分配給第二個服務器，這樣分配下去分配完一輪之後回到開頭分配給第一個服務器（操作系統調度算法複習一下）。這種方式比較適合各服務器處理能力相同而且每個業務處理量差不多的時候。
Least Connections — 最少連接（Least Connections）這個算法意味着負載均衡器會選擇當前連接最少的服務器。
IP hash — 在這個算法下，負載均衡器根據請求源的IP來決定分發給哪個服務器。這個方法保證了一個特定的用戶會一直訪問相同的服務器。
其他還有一些不算太常見的算法，比如Url hash、Random等。
健康檢測（health checks）
在負載均衡算法一節中我們有一個前提，就是流量只會被分配到健康的服務器上，那麼負載均衡器怎麼去判斷服務器現在是否健康呢？
爲了監控健康的服務器，健康檢查一般會通過配置的協議和端口嘗試去連接服務器來保證服務器正在監聽。如果一個服務器的健康檢查失敗了，也就是說服務器無法正常響應請求，那麼就會被自動的移除池子中，流量也不會被分配到這個壞掉的服務器直到它能通過健康檢查。
這塊具體的方式可以參考阿里雲關於負載均衡的文檔健康檢查原理
負載均衡如何處理狀態
我們都知道基於session的用戶認證會在服務器存有session的一些信息，但當系統引入負載均衡的時候這樣會出現一些問題。
舉個電商網站的例子，當用戶U發送的登錄請求被分發到了服務器S1並在服務器中記錄了session信息，而當用戶想要提交購物請求的時候這個請求被分發到了服務器S2，但服務器S2並沒有保存用戶U的session信息。
爲了解決這個問題一個是可以使用之前說的IP hash算法，這個算法根據IP來分配流量對應的服務器，所以可以保證同一個用戶的流量會訪問到同一個服務器。另一個應用層的方法是sticky session，中文應該叫粘性會話，負載均衡器會設置一個cookie然後帶有這個cookie的session都會被分配到同一個服務器上。
負載均衡雙機熱備（Hot standby）
正如開頭所說，負載均衡器本身就是一個單點故障隱患，其中一個解決方案就是雙機熱備（提高可用性的一大基本方法就是冗餘）。
雙機熱備方案爲了解決負載均衡器的單點故障問題，引入了第二個負載均衡器，當主節點GG了之後切換到備用節點。