轉自：http://www.cnblogs.com/chanshuyi/p/how-loadbalance-works.html

在網際網路+不斷滲透到生活中的今天，各種各樣的網路服務存在在我們身邊，他們的訪問流量也是大得驚人。一個大型網站（百萬PV以上）想要正常訪問，單單靠一臺伺服器是不可能提供穩定服務的。這時候就需要用負載均衡技術將海量的介面請求平均分發到各個伺服器上，以減少每臺伺服器的壓力。

上面的流程圖展示了從使用者請求和響應的整個路程。使用者按下一個按鈕，一個請求通過網路轉發到運營商網路，運營商對其進行DNS解析。如果請求所對應的域名配置了DNS輪詢，那麼運營商將會隨機返回域名對應的一個伺服器IP，之後將請求轉發到該伺服器上。當請求到達伺服器時，首先會達到LVS虛擬伺服器，虛擬伺服器再根據具體演算法轉發給後邊的Nginx伺服器。當Nginx接收到請求時，Nginx伺服器會根據其配置將請求再次轉發給其後端配置的應用伺服器，應用伺服器才是最終處理業務請求的地方。

在整個請求過程中，有三種負載均衡技術：第一次是DNS輪詢，第二次是LVS負載均衡，第三次是Nginx負載均衡。

DNS輪詢

DNS輪詢指的是服務提供者在運營商針對某一域名配置了多個提供服務的伺服器IP，當用戶請求改域名的介面時，運營商將隨機挑選出一個伺服器響應使用者請求。下圖的例子是：有3臺聯通伺服器、3臺電信伺服器，要實現“聯通使用者流量分攤到3臺聯通伺服器、其他使用者流量分攤到電信伺服器”這個效果的設定。

DNS由於成本較低，所以一般在小型的網站用的比較多。但是大型的網站一般也會將用它和其他負載均衡的方式結合起來一起使用，DNS輪詢方式提供的IP地址，在大型網站中往往是一個叢集的地址，可能是均衡交換機也可能是均衡伺服器。我們可以通過nslookup

C:\Users\Administrator>nslookup www.baidu.com
伺服器:  UnKnown
Address:  10.10.121.11

非權威應答:
名稱:    www.a.shifen.com
Addresses:  58.217.200.113
          58.217.200.112
Aliases:  www.baidu.com

DNS輪詢的優點是成本低、操作簡單，但是其缺點也是明顯的：

• 服務不穩定。如果某臺伺服器宕機，DNS伺服器是無法知曉的，仍舊會將訪問分配到此伺服器。修改DNS記錄全部生效一般要1-3小時，甚至更久。這就可能會導致某些使用者在伺服器發生故障的時候完全無法訪問。
• DNS負載均衡採用的是簡單的輪詢演算法，不能區分伺服器的差異，不能反映伺服器的當前執行狀態，不能做到為效能較好的伺服器多分配請求，甚至會出現客戶請求集中在某一臺伺服器上的情況。
• 登陸狀態無法儲存。如果是需要身份驗證的網站，DNS解析無法將驗證使用者的訪問持久分配到同一伺服器。雖然有一定的本地DNS快取，但是很難保證在使用者訪問期間，本地DNS不過期，而重新查詢伺服器並指向了新的伺服器，那麼原伺服器儲存的使用者資訊是無法被帶到新伺服器的，而且可能被要求重新認證身份，而且來回切換時間長了各臺伺服器都儲存有使用者不同的資訊，對伺服器資源也是一種浪費。

正是因為上述存在的缺點，所以DNS一般不會單獨使用，而是配合其他負載均衡方式一起使用。

LVS負載均衡

LVS伺服器接收到網路請求後，會根據配置的演算法將請求轉發給後邊的伺服器處理。為了實現高可用，一般情況下都會有至少兩臺LVS伺服器，它們之間用KeepAlive定時通訊。當備用LVS伺服器無法接收到主LVS伺服器的資訊時，備用LVS伺服器就認為主LVS已經宕機了，這時候備用LVS將自動切換為主LVS提供服務。

