當一台伺服器的效能達到極限時，我們可以使用伺服器集群來提高**的整體效能。那麼，在伺服器集群中，需要有一台伺服器充當排程者的角色，使用者的所有請求都會首先由它接收，排程者再根據每台伺服器的負載情況將請求分配給某一台後端伺服器去處理。
那麼在這個過程中，排程者如何合理分配任務，保證所有後端伺服器都將效能充分發揮，從而保持伺服器集群的整體效能最優，這就是負載均衡問題。
下面詳細介紹負載均衡的四種實現方式
過程描述
當使用者向伺服器發起請求時，請求首先被集群排程者截獲；排程者根據某種分配策略，選擇一台伺服器，並將選中的伺服器的ip位址封裝在http響應訊息頭部的location欄位中，並將響應訊息的狀態碼設為302，最後將這個響應訊息返回給瀏覽器。
當瀏覽器收到響應訊息後，解析location欄位，並向該url發起請求，然後指定的伺服器處理該使用者的請求，最後將結果返回給使用者。
在使用http重定向來實現伺服器集群負載均衡的過程中，需要一台伺服器作為請求排程者。使用者的一項操作需要發起兩次http請求，一次向排程伺服器傳送請求，獲取後端伺服器的ip，第二次向後端伺服器傳送請求，獲取處理結果。
排程策略
優缺點分析
採用http重定向來實現伺服器集群的負載均衡實現起來較為容易，邏輯比較簡單，但缺點也較為明顯。
在http重定向方法中，排程伺服器只在客戶端第一次向**發起請求的時候起作用。當排程伺服器向瀏覽器返回響應資訊後，客戶端此後的操作都基於新的url進行的(也就是後端伺服器)，此後瀏覽器就不會與排程伺服器產生關係，進而會產生如下幾個問題：
由於不同使用者的訪問時間、訪問頁面深度有所不同，從而每個使用者對各自的後端伺服器所造成的壓力也不同。而排程伺服器在排程時，無法知道當前使用者將會對伺服器造成多大的壓力，因此這種方式無法實現真正意義上的負載均衡，只不過是把請求次數平均分配給每台伺服器罷了。
若分配給該使用者的後端伺服器出現故障，並且如果頁面被瀏覽器快取，那麼當使用者再次訪問**時，請求都會發給出現故障的伺服器，從而導致訪問失敗
dns是什麼
在了解dns負載均衡之前，我們首先需要了解dns網域名稱解析的過程。
我們知道，資料報採用ip位址在網路中傳播，而為了方便使用者記憶，我們使用網域名稱來訪問**。那麼，我們通過網域名稱訪問**之前，首先需要將網域名稱解析成ip位址，這個工作是由dns完成的。也就是網域名稱伺服器。
我們提交的請求不會直接傳送給想要訪問的**，而是首先發給網域名稱伺服器，它會幫我們把網域名稱解析成ip位址並返回給我們。我們收到ip之後才會向該ip發起請求。
那麼，dns伺服器有乙個天然的優勢，如果乙個網域名稱指向了多個ip位址，那麼每次進行網域名稱解析時，dns只要選乙個ip返回給使用者，就能夠實現伺服器集群的負載均衡。
具體做法
首先需要將我們的網域名稱指向多個後端伺服器(將乙個網域名稱解析到多個ip上)，再設定一下排程策略，那麼我們的準備工作就完成了，接下來的負載均衡就完全由dns伺服器來實現。
當使用者向我們的網域名稱發起請求時，dns伺服器會自動地根據我們事先設定好的排程策略選乙個合適的ip返回給使用者，使用者再向該ip發起請求。
排程策略
一般dns提供商會提供一些排程策略供我們選擇，如隨機分配、輪詢、根據請求者的地域分配離他最近的伺服器。
優缺點分析
dns負載均衡最大的優點就是配置簡單。伺服器集群的排程工作完全由dns伺服器承擔，那麼我們就可以把精力放在後端伺服器上，保證他們的穩定性與吞吐量。而且完全不用擔心dns伺服器的效能，即便是使用了輪詢策略，它的吞吐率依然卓越。
此外，dns負載均衡具有較強了擴充套件性，你完全可以為乙個網域名稱解析較多的ip，而且不用擔心效能問題。
但是，由於把集群排程權交給了dns伺服器，從而我們沒辦法隨心所欲地控制排程者，沒辦法定製排程策略。
dns伺服器也沒辦法了解每台伺服器的負載情況，因此沒辦法實現真正意義上的負載均衡。它和http重定向一樣，只不過把所有請求平均分配給後端伺服器罷了。
此外，當我們發現某一台後端伺服器發生故障時，即使我們立即將該伺服器從網域名稱解析中去除，但由於dns伺服器會有快取，該ip仍然會在dns中保留一段時間，那麼就會導致一部分使用者無法正常訪問**。這是乙個致命的問題！好在這個問題可以用動態dns來解決。
動態dns
動態dns能夠讓我們通過程式動態修改dns伺服器中的網域名稱解析。從而當我們的監控程式發現某台伺服器掛了之後，能立即通知dns將其刪掉。
綜上所述
dns負載均衡是一種粗獷的負載均衡方法，這裡只做介紹，不推薦使用。
什麼是反向**負載均衡？
反向**伺服器是乙個位於實際伺服器之前的伺服器，所有向我們**發來的請求都首先要經過反向**伺服器，伺服器根據使用者的請求要麼直接將結果返回給使用者，要麼將請求交給後端伺服器處理，再返回給使用者。
之前我們介紹了用反向**伺服器實現靜態頁面和常用的動態頁面的快取。接下來我們介紹反向**伺服器更常用的功能——實現負載均衡。
我們知道，所有傳送給我們**的請求都首先經過反向**伺服器。那麼，反向**伺服器就可以充當伺服器集群的排程者，它可以根據當前後端伺服器的負載情況，將請求**給一台合適的伺服器，並將處理結果返回給使用者。
優點缺點
排程者壓力過大
由於所有的請求都先由反向**伺服器處理，那麼當請求量超過排程伺服器的最大負載時，排程伺服器的吞吐率降低會直接降低集群的整體效能。
制約擴充套件
當後端伺服器也無法滿足巨大的吞吐量時，就需要增加後端伺服器的數量，可沒辦法無限量地增加，因為會受到排程伺服器的最大吞吐量的制約。
粘滯會話
反向**伺服器會引起乙個問題。若某台後端伺服器處理了使用者的請求，並儲存了該使用者的session或儲存了快取，那麼當該使用者再次傳送請求時，無法保證該請求仍然由儲存了其session或快取的伺服器處理，若由其他伺服器處理，先前的session或快取就找不到了。
解決辦法1：
可以修改反向**伺服器的任務分配策略，以使用者ip作為標識較為合適。相同的使用者ip會交由同一台後端伺服器處理，從而就避免了粘滯會話的問題。
解決辦法2：
可以在cookie中標註請求的伺服器id，當再次提交請求時，排程者將該請求分配給cookie中標註的伺服器處理即可。
django 高併發解決方案 負載均衡
1.什麼是負載均衡？當一台伺服器的效能達到極限時，我們可以使用伺服器集群來提高 的整體效能。那麼，在伺服器集群中，需要有一台伺服器充當排程者的角色，使用者的所有請求都會首先由它接收，排程者再根據每台伺服器的負載情況將請求分配給某一台後端伺服器去處理。那麼在這個過程中，排程者如何合理分配任務，保證所有...
04 高併發負載均衡 LVS
路由器 三層，只關心ip和路由表 lvs伺服器 四層，只關心port，狀態 nginx 七層，只關心socket對應關係 dip rip client的資料報到rip上 隱藏vip cip動態排程方法 預設方法 wlc 修改 e 刪除 d t u f service address ipvsadm ...
高併發負載均衡 nginx與lvs
客戶端通過企業防火牆傳送請求 伺服器通過訪問資料庫進行互動，同樣高併發大資料會涉及到資料庫處理高併發的方案 另外會新增多台伺服器用作快取 訊息處理等 1 高併發一般會發生在下面兩處 負載均衡處 資料庫高併發 2 高併發初期解決方案 應對高併發，解決方案大多從伺服器級別和應用程式級別 硬體和軟體 兩個...