最近幾年，中國的互聯網高速發展，現在我國的互聯網用戶已達到6.68億。網絡瀏覽和使用需求的攀升，導致了網站的訪問量和數據流量也大幅度的增加，對於網站服務器的計算處理能力提出了更高的要求。那麼網絡服務器負載均衡原理是什麼？以下僅供參考！
一、http重定向
當http代理（比如瀏覽器）向web服務器請求某個URL後，web服務器可以通過http響應頭信息中的Location標記來返回一個新的URL。這意味着HTTP代理需要繼續請求這個新的URL，完成自動跳轉。
性能缺陷：
1、吞吐率限制
主站點服務器的吞吐率平均分配到了被轉移的服務器。現假設使用RR（Round Robin）調度策略，子服務器的最大吞吐率爲1000reqs/s，那麼主服務器的吞吐率要達到3000reqs/s才能完全發揮三臺子服務器的作用，那麼如果有100臺子服務器，那麼主服務器的吞吐率可想而知得有大？相反，如果主服務的最大吞吐率爲6000reqs/s，那麼平均分配到子服務器的吞吐率爲2000reqs/s，而現子服務器的最大吞吐率爲1000reqs/s，因此就得增加子服務器的數量，增加到6個才能滿足。
2、重定向訪問深度不同
有的重定向一個靜態頁面，有的重定向相比複雜的動態頁面，那麼實際服務器的負載差異是不可預料的，而主站服務器卻一無所知。因此整站使用重定向方法做負載均衡不太好。
我們需要權衡轉移請求的開銷和處理實際請求的開銷，前者相對於後者越小，那麼重定向的意義就越大，例如下載。你可以去很多鏡像下載網站試下，會發現基本下載都使用了Location做了重定向。
二、DNS負載均衡
DNS負責提供域名解析服務，當訪問某個站點時，實際上首先需要通過該站點域名的DNS服務器來獲取域名指向的IP地址，在這一過程中，DNS服務器完成了域名到IP地址的映射，同樣，這樣映射也可以是一對多的，這時候，DNS服務器便充當了負載均衡調度器，它就像http重定向轉換策略一樣，將用戶的請求分散到多臺服務器上，但是它的實現機制完全不同。
使用dig命令來看下”baidu”的DNS設置
可見baidu擁有三個A記錄
相比http重定向，基於DNS的負載均衡完全節省了所謂的主站點，或者說DNS服務器已經充當了主站點的職能。但不同的是，作爲調度器，DNS服務器本身的性能幾乎不用擔心。因爲DNS記錄可以被用戶瀏覽器或者互聯網接入服務商的各級DNS服務器緩存，只有當緩存過期後纔會重新向域名的DNS服務器請求解析。也說是DNS不存在http的'吞吐率限制，理論上可以無限增加實際服務器的數量。
特性:
1、可以根據用戶IP來進行智能解析。DNS服務器可以在所有可用的A記錄中尋找離用記最近的一臺服務器。
2、動態DNS：在每次IP地址變更時，及時更新DNS服務器。當然，因爲緩存，一定的延遲不可避免。
不足：
1、沒有用戶能直接看到DNS解析到了哪一臺實際服務器，加服務器運維人員的調試帶來了不便。
2、策略的侷限性。例如你無法將HTTP請求的上下文引入到調度策略中，而在前面介紹的基於HTTP重定向的負載均衡系統中，調度器工作在HTTP層面，它可以充分理解HTTP請求後根據站點的應用邏輯來設計調度策略，比如根據請求不同的URL來進行合理的過濾和轉移。
3、如果要根據實際服務器的實時負載差異來調整調度策略，這需要DNS服務器在每次解析操作時分析各服務器的健康狀態，對於DNS服務器來說，這種自定義開發存在較高的門檻，更何況大多數站點只是使用第三方DNS服務。
4、DNS記錄緩存，各級節點的DNS服務器不同程序的緩存會讓你暈頭轉向。
5、基於以上幾點，DNS服務器並不能很好地完成工作量均衡分配，最後，是否選擇基於DNS的負載均衡方式完全取決於你的需要。
三、反向代理負載均衡
這個肯定大家都有所接觸，因爲幾乎所有主流的Web服務器都熱衷於支持基於反向代理的負載均衡。它的核心工作就是轉發HTTP請求。
相比前面的HTTP重定向和DNS解析，反向代理的調度器扮演的是用戶和實際服務器中間人的角色：
1、任何對於實際服務器的HTTP請求都必須經過調度器
2、調度器必須等待實際服務器的HTTP響應，並將它反饋給用戶（前兩種方式不需要經過調度反饋，是實際服務器直接發送給用戶）
特性：
1、調度策略豐富。例如可以爲不同的實際服務器設置不同的權重，以達到能者多勞的效果。
2、對反向代理服務器的併發處理能力要求高，因爲它工作在HTTP層面。
3、反向代理服務器進行轉發操作本身是需要一定開銷的，比如創建線程、與後端服務器建立TCP連接、接收後端服務器返回的處理結果、分析HTTP頭部信息、用戶空間和內核空間的頻繁切換等，雖然這部分時間並不長，但是當後端服務器處理請求的時間非常短時，轉發的開銷就顯得尤爲突出。例如請求靜態文件，更適合使用前面介紹的基於DNS的負載均衡方式。
4、反向代理服務器可以監控後端服務器，比如系統負載、響應時間、是否可用、TCP連接數、流量等，從而根據這些數據調整負載均衡的策略。
5、反射代理服務器可以讓用戶在一次會話週期內的所有請求始終轉發到一臺特定的後端服務器上（粘滯會話），這樣的好處一是保持session的本地訪問，二是防止後端服務器的動態內存緩存的資源浪費。
四、IP負載均衡(LVS-NAT)
因爲反向代理服務器工作在HTTP層，其本身的開銷就已經嚴重製約了可擴展性，從而也限制了它的性能極限。那能否在HTTP層面以下實現負載均衡呢？
NAT服務器:它工作在傳輸層，它可以修改發送來的IP數據包，將數據包的目標地址修改爲實際服務器地址。
從Linux2.4內核開始，其內置的Neftilter模塊在內核中維護着一些數據包過濾表，這些表包含了用於控制數據包過濾的規則。可喜的是，Linux提供了iptables來對過濾表進行插入、修改和刪除等操作。更加令人振奮的是，Linux2.6.x內核中內置了IPVS模塊，它的工作性質類型於Netfilter模塊，不過它更專注於實現IP負載均衡。
想知道你的服務器內核是否已經安裝了IPVS模塊，可以
有輸出意味着IPVS已經安裝了。IPVS的管理工具是ipvsadm，它爲提供了基於命令行的配置界面，可以通過它快速實現負載均衡系統。這就是大名鼎鼎的LVS(Linux Virtual Server，Linux虛擬服務器)。
1、打開調度器的數據包轉發選項
echo 1 > /proc/sys/net/ipv4/ip_forward
2、檢查實際服務器是否已經將NAT服務器作爲自己的默認網關，如果不是，如添加
route add default gw
3、使用ipvsadm配置
ipvsadm -A -t -s rr
添加一臺虛擬服務器，-t 後面是服務器的外網ip和端口，-s rr是指採用簡單輪詢的RR調度策略（這屬於靜態調度策略，除此之外，LVS還提供了系列的動態調度策略，比如最小連接（LC）、帶權重的最小連接（WLC），最短期望時間延遲（SED）等）
ipvsadm -a -t -r -m
ipvsadm -a -t -r -m
添加兩臺實際服務器（不需要有外網ip），-r後面是實際服務器的內網ip和端口，-m表示採用NAT方式來轉發數據包
運行ipvsadm -L -n可以查看實際服務器的狀態。這樣就大功告成了。
實驗證明使用基於NAT的負載均衡系統。作爲調度器的NAT服務器可以將吞吐率提升到一個新的高度，幾乎是反向代理服務器的兩倍以上，這大多歸功於在內核中進行請求轉發的較低開銷。但是一旦請求的內容過大時，不論是基於反向代理還是NAT，負載均衡的整體吞吐量都差距不大，這說明對於一睦開銷較大的內容，使用簡單的反向代理來搭建負載均衡系統是值考慮的。
這麼強大的系統還是有它的瓶頸，那就是NAT服務器的網絡帶寬，包括內部網絡和外部網絡。當然如果你不差錢，可以去花錢去購買千兆交換機或萬兆交換機，甚至負載均衡硬件設備。
一個簡單有效的辦法就是將基於NAT的集羣和前面的DNS混合使用，比如５個100Mbps出口寬帶的集羣，然後通過DNS來將用戶請求均衡地指向這些集羣，同時，你還可以利用DNS智能解析實現地域就近訪問。這樣的配置對於大多數業務是足夠了，但是對於提供下載或視頻等服務的大規模站點，NAT服務器還是不夠出色。
五、直接路由(LVS-DR)
NAT是工作在網絡分層模型的傳輸層（第四層），而直接路由是工作在數據鏈路層（第二層），貌似更厲害些。它通過修改數據包的目標MAC地址（沒有修改目標IP），將數據包轉發到實際服務器上，不同的是，實際服務器的響應數據包將直接發送給客戶羰，而不經過調度器。
1、網絡設置
這裏假設一臺負載均衡調度器，兩臺實際服務器，購買三個外網ip，一臺機一個，三臺機的默認網關需要相同，最後再設置同樣的ip別名，這裏假設別名爲。這樣一來，將通過這個IP別名來訪問調度器，你可以將站點的域名指向這個IP別名。