使用LVS架設的伺服器集群系統有三個部分組成：最前端的負載均衡層（Loader Balancer），中間的伺服器群組層，用Server Array表示，最底層的資料共享儲存層，用Shared Storage表示。在使用者看來所有的應用都是透明的，使用者只是在使用一個虛擬伺服器提供的高效能服務。LVS的體系架構如圖：

LVS的各個層次的詳細介紹：

• Load Balancer層：位於整個集群系統的最前端，有一臺或者多臺負載排程器（Director Server）組成，LVS模組就安裝在Director Server上，而Director的主要作用類似於一個路由器，它含有完成LVS功能所設定的路由表，通過這些路由表把使用者的請求分發給Server Array層的應用伺服器（Real Server）上。同時，在Director Server上還要安裝對Real Server服務的監控模組Ldirectord，此模組用於監測各個Real Server服務的健康狀況。在Real Server不可用時把它從LVS路由表中剔除，恢復時重新加入。

• Server Array層：由一組實際執行應用服務的機器組成，Real Server可以是WEB伺服器、MAIL伺服器、FTP伺服器、DNS伺服器、視訊伺服器中的一個或者多個，每個Real Server之間通過高速的LAN或分佈在各地的WAN相連線。在實際的應用中，Director Server也可以同時兼任Real Server的角色。

• Shared Storage層：是為所有Real Server提供共享儲存空間和內容一致性的儲存區域，在物理上，一般有磁碟陣列裝置組成，為了提供內容的一致性，一般可以通過NFS網路檔案系統共享數 據，但是NFS在繁忙的業務系統中，效能並不是很好，此時可以採用叢集檔案系統，例如Red hat的GFS檔案系統，oracle提供的OCFS2檔案系統等。
  從整個LVS結構可以看出，Director Server是整個LVS的核心，目前，用於Director Server的作業系統只能是Linux和FreeBSD，linux2.6核心不用任何設定就可以支援LVS功能，而FreeBSD作為 Director Server的應用還不是很多，效能也不是很好。對於Real Server，幾乎可以是所有的系統平臺，Linux、windows、Solaris、AIX、BSD系列都能很好的支援。

LVS 的IP負載均衡技術是通過IPVS模組來實現的，IPVS是LVS集群系統的核心軟體，它的主要作用是：安裝在Director Server上，同時在Director Server上虛擬出一個IP地址，使用者必須通過這個虛擬的IP地址訪問服務。這個虛擬IP一般稱為LVS的VIP，即Virtual IP。訪問的請求首先經過VIP到達負載排程器，然後由負載排程器從Real Server列表中選取一個服務節點響應使用者的請求。

當用戶的請求到達負載排程器後，排程器如何將請求傳送到提供服務的Real Server節點，而Real Server節點如何返回資料給使用者，是IPVS實現的重點技術，IPVS實現負載均衡機制有三種：DR模式、NAT模式、Full-NAT模式、Tunnel模式，其中DR模式是使用最廣泛的一種。

DR模式

特點：工作在資料鏈路層，由LVS修改請求報文的Mac地址，由RS伺服器直接返回響應給客戶端。

• 使用者按下按鈕，傳送介面請求，此時網路資料包關鍵資訊為：【源IP：client_ip，目標IP：lvs_ip，Mac地址：lvs_mac_address】
• 當用戶請求到達LVS伺服器的時候，LVS伺服器直接將改網路資料包的Mac地址修改為RS伺服器的Mac地址，之後將其轉發到RS伺服器。此時網路資料包關鍵資訊為：【源IP：client_ip，目標IP：lvs_ip，Mac地址：rs_mac_address】
• 當RS伺服器接收到網路資料包時，RS伺服器發現請求報文的Mac地址是自己的地址，就接收報文並進行處理。處理完成之後，將響應報文通過網絡卡向外發出。此時發出的響應報文資料包關鍵資訊為：【源IP：lvs_ip，目標IP：client_ip，Mac地址：rs_mac_address】
• 響應報文最終到達客戶端

