負載均衡原理與技術實現
負載均衡(Load Balance，簡稱LB)是一種服務器或網絡設備的集羣技術。負載均衡將特定的業務(網絡服務、網絡流量等)分擔給多個服務器或網絡設備，從而提高了業務處理能力，保證了業務的高可用性。
（一）HTTP重定向實現負載均衡
當用戶向服務器發起請求時，請求首先被集羣調度者截獲；調度者根據某種分配策略，選擇一臺服務器，並將選中的服務器的IP地址封裝在HTTP響應消息頭部的Location字段中，並將響應消息的狀態碼設爲302，最後將這個響應消息返回給瀏覽器。
當瀏覽器收到響應消息後，解析Location字段，並向該URL發起請求，然後指定的服務器處理該用戶的請求，最後將結果返回給用戶。
在使用HTTP重定向來實現服務器集羣負載均衡的過程中，需要一臺服務器作爲請求調度者。用戶的一項操作需要發起兩次HTTP請求，一次向調度服務器發送請求，獲取後端服務器的IP，第二次向後端服務器發送請求，獲取處理結果。
調度服務器收到用戶的請求後，究竟選擇哪臺後端服務器處理請求，這由調度服務器所使用的調度策略決定。
- 隨機分配策略
當調度服務器收到用戶請求後，可以隨機決定使用哪臺後端服務器，然後將該服務器的IP封裝在HTTP響應消息的Location屬性中，返回給瀏覽器即可。 - 輪詢策略(RR)
調度服務器需要維護一個值，用於記錄上次分配的後端服務器的IP。那麼當新的請求到來時，調度者將請求依次分配給下一臺服務器。
由於輪詢策略需要調度者維護一個值用於記錄上次分配的服務器IP，因此需要額外的開銷；此外，由於這個值屬於互斥資源，那麼當多個請求同時到來時，爲了避免線程的安全問題，因此需要鎖定互斥資源，從而降低了性能。而隨機分配策略不需要維護額外的值，也就不存在線程安全問題，因此性能比輪詢要高。
優缺點分析
採用HTTP重定向來實現服務器集羣的負載均衡實現起來較爲容易，邏輯比較簡單，但缺點也較爲明顯。
在HTTP重定向方法中，調度服務器只在客戶端第一次向網站發起請求的時候起作用。當調度服務器向瀏覽器返回響應信息後，客戶端此後的操作都基於新的URL進行的(也就是後端服務器)，此後瀏覽器就不會與調度服務器產生關係，進而會產生如下幾個問題：
- 由於不同用戶的訪問時間、訪問頁面深度有所不同，從而每個用戶對各自的後端服務器所造成的壓力也不同。而調度服務器在調度時，無法知道當前用戶將會對服務器造成多大的壓力，因此這種方式無法實現真正意義上的負載均衡，只不過是把請求次數平均分配給每臺服務器罷了。
- 若分配給該用戶的後端服務器出現故障，並且如果頁面被瀏覽器緩存，那麼當用戶再次訪問網站時，請求都會發給出現故障的服務器，從而導致訪問失敗。
（二）DNS負載均衡
我們提交的請求不會直接發送給想要訪問的網站，而是首先發給域名服務器，它會幫我們把域名解析成IP地址並返回給我們。我們收到IP之後纔會向該IP發起請求。
那麼，DNS服務器有一個天然的優勢，如果一個域名指向了多個IP地址，那麼每次進行域名解析時，DNS只要選一個IP返回給用戶，就能夠實現服務器集羣的負載均衡。
一般DNS提供商會提供一些調度策略供我們選擇，如隨機分配、輪詢、根據請求者的地域分配離他最近的服務器。
優缺點分析
DNS負載均衡最大的優點就是配置簡單。服務器集羣的調度工作完全由DNS服務器承擔，那麼我們就可以把精力放在後端服務器上，保證他們的穩定性與吞吐量。而且完全不用擔心DNS服務器的性能，即便是使用了輪詢策略，它的吞吐率依然卓越。
此外，DNS負載均衡具有較強了擴展性，你完全可以爲一個域名解析較多的IP，而且不用擔心性能問題。
但是，由於把集羣調度權交給了DNS服務器，從而我們沒辦法隨心所欲地控制調度者，沒辦法定製調度策略。
DNS服務器也沒辦法瞭解每臺服務器的負載情況，因此沒辦法實現真正意義上的負載均衡。它和HTTP重定向一樣，只不過把所有請求平均分配給後端服務器罷了。
此外，當我們發現某一臺後端服務器發生故障時，即使我們立即將該服務器從域名解析中去除，但由於DNS服務器會有緩存，該IP仍然會在DNS中保留一段時間，那麼就會導致一部分用戶無法正常訪問網站。這是一個致命的問題！好在這個問題可以用動態DNS來解決。
動態DNS能夠讓我們通過程序動態修改DNS服務器中的域名解析。從而當我們的監控程序發現某臺服務器掛了之後，能立即通知DNS將其刪掉。
綜上：DNS是一種粗獷的負載均衡方法，一般不推薦使用
（三）反向代理負載均衡
反向代理服務器是一個位於實際服務器之前的服務器，所有向我們網站發來的請求都首先要經過反向代理服務器，服務器根據用戶的請求要麼直接將結果返回給用戶，要麼將請求交給後端服務器處理，再返回給用戶。
用反向代理服務器可以實現靜態頁面和常用的動態頁面的緩存。
我們知道，所有發送給我們網站的請求都首先經過反向代理服務器。那麼，反向代理服務器就可以充當服務器集羣的調度者，它可以根據當前後端服務器的負載情況，將請求轉發給一臺合適的服務器，並將處理結果返回給用戶。
優點
- 隱藏後端服務器。
與HTTP重定向相比，反向代理能夠隱藏後端服務器，所有瀏覽器都不會與後端服務器直接交互，從而能夠確保調度者的控制權，提升集羣的整體性能。 - 故障轉移
與DNS負載均衡相比，反向代理能夠更快速地移除故障結點。當監控程序發現某一後端服務器出現故障時，能夠及時通知反向代理服務器，並立即將其刪除。 - 合理分配任務
HTTP重定向和DNS負載均衡都無法實現真正意義上的負載均衡，也就是調度服務器無法根據後端服務器的實際負載情況分配任務。但反向代理服務器支持手動設定每臺後端服務器的權重。我們可以根據服務器的配置設置不同的權重，權重的不同會導致被調度者選中的概率的不同。或者使用IP/Url Hash的方法。
缺點
- 調度者壓力過大
由於所有的請求都先由反向代理服務器處理，那麼當請求量超過調度服務器的最大負載時，調度服務器的吞吐率降低會直接降低集羣的整體性能。 - 制約擴展
當後端服務器也無法滿足巨大的吞吐量時，就需要增加後端服務器的數量，可沒辦法無限量地增加，因爲會受到調度服務器的最大吞吐量的制約。
常用負載均衡開源軟件有nginx、lvs、haproxy，商業的硬件負載均衡設備F5、Netscale
LVS是 Linux Virtual Server 的簡稱，也就是Linux虛擬服務器。
Nginx+keepalive實現主備：防止唯一的nginx宕機導致系統停止
Keepalived的作用是檢測服務器的狀態，如果有一臺web服務器宕機，或工作出現故障，Keepalived將檢測到，並將有故障的服務器從系統中剔除，同時使用其他服務器代替該服務器的工作，當服務器工作正常後Keepalived自動將服務器加入到服務器羣中，這些工作全部自動完成，不需要人工干涉，需要人工做的只是修復故障的服務器。
Keepalived原理分別如下：
網絡層：Keepalived使用網絡層的方式工作時，Keepalived會定期向服務器羣中的服務器發送一個ICMP的數據包（既我們平時用的Ping程序）,如果發現某臺服務的IP地址沒有激活，Keepalived便報告這臺服務器失效，並將它從服務器羣中剔除，這種情況的典型例子是某臺服務器被非法關機。網絡層的方式是以服務器的IP地址是否有效作爲服務器工作正常與否的標準。
傳輸層：如果您理解了網絡層的方式，傳輸就容易了。傳輸主要以TCP端口的狀態來決定服務器工作正常與否。如web server的服務端口一般是80，如果Keepalived檢測到80端口沒有啓動，則Keepalived將把這臺服務器從服務器羣中剔除。
雙機熱備
1、一臺master、一臺backup(slave)，master掛了backup自動補上去
2、135用master、246用backup，週末休息
3、兩臺Load Balancer都作爲master，分別爲不同的業務做負載均衡，並且同時設置爲對方的slave，即可靠，又不浪費資源