文章鏈接：http://www.cnblogs.com/loveis715/p/4547968.html
解決方案：
1、基於DNS的負載平衡：
當通過在瀏覽器的地址欄中鍵入域名來訪問某個網站時，瀏覽器會首先查找本地的DNS緩存是否擁有該域名對應的IP地址。
如果有，那麼瀏覽器將嘗試直接使用該IP地址訪問網址的內容。
如果本地DNS緩存中沒有該域名所對應的IP地址，那麼它將向DNS發送一個請求，以獲得該域名對應的IP並添加到本地DNS緩存中。
在DNS中，一個域名可能和多個IP地址綁定，這種情況下，DNS響應將會按照Round Robin（輪詢）方式返回這些IP地址的列表。
2、L3/4負載平衡，即基於網絡層的負載平衡：
指的是負載平衡服務器會根據OSI模型中的第三層網絡層和第四層傳輸層所包含的數據來進行負載平衡操作。
在這種負載平衡服務器中，這些數據主要包含數據包的IP頭和TCP、UDP等協議的協議頭。
工作原理：在數據到達時，負載平衡服務器將根據自身算法以及OSI模型三四層所包含的數據決定需要處理該數據的服務實例並將其轉發。
運行包含三方面內容：
（1）負載平衡服務器需要知道當前有效的服務實例有哪些；
負載平衡服務器需要週期性的發送狀態查詢請求以探測到底哪些服務實例正在有效的工作。
如果服務實例崩潰但是承載它的OS正常工作，那麼該OS仍會響應負載平衡服務器所發出的Ping命令，只是TCP連接會失敗；
如果服務實例沒有崩潰只是掛起，仍可以接受TCP連接，只是無法收到HTTP請求。
一旦負載平衡服務器發現其所管理的某個服務實例不再有效，那麼它就不會再將任何數據轉發給該服務實例，直至該服務實例迴歸正常狀態。
（2）根據自身分派算法來決定需要處理數據的服務實例；
Round Robin是最常用也是表現最好的負載平衡算法。
如果各個服務實例的容量不同，那麼負載均衡服務器會使用Weighted Round Robin算法，即根據各個服務實例的實際能力來按比例分配負載。
如果單純使用Round Robin算法，那麼具有關聯關係的各個請求可能被分配到不同的服務實例上。因此很多負載平衡服務器允許根據數據的特定特徵對這些負載進行分配，如使用一種哈希算法對用戶所在的IP進行計算，並根據計算結果決定需要分配到的服務實例。
如果某個服務器失效，那麼哈希算法中的哈希值空間將會發生變化，進而導致原本的的服務實例分配結果將不再有效。這種情況下，所有請求將重新分配服務器實例。
（3）根據分派算法的計算結果將數據發送到目標服務實例上。
三種轉發方式：
A、Direct Routing：負載平衡服務器和各服務實例必須在同一個網段上並使用同一個IP。
在收到數據後，將直接對這些數據包進行轉發。
各服務實例在在處理完數據包之後可以將相應返回給負載平衡服務器，也可以選擇將響應直接發送給用戶，而不需要再經過負載平衡服務器。
在該過程，負載平衡服務器和各個服務實例都不需要對IP層數據進行任何更改就可以對其進行轉發。這種轉發方式的吞吐量非常高。
B、Tunnelling：與A類似，唯一的不同是在負載平衡服務器和各個服務之間建立了一系列通道。
C、IP Address Translation：用戶連接的目標地址是虛擬地址（VIP，Virtual IP）。
而負載平衡服務器在連接到請求時，將目標地址轉化爲服務實例所在的實際地址（RIP，real IP），並將原地址更改爲Load Balancer所在的地址。
請求處理完畢後，服務實例將會把響應發送到負載平衡服務器，此時服務器再將響應的地址更改爲VIP，並將該響應返回給用戶。
3、L7負載平衡，即基於應用層的負載平衡：
主要通過OSI模型中的第七層應用層中的數據決定如何分發負載。
運行時，L7負載平衡服務器上的OS會將接收到的各個數據包組織成爲用戶請求，並根據在請求中多包含的數據決定由哪個服務實例來對該請求進行處理。