這種方式是三種負載排程機制中效能最高最好的，但是必須要求Director Server與Real Server都有一塊網絡卡連在同一物理網段上。

NAT模式

特點：工作在網路層，由LVS修改請求報文的目標IP地址以及響應報文的源IP地址，必須經LVS返回給客戶端。

• 使用者按下按鈕，傳送介面請求，此時網路資料包關鍵資訊為：【源IP：client_ip，目標IP：lvs_ip，Mac地址：lvs_mac_address】
• 當用戶請求到達LVS伺服器的時候，LVS伺服器直接將改網路資料包的目標IP地址修改為RS伺服器的IP地址（DNAT技術），之後將其轉發到RS伺服器。此時網路資料包關鍵資訊為：【源IP：client_ip，目標IP：rs_ip，Mac地址：lvs_mac_address】（這裡有一個問題，為什麼Mac地址是lvs_mac_address，但資料包就能夠到RS伺服器呢？）
• 當RS伺服器接收到資料包後對比發現目標IP是自己的IP，於是構建響應報文傳送給LVS伺服器。此時網路資料包關鍵資訊為：【源IP：rs_ip，目標IP：client_ip，Mac地址：client_mac_address】
• LVS伺服器接收到響應報文，修改響應報文的源IP地址為LVS的IP地址，然後響應給客戶端。此時發出的響應報文資料包關鍵資訊為：【源IP：lvs_ip，目標IP：client_ip，Mac地址：client_mac_address】
• 響應報文最終到達客戶端

NAT模式要求LVS和RS伺服器必須在同一網段內，因此會導致運維上的困難。另外因為每次請求都需要經過LVS伺服器，所以LVS伺服器的壓力會比較大。

Full-NAT模式

特點：工作在網路層，在LVS修改請求報文以及響應報文的源IP地址、目標IP地址，必須經LVS返回給客戶端。

• 使用者按下按鈕，傳送介面請求。此時網路資料包關鍵資訊為：【源IP：client_ip，目標IP：lvs_ip，Mac地址：lvs_mac_address】
• 當用戶請求到達LVS伺服器的時候，LVS伺服器直接將改網路資料包的源目標IP地址修改為LVS伺服器的IP地址、目標IP地址修改為RS伺服器的IP地址（SNAT技術、DNAT技術），之後將其轉發到RS伺服器。此時網路資料包關鍵資訊為：【源IP：lvs_ip，目標IP：rs_ip，Mac地址：lvs_mac_address】
• RS伺服器接收到資料包，於是構建響應返回給LVS伺服器。此時網路資料包關鍵資訊為：【源IP：rs_ip，目標IP：lvs_ip】
• 當LVS收到RS伺服器的響應資料包後，LVS伺服器直接將改網路資料包的源目標IP地址修改為LVS伺服器的IP地址、目標IP地址修改為客戶端的IP地址（SNAT技術、DNAT技術）。此時網路資料包關鍵資訊為：【源IP：lvs_ip，目標IP：client_ip】
• 響應報文最終到達客戶端

Full-NAT模式是在NAT基礎上為了解決跨子網問題而誕生的，其通過在網路層修改源IP地址和目標IP地址來達到不同子網的通訊。

Tunnel模式

特點：工作在網路層，在原有IP報文外多封裝一層IP報文，由RS伺服器直接返回響應給客戶端。

• 使用者按下按鈕，傳送介面請求。此時網路資料包關鍵資訊為：【源IP：client_ip，目標IP：lvs_ip】
• 當用戶請求到達LVS伺服器的時候，LVS伺服器直接在原有報文外再次封裝一層IP報文，封裝的源IP地址為lvs_ip，目標IP地址為rs_ip，然後將其轉發到RS伺服器。此時網路資料包關鍵資訊為：外部報文-->【源IP：lvs_ip，目標IP：rs_ip】，內部報文-->【源IP：client_ip，目標IP：lvs_ip】。
• RS伺服器接收到報文後發現時自己的IP地址，就將報文接收下來。拆除掉最外層的IP報文後，會發現裡面還有一層IP報文，而且目標是lvs_ip，那麼此時RS開始處理此請求，處理完成之後，直接將響應報文傳送給客戶端。此時網路資料包關鍵資訊為：【源IP：lvs_ip，目標IP：client_ip】
• 響應報文最終到達客戶端。

