筆者曾供職於華為，三星，騰訊，是一個資深碼農，歡迎大家

關注我，歡迎評論轉發

過程描述

當用戶向服務器發起請求時，請求首先被集群調度者截獲；調度者根據某種分配策略，選擇一臺服務器，並將選中的服務器的IP地址封裝在HTTP響應消息頭部的Location字段中，並將響應消息的狀態碼設為302，最後將這個響應消息返回給瀏覽器。

當瀏覽器收到響應消息後，解析Location字段，並向該URL發起請求，然後指定的服務器處理該用戶的請求，最後將結果返回給用戶。

在使用HTTP重定向來實現服務器集群負載均衡的過程中，需要一臺服務器作為請求調度者。用戶的一項操作需要發起兩次HTTP請求，一次向調度服務器發送請求，獲取後端服務器的IP，第二次向後端服務器發送請求，獲取處理結果。

調度策略

調度服務器收到用戶的請求後，究竟選擇哪臺後端服務器處理請求，這由調度服務器所使用的調度策略決定。

1. 隨機分配策略
2. 當調度服務器收到用戶請求後，可以隨機決定使用哪臺後端服務器，然後將該服務器的IP封裝在HTTP響應消息的Location屬性中，返回給瀏覽器即可。
3. 輪詢策略(RR)
4. 調度服務器需要維護一個值，用於記錄上次分配的後端服務器的IP。那麼當新的請求到來時，調度者將請求依次分配給下一臺服務器。

由於輪詢策略需要調度者維護一個值用於記錄上次分配的服務器IP，因此需要額外的開銷；此外，由於這個值屬於互斥資源，那麼當多個請求同時到來時，為了避免線程的安全問題，因此需要鎖定互斥資源，從而降低了性能。而隨機分配策略不需要維護額外的值，也就不存在線程安全問題，因此性能比輪詢要高。

優缺點分析

採用HTTP重定向來實現服務器集群的負載均衡實現起來較為容易，邏輯比較簡單，但缺點也較為明顯。

在HTTP重定向方法中，調度服務器只在客戶端第一次向網站發起請求的時候起作用。當調度服務器向瀏覽器返回響應信息後，客戶端此後的操作都基於新的URL進行的(也就是後端服務器)，此後瀏覽器就不會與調度服務器產生關係，進而會產生如下幾個問題：

• 由於不同用戶的訪問時間、訪問頁面深度有所不同，從而每個用戶對各自的後端服務器所造成的壓力也不同。而調度服務器在調度時，無法知道當前用戶將會對服務器造成多大的壓力，因此這種方式無法實現真正意義上的負載均衡，只不過是把請求次數平均分配給每臺服務器罷了。
• 若分配給該用戶的後端服務器出現故障，並且如果頁面被瀏覽器緩存，那麼當用戶再次訪問網站時，請求都會發給出現故障的服務器，從而導致訪問失敗。