關于負載均衡器已經有很多文章，但今天要討論的不是負載均衡器如何工作，而是如何防止負載均衡器成為單點故障。

負載均衡器是系統設計工具集中的絕佳工具，可幫助系統進行擴展。當我們需要為大流量提供服務時，將不可避免遇到單臺服務器內存和計算能力不足以為所有流量提供服務的情況。此時，有以下兩種選擇：

• 通過增加處理能力和內存使服務器更強大，但有硬件上限約束。
• 也可以運行多個服務器實例，每個實例處理部分流量。

簡單來說，負載均衡器會接收所有進入的流量，并智能的將流量分配給服務器的多個運行實例。這樣只需要增加越來越多的服務器副本，就可以無限擴容。在系統設計術語中，這被稱為水平擴容。

雖然負載均衡器可以在應用擴容時規避內存和計算限制，但并不能解決單點故障問題。

從上圖可以看到，所有請求都要經過負載均衡器，然后由負載均衡器將請求轉發到后端副本。很明顯，在這種情況下，負載均衡器本身就是一個單點。如果負載均衡器關閉或由于某種原因無法訪問，用戶將無法使用應用程序，從而造成業務全面中斷。

那么該如何防止出現這種情況，如何防止負載均衡器造成單點故障呢？下面我們將討論如何解決這一問題。

部署高可用主從負載均衡器

解決這個問題的一個辦法是將負載均衡器部署為高可用對，這意味著要部署兩個或更多負載均衡器實例，一旦其中某個負載均衡器出現故障，其他負載均衡器就能接替并繼續為客戶提供服務。

聽起來似乎是個合理的解決方案，但馬上想到的第一個問題是，客戶如何知道需要向哪個負載均衡器實例發出請求？如果負載均衡器的某個實例出現故障，其他負載均衡器如何知道？

我們來解決這些問題。

如何管理本地網絡流量

要回答上述問題，必須了解以下有關網絡路由的要點，我們需要深入了解流量是如何在網絡中路由的。

• 本地網絡內的所有流量都由一臺名為"交換機"的設備管理，而不是路由器。
• 交換機通過主機 MAC 地址向它們發送流量。
• 每當交換機收到帶有目標 IP 地址的 TCP 數據包時，都需要知道相應主機的 MAC 地址，以便將 TCP 數據包正確轉發給正確的目標機器。
• 為了解析目標 IP 地址的 MAC 地址，交換機將使用地址解析協議 (ARP，Address Resolution Protocol)，向連接到本地網絡的所有機器發送廣播，詢問它們是否正在為給定的 IP 提供服務。
• 擁有給定 IP 的主機將回復其 MAC 地址，而其他主機將直接忽略 ARP 請求。

了解了網絡路由的工作原理后，讓我們回到最初的問題。

第一步是在網絡中部署兩個負載均衡器，其中一個為主模式，另一個為從模式，這種主從模式在高可用性系統中非常常見。

這兩個負載均衡器同意共享同一個虛擬 IP 地址（虛擬 IP 地址分配給軟件系統，如負載均衡器，而不是物理設備，因此可以將其視為一個虛構的 IP 地址），并且互相發送心跳（liveness ping）。

每當交換機要將數據包轉發到虛擬 IP 地址時，首先向網絡上的所有主機發送廣播，詢問哪些機器的 MAC 地址分配了虛擬 IP 地址。主負載均衡收到廣播后，會立即以其 MAC 地址作出回應，這樣交換機就知道，今后所有屬于虛擬 IP 地址的數據包都應轉發給主負載均衡器。從負載均衡器也會收到該廣播，但不會用自己的 MAC 地址做出回應，因為它知道自己不是主負載均衡器。

兩個負載均衡器不斷相互發送心跳（liveness ping）信息。如果主負載均衡器發生故障，從負載均衡器會立即開始為虛擬 IP 地址公布自己的 MAC 地址，從而承擔起主負載均衡器的角色。

將 IP 地址解析為 MAC 地址的整個過程是通過地址解析協議（簡稱 ARP）完成的。

請注意，使用 ARP 將 MAC 地址解析為 IP 地址的過程相當快，因此當主負載均衡器發生故障時，終端用戶可能不會看到明顯的停機時間。

這就是我們確保負載均衡器不會成為單點故障的方法。請注意，還可以使用其他策略來解決這個問題，例如使用多播，或監控負載均衡器并自動更新 DNS 以指向健康的負載均衡器等。