理解負載均衡，首先要理解轉移與**的區別：
轉移與**就象客戶與外包公司是否需要直接接觸的場景一樣，如果直接與外包公司接觸就是轉移。如果通過接包人接觸。客戶與外包公司之間透明，就是**。
轉移：資料報從客戶端轉移到實際伺服器，需要知道實際伺服器的位址。
**：資料報只須從客戶端傳送到**伺服器或dnat伺服器上，再由它們**到實際伺服器。當資料報發給**或dnat時，客戶端就認為資料報已經傳送給實際伺服器上。當實際伺服器接收到**或dnat發來的包，實際伺服器就認為資料報就是來自客戶端。
轉移只需要客戶端，實際伺服器參與
**需要客戶端 **或dnat 實際伺服器參與
一.dns的負載均衡：
dns的負載均衡是一種［轉移］。而不是［**］。
二.反向**負載均衡：
對於客戶端，實際伺服器是基於web伺服器或一些專門的**varnish就是工作在一種**的模式下。**的優勢，在七層工作，可以針對每個http請求定製負載。可以配置負載的權重。可以將排程策略落實到每乙個 http 請求。
反向**伺服器工作在 http 層面,對於所有 http 請求都要親自**,可謂是大事小事親歷親為，可控也帶來了劣勢。就是可擴充套件會限制。
反向**伺服器的另乙個特點就是可以根據ip進行hash,從而做到sticky session，即乙個客戶的連續請求被**到同一臺backend。
事實上,在後端伺服器上儲存 session 資料和本地化快取是bad smell.它使得後端伺服器顯得過於個性化,以至於和整個系統格格不入,如果允許的話,我們應該盡量避免這樣的設計,比如採用分布式 session 或者分布式快取等,讓後端伺服器的應用盡量與本地無關,也可更好地適應環境。
解決如下：
1.sna.
2.分布式session：memcached/terracotta
三.dnat負載均衡：
dnat與dns協作的方式：
dns是翻譯網域名稱為ip。dnat是用來修改包。
因為dnat**都是通過ip進行的，而不是通過網域名稱。
如果客戶端通過網域名稱訪問dnat伺服器，首先會通過dns將網域名稱翻譯成ip位址。然後再把客戶端的資料報傳送到dnat伺服器上。如果客戶端直接使用ip位址。連dns的翻譯都免了，直接找的是dnat伺服器。然後再通過dnat來修改資料報位址及埠來實現［**］到實際伺服器。
dnat伺服器：與動態**伺服器幹的一樣的工作：［**］。
dnat的工作原理：修改資料報目標位址及埠。
dnat是根據核心的netfilter包及規則配置iptables（類似於資料檔案）來完成對資料報的目標位址及埠進行修改。
注意：1.netfilter與iptables是dnat實現修改包的工具，是dnat最重要的組成部分。
2.dnat表示了原理。其實dnat伺服器有時候就是nat伺服器。所以，簡稱為nat方式實現ip層的負載均衡。
dnat的缺點：
iptables 似乎只能按照我們的規則來幹活,沒有排程器應該具備的排程能力和排程策略。
四：lvs負載均衡
熟悉了 netfilter/iptables 的機制後。
理解 ipvs(ip virtual server)就一點也不難了,它的工作性質類似於 netfilter 模組,也工作在 linux 核心中,但是它更專注於實現 ip 負載均衡。
ipvs 不僅可以實現基於 nat 的負載均衡,同時還包括後面要介紹的直接路由和 ip 隧道等負載均衡。ipvs模組已經內建到 linux 2.6.x 核心中,這意味著使用 linux 2.6.x 核心的伺服器將無須重新編譯核心就可以直接使用它。
當然,ipvs 也需要有與dnat類似的管理工具,即ipvsadm
vip是使用linux的核心進行負載均衡：
[反向**伺服器]作為負載均衡排程器的工作機制,其本身的開銷已經嚴重制約了這種框架的可擴充套件性,從而也限制了它的效能極限。
能否在 http 層面以下實現負載均衡呢?答案是肯定的。回憶一下網路分層模型,事實上,在資料鏈路層(第二層) 、網路層(第三層)以及傳輸層(四層)都可以實現不同機制的負載均衡,但有所不同的是,這些負載均衡排程器的工作必須由 linux 核心來完成,因為我們希望網路資料報在從核心緩衝區進入程序使用者位址空間之前,盡早地被**到其他實際伺服器上,沒錯,linux 核心當然可以辦得到,隨後我們會介紹位於核心的 netfilter 和 ipvs,而使用者空間的應用程式對此卻束手無策。
好處：1.因為可以將排程器工作在應用層以下,這些負載均衡系統可以支援更多的網路服務協議,比如 ftp、smtp、dns,以及流**和 voip 等應用。
2.排程策略
常見負載均衡演算法
隨著系統日益龐大 邏輯業務越來越複雜，系統架構由原來的單一系統到垂直系統，發展到現在的分布式系統。分布式系統中，可以做到公共業務模組的高可用，高容錯性，高擴充套件性，然而，當系統越來越複雜時，需要考慮的東西自然也越來越多，要求也越來越高，比如服務路由 負載均衡等。此文將針對負載均衡演算法進行講解，不...
常見負載均衡演算法
輪詢很容易實現，將請求按順序輪流分配到後台伺服器上，均衡的對待每一台伺服器，而不關心伺服器實際的連線數和當前的系統負載。這裡通過例項化乙個serviceweightmap的map變數來伺服器位址和權重的對映，以此來模擬輪詢演算法的實現，其中設定的權重值在以後的加權演算法中會使用到，這裡先不做過多介紹...
常見負載均衡演算法
輪詢法是負載均衡中最常用的演算法，它容易理解也容易實現。輪詢法是指負載均衡伺服器 load balancer 將客戶端請求按順序輪流分配到後端伺服器上，以達到負載均衡的目的。假設現在有6個客戶端請求，2台後端伺服器。當第乙個請求到達負載均衡伺服器時，負載均衡伺服器會將這個請求分派到後端伺服器1 當第...