其實與LVS相似的流量轉發方案還有HAProxy。LVS與HAProxy都適合用來放在負載均衡的最前端，用於海量流量轉發。在高可用支援上，他們都有對應的高可用方案，LVS與KeepAlive結合實現高可用，而HAProxy與heartbeat實現高可用。在配置難度上，LVS配置比較複雜，而HAProxy相對簡單。在系統支援上，Linux系統對LVS有核心級別的支援，而HAProxy則沒有。在效能上，LVS因為有系統核心級別的支援，所以其可以實現響應資料包不經過LVS，而HAProxy的響應資料包則必須經過HAProxy，這就導致了HAProxy的壓力會比較大，也就是HAProxy效能沒有LVS好。

Nginx負載均衡

當請求經過LVS伺服器轉發到達Nginx伺服器後，Nginx會根據其負載配置檔案將請求轉發到具體的應用伺服器進行處理。

與Nginx相似的軟體還有apche、squid、lighttpd等負載均衡軟體，但apache和squid屬於同步模式的反向代理，在大檔案的傳輸上會出現阻塞，導致後端伺服器連線數過多，最終導致伺服器壓力過大。而Nginx和lighttpd則是使用非同步模式的反向代理，代理在接受完資料之前不會與後端伺服器建立連線，這樣就避免了對後端伺服器造成過大壓力。

舉個例子：當用戶上傳一個100M大的檔案時，如果使用者網速慢，需要半個小時才能上傳完。如果採用apache、squid這種同步模式的反向代理，那麼在接收過程中代理不僅會與客戶端建立連線，還會有後臺伺服器建立連線。如果上傳大檔案的使用者一多，那麼後端伺服器的壓力就很大。而且因為廣域網（WAN）和區域網（LAN）的傳輸速度差別很大，因此同步方式的反向代理會造成連線資源的浪費。而nginx和lighttpd非同步模式的反向代理則是等代理完全接收完資料之後，才與後端伺服器建立連線，這樣就大大減少了後端的伺服器的壓力。

而nginx和lighttpd的非同步模式也略有不同，lighttpd是先收完再轉向客戶瀏覽器，而nginx是邊收資料邊轉向使用者瀏覽器。因此nginx的非同步代理模型可以更好地提供高效能的負載均衡，所以現在nginx也是許多企業級網站的首選。

LVS 與 Nginx 的區別

既然LVS和Nginx都能實現負載均衡，那為什麼要將Nginx作為LVS後端機器，而不是LVS作為Nginx的後端機器，他們之間到底有什麼區別呢？

LVS設計就是用來進行流量轉發的，功能比較單一，所以其在流量轉發上效能更高、更穩定。LVS在流量轉發的效能基本達到了F5硬體裝置的60%效能，其他幾個10%都有點困難。但也正是因為其效率高、穩定，所以導致了其功能單一，在應用場景方面比較單一。而Nginx功能強大，支援對域名、目錄的解析，這使得其應用場景廣泛。

簡單地說：lvs只做簡單轉發，能做的事情也就很少，nginx功能全面，能滿足很多的業務場景。

所以我們才說LVS更加適合做最前端的流量轉發，擋住海量流量。而Nginx則適合放在應用伺服器的上層，用來針對不同的請求進行目錄識別或域名識別，從而達到功能模組的垂直分割。

參考資料

• Web基礎架構：負載均衡和LVS - 李克華 - 部落格園
• squid,nginx,lighttpd反向代理的區別 - TroyHector - 部落格園
• lvs與haproxy