1、隱藏真實服務器
當一臺服務器無法滿足用戶的請求量時，首先的方案就是將系統多部署幾份，這樣用戶的訪問請求就可以分散到各個服務器，這樣單臺服務器的壓力就小得多了。但是需要面對的問題就是，對於客戶來說，最好只有一個服務器。
此時我們能想到的，就是DNS，可以設置一下，讓對外的域名映射到多個服務器的IP，用戶面對的是系統的域名，然後可以採用輪詢的方式，如下圖所示：
但是這樣存在一個問題，因爲DNS這個分層系統是存在緩存的，且用戶端的機器也有緩存，如果某個機器出現了故障，域名解析的卻還是那個機器，那麼用戶訪問就異常了。
2、通過軟件實現負載均衡
如下圖所示，其中的LB就代表是要開發的負載均衡器吧。LB有兩個IP，一個對外，一個對內，用戶看到的就是對外IP了。
接下來看下數據包：
客戶發給負載均衡器的數據包如下所示：
如果負載均衡器想將數據包發給RS1這臺服務器，那麼就可以將數據包修改爲這樣：
當RS1處理完，要發送結果給客戶端。
而這個數據包，肯定是需要經過LB這個網關的，所以LB收到數據包後，再次替換掉源地址和源端口，再發送給客戶。
即數據包的流向如下圖所示：
而LB如何選擇後面的各個真實的服務器，則有很多種的策略。如輪詢、加權輪詢、最少連接等等。
3、四層還是七層
問題：如果按照上述的負載均衡的方式，又引出另外一個問題，對於用戶的一個請求來說，可能會被分成多個數據包來發送，如果這些數據包被負載均衡器發送到了不同的機器。那怎麼搞？
方案：負載均衡器看來必須得維護一個表，這個表需要記錄下客戶端的數據包被轉發到了哪個真實的服務器上，這樣當下一個數據包到來時，就把它轉發到同一個服務器上去。------這個負載均衡軟件需要是面向連接的，可以稱爲四層負載均衡。
4、責任分離
負載均衡器存在的瓶頸：所有流量都要通過它，它要修改客戶發來的數據包，還需要修改發給客戶的數據包。
（我想想，既然如此的話，能否讓那些真實的服務器去修改數據包？不過這些真實的服務器應該不知道負載均衡器的外網IP地址。其實可以直接讓這些真實的服務器去響應給客戶端。不過這樣可能存在安全隱患吧。）
且看真正的處理方案：
a、首先讓所有的服務器都有同一個IP，把他稱爲VIP:
b、此時每個實際服務器的loopback都綁定了那個VIP，但是這麼多服務器都有同樣的IP，當IP數據包來的時候，到底由哪個服務器來處理呢？且看下面的IP數據包的圖：圖中的問號是目的地的MAC地址（可以使用ARP協議），而將VIP這個IP地址廣播出去後，具有此IP機器就會回覆自己的MAC地址，但是現在有好幾臺機器都有這個IP地址，要怎麼辦？只讓LB響應這個VIP地址的ARP請求，而RS1、RS2、RS3則抑制對這個VIP地址的ARP響應。
既然LB得到了這個IP數據包，就可以使用某個策略從真實的服務器中選取一個服務器，把IP數據報原封不動直接轉發就可以了。
而服務器處理完了以後，由真實服務器直接響應發會給客戶端，完全不用再通過LB，而對於客戶端來說，看到的還是那個ip地址。此時數據的流向就是：
