- 能夠徹底的掌握什麼是負載均衡，以及爲什麼要使用負載均衡。
- 能夠清楚的理解實現負載均衡的三種方式，以及每種方式的優缺點
一、什麼是負載均衡？爲什麼要使用負載均衡？
首先來看一下百度百科上對於負載均衡的介紹。
負載均衡：建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。
這樣籠統來看，我想有很多人都看不明白，那麼下面我將用大白話給大家介紹一下到底什麼是負載均衡，如果介紹的不好，還請大家見諒。
現在網站的架構已經從C/S模式轉變爲B/S模式，對於這兩種模式的區別，大家沒必要糾結，有興趣的同學可以給我留言，我會在後面爲大家講解，現在只需要知道C/S模式是有一個專門的客戶端，而B/S模式是將瀏覽器作爲客戶端。當用戶在瀏覽器上輸入一個網址按下回車鍵後，就會產生一個請求，在遠方的服務器會處理這個請求，根據這個請求來生成用戶想要的頁面，然後將這個頁面響應給瀏覽器，這樣用戶就能看到他想要看到的東西。我們知道，一臺服務器處理數據（請求也是一種數據）的能力是有限的，當有大量的用戶同時在瀏覽器上輸入網址並按下回車鍵後，就會有大量的請求產生，遠方的服務器就不得不處理這些請求，由於請求數量過多，服務器處理的效率就會變慢，響應時間就會變長，這樣用戶就不能在可以忍受的時間內看到自己想看到的東西，嚴重影響體驗效果。更嚴重一點，如果請求數量超過了這臺服務器所能處理的最大請求，服務器就會崩潰，直接導致網站癱瘓。
那麼，有什麼方法能夠解決這個問題呢？答案就是建立一個集羣（就是一羣服務器），通過集羣的力量來提高服務端的數據處理能力，因爲一臺服務器的處理能力肯定比不上多臺服務器的處理能力。
這樣我們在來描述一下用戶請求頁面的過程：首先用戶在瀏覽器輸入網址並按下回車鍵，然後會產生一個請求，遠方的服務器會處理這個請求......等等，現在遠方有很多服務器，到底哪個服務器來處理這個請求呢，總不能所有的服務器都處理這個請求吧。哪個服務器處理這個請求？大家明白了吧，這就是負載均衡所要解決的問題。回到上邊請求頁面的過程，這個請求此時會被一臺專門的服務器來處理，這臺服務器其實就是個集羣的老大，他負責把這個請求派給下面哪個小弟（服務器）來處理，處理完之後返回頁面用戶。當有多個請求同時發生時，集羣的老大可以將請求派給不同的小弟，這樣處理的效率就會大幅提升，充分發揮集羣的力量，至於哪個請求到底派給哪個小弟，這就是調度策略的問題了。
好了，到現在大家應該都明白什麼是負載均衡了，爲了讓大家印象更加深刻，大家可以看一下下面的圖，便於理解記憶。
負載均衡
二、實現負載均衡的三種方式
1、HTTP重定向實現負載均衡
請求過程：
當用戶向服務器發起請求時，請求首先被集羣調度者（集羣老大）截獲；調度者根據某種分配策略，選擇一臺服務器（小弟），並將選中的服務器的IP地址封裝在HTTP響應消息頭部的Location字段中，並將響應消息的狀態碼設爲302，最後將這個響應消息返回給瀏覽器。
當瀏覽器收到響應消息後，解析Location字段，並向該URL發起請求，然後指定的服務器處理該用戶的請求，最後將結果返回給用戶。
在使用HTTP重定向來實現服務器集羣負載均衡的過程中，需要一臺服務器作爲請求調度者。用戶的一項操作需要發起兩次HTTP請求，一次向調度服務器發送請求，獲取後端服務器的IP，第二次向後端服務器發送請求，獲取處理結果。
HTTP重定向實現負載均衡
優點：採用HTTP重定向來實現服務器集羣的負載均衡實現起來較爲容易，邏輯比較簡單。
缺點：在HTTP重定向方法中，調度服務器只在客戶端第一次向網站發起請求的時候起作用。當調度服務器向瀏覽器返回響應信息後，客戶端此後的操作都基於新的URL進行的(也就是後端服務器)，此後瀏覽器就不會與調度服務器產生關係，進而會產生如下幾個問題：
- 由於不同用戶的訪問時間、訪問頁面深度有所不同，從而每個用戶對各自的後端服務器所造成的壓力也不同。而調度服務器在調度時，無法知道當前用戶將會對服務器造成多大的壓力，因此這種方式無法實現真正意義上的負載均衡，只不過是把請求次數平均分配給每臺服務器罷了。
- 若分配給該用戶的後端服務器出現故障，並且如果頁面被瀏覽器緩存，那麼當用戶再次訪問網站時，請求都會發給出現故障的服務器，從而導致訪問失敗。
2、DNS負載均衡
首先我們要了解一下什麼是DNS?
DNS的全拼是Domain Name System，中文也叫做域名服務器，是負責將域名解析成IP地址的，例如將www.baidu.com這個域名解析成了115.239.211.112，我們訪問www.baidu.com時其實訪問的是115.239.211.112這臺服務器。
請求過程：
當用戶向我們的域名發起請求時，DNS服務器會自動地根據我們事先設定好的調度策略選一個合適的IP返回給用戶，用戶再向該IP發起請求。
DNS負載均衡
優點：
- DNS負載均衡最大的優點就是配置簡單。服務器集羣的調度工作完全由DNS服務器承擔，那麼我們就可以把精力放在後端服務器上，保證他們的穩定性與吞吐量。而且完全不用擔心DNS服務器的性能，即便是使用了輪詢策略，它的吞吐率依然卓越。
- DNS負載均衡具有較強了擴展性，你完全可以爲一個域名解析較多的IP，而且不用擔心性能問題。
缺點：
- 由於把集羣調度權交給了DNS服務器，從而我們沒辦法隨心所欲地控制調度者，沒辦法定製調度策略。
- DNS服務器也沒辦法瞭解每臺服務器的負載情況，因此沒辦法實現真正意義上的負載均衡。它和HTTP重定向一樣，只不過把所有請求平均分配給後端服務器罷了。
- 當我們發現某一臺後端服務器發生故障時，即使我們立即將該服務器從域名解析中去除，但由於DNS服務器會有緩存，該IP仍然會在DNS中保留一段時間，那麼就會導致一部分用戶無法正常訪問網站（可以用動態 DNS來解決）。
3、反向代理負載均衡
請求過程：
用戶發來的請求都首先要經過反向代理服務器，服務器根據用戶的請求要麼直接將結果返回給用戶，要麼將請求交給後端服務器處理，再返回給用戶。
反向代理負載均衡
優點：
- 隱藏後端服務器。與HTTP重定向相比，反向代理能夠隱藏後端服務器，所有瀏覽器都不會與後端服務器直接交互，從而能夠確保調度者的控制權，提升集羣的整體性能。
- 故障轉移。與DNS負載均衡相比，反向代理能夠更快速地移除故障結點。當監控程序發現某一後端服務器出現故障時，能夠及時通知反向代理服務器，並立即將其刪除。
- 合理分配任務 。HTTP重定向和DNS負載均衡都無法實現真正意義上的負載均衡，也就是調度服務器無法根據後端服務器的實際負載情況分配任務。但反向代理服務器支持手動設定每臺後端服務器的權重。我們可以根據服務器的配置設置不同的權重，權重的不同會導致被調度者選中的概率的不同。
缺點：
- 調度者壓力過大 。由於所有的請求都先由反向代理服務器處理，那麼當請求量超過調度服務器的最大負載時，調度服務器的吞吐率降低會直接降低集羣的整體性能。
- 制約擴展。當後端服務器也無法滿足巨大的吞吐量時，就需要增加後端服務器的數量，可沒辦法無限量地增加，因爲會受到調度服務器的最大吞吐量的制約。
負載均衡的介紹到此結束，希望能夠對大家有所幫助。最後，請大家多多關注，程序猿大隊長會每天給大家分享知識，與大家共同成長。