負載均衡就是智能調度
全局負載均衡（GSLB）的負載均衡主要是在多個節點之間進行均衡，其結果可能直接終結負載均衡過程，
也可能將用戶訪問交付下一層次的（區域或本地）負載均衡系統進行處理。
GSLB最通用的是基於DNS解析方式，還有HTTP重定向、IP路由等方法
DNS就是IP地址和網址互換
當須要訪問abc.com這個站點時，
實際上咱們想要瀏覽的網頁內容都存放在互聯網中對應某個IP的服務器上，
而瀏覽器的任務就是找到咱們想要訪問的這臺服務器的IP地址，而後向它請求內容。
本地DNS服務器（local DNS server）是用戶所在局域網或ISP網絡中的域名服務器。
當客戶端在瀏覽器裏請求abc.com時，瀏覽器會首先向本地DNS服務器請求將 abc.com解析成IP地址，
本地DNS服務器再向整個DNS系統查詢，直到找到解析結果。
客戶端能夠配置DNS服務器或經過DHCP來分配
DNS給使用它的互聯網應用帶來額外的時延，有時時延還比較大，爲了解決問題，須要引入「緩存」機制。
緩存是指DNS查詢結果在主機（local DNS server）中緩存。
在區內主機對某個域名發起第一次查詢請求時，
負責處理遞歸查詢的DNS服務器要發送好幾回查詢（先查.root，再查.com之 類，再定位IP地址等）才能找到結果，
不過在這過程當中它也獲得了許多信息，
好比各區域權威DNS服務器（就是告訴你最終abc.com在哪裏的DNS服務 器）和它們的地址、域名解析最終結果。
他會把這些信息保存起來，當其餘主機向它發起查詢請求時，它就直接向主機返回緩存中可以找到的結果，直到數據過時。
客戶端瀏覽器也能夠緩存DNS響應信息。
Internet類資源記錄分爲
–A記錄（address）：域名->多個IP的映射。對同一個域名，能夠有多條A記錄
–NS記錄（name server）：指定由哪臺DNS服務器來解析
–SOA記錄（start of authority）：指定該區域的權威域名服務器
–CNAME記錄（canonical name）：多個域名->服務器的映射
–PTR記錄（pointer record）：IP->域名的映射
DNS系統自己是具有簡單負載分配能力的，這是基於DNS的輪詢機制。
若是有多臺Web服務器（多源）同時爲站點 abc.com提供服務，abc.com的權威服務器可能會解析出一個或多個IP地址。
權威域名服務器還能夠調整響應中IP地址的排列方式，即在每次響應中將不一樣的IP地址置於首位（取決於可服務能力和服務質量），
經過這種方式實現對這些Web服務器的負載均衡經過CNAME方式實現負載均衡：域名服務器得到CNAME記錄後，
就會用記錄中的別名來替換查找的域名或主機名（實現多個域名->服務器映射）。
後面會查詢這個別名的A記錄來獲取相應的IP地址。
具體操做爲：先將GSLB的主機名定義爲所查詢域名的權威DNS服務器的別名，
而後將GSLB主機名添加多條A記錄，分別對應多個服務器的IP地址。
這樣，本地DNS服務器會向客戶端返回多個IP地址做爲域名的查詢結果，而且這些IP地址的排列順序是輪換的。
客戶端通常會選擇首個IP地址進行訪問。
負載均衡器做爲權威DNS服務器：負載均衡器就會接收全部對這個域名的DNS請求，
從而可以根據預先設置的一些策略來提供對域名的智能DNS解析。
F5的DNS具備完整的DNS功能以及加強的GSLB特性，Foundry、Nortel、Cisco和Radware的產品 能實現部分DNS功能。
負載均衡做爲代理DNS服務器：負載均衡器被註冊爲一個域名空間的權威DNS服務器，
而真正的權威域名服務器則部署在負載均衡器後面。
全部的DNS請求都會先到達負載均衡器，由負載均衡器轉發到真正的權威DNS服務器，而後修改權威DNS服務器返回的響應信息。
真正的權威DNS服務器正常響應瀏覽器的DNS請求，返回域名解析結果列表，
這個響應會先發送到負載均衡器，而負載均衡器會根據本身的策略選擇一個性能最好的服務器 IP並修改須要實現GSLB的域名的DNS查詢響應，
對其餘請求透明轉發，這樣就不會影響整個域名空間的解析性能。
在基於DNS方式下不管採用何種工做方式，都會有一些請求不會到達GSLB，這是DNS系統自己的緩存機制在起做用。
當用戶請求的域名在本地DNS或本機（客戶端瀏覽器）獲得瞭解析結果，這些請求就不會達到GSLB。
Cache更新時間越短，用戶請求達到GSLB的概率越大。因爲DNS的緩存機制屏蔽掉至關一部分用戶請求，從而大大減 輕了GSLB處理壓力，使得系統抗流量衝擊能力顯著提高，這也是不少商業CDN選擇DNS機制作全局負載均衡的緣由之一。
但弊端在於，若是在DNS緩存刷新間隔以內系統發生影響用戶服務的變化，
好比某個節點故障，某個鏈路擁塞等，用戶依然會被調度到故障部位去。
智能DNS功能，它在向本地DNS返回應答以前會先根據一些靜態或動態策略進行智能計算。
– 服務器的「健康情況」
– 地理區域距離
– 會話保持
– 響應時間
– IP地址權重
– 會話能力閾值
– 往返時間（TTL）
– 其餘信息，包括服務器當前可用會話數、最少選擇次數、輪詢等算法
關於GSLB的部署問題瀏覽器
關於內容的緩存問題（如何智能調度最有效）和配置
在有些CDN中（用於視頻網站加速的狀況較多），網站須要加速的內容所有先緩存在OCS（內容中心），
而後再將一部分 （一般是熱門的內容）分發到個POP節點（Cache邊緣集羣），
因此POP節點在某些時候會出現本地不命中而須要回OCS取內容或者從其餘POP節點取內容的狀況
純粹基於DNS方式的GSLB只能完成就近性判斷。
爲實現智能調度，大多數解決方案須要在GSLB設備附近以旁路的方式部署一臺輔助設備（爲方便描述，咱們可稱之爲GRM——全局資源管理設備），
用以實現和各POP節點的本地資源管理設備進行通訊，完成CDN對各POP節點的狀態檢查，
並根據POP節點的狀態和流量狀況，從新制訂用戶調度策略，將策略實時發送到GSLB中去執行
由於DNS服務採用以UDP爲基礎的、默認無鏈接的訪問方式，給分佈式攻擊（DDoS）帶來了更大的便利。
（有DNSSEC能夠提供某程度的DDoS攻擊保護）
隱藏節點的存在很大程度上能夠避免GSLB被攻擊致癱瘓的機會，
實際隱藏節點的實現方法就是在實際組網時除了部署正常工做的GSLB之外，
再部署一臺備份的GSLB設備，並將這一備份GSLB設備隱藏起來，不對外公佈。
HTTP重定向（CDN GSLB用302重定向）：在HTTP協議中，有三類重定向狀態碼：
301永久性轉移（permanently moved）、
302暫時轉移（temporarily moved）、
meta fresh在特定時間後重定向到新的網頁
HTTP重定向只適用於HTTP應用，不適用於任何其餘應用。
好比微軟的MMS協議，RTSP協議，就不能使用這種方式 進行重定向。
其次，因爲HTTP重定向過程須要額外解析域名URL，還須要與URL創建TCP鏈接而且發送HTTP請求，使得響應時間加長。
第三，不一樣於DNS方式，沒有任何用戶請求能被外部系統終結（不能緩存），
全部請求都必須進入GSLB系統，這將成爲性能和可靠性的瓶頸。(流媒體用的比較多)
基於IP路由的GSLB
基於路由協議算法選擇一條路由到達這兩個本地均衡器中的一個。
由於每次訪問請求的終端IP地址不一樣，路由條件也不一樣，
因此在多個路由器上優選的路由不一樣，從統計複用的角度來看基本是在負載均衡器1和2之間均勻分佈的。
IP路由在多個POP點之間實現的負載均衡是一種機率上的均衡，而不是真正的均衡（沒作智能調度）。
基於DNS解析方式,基於HTTP重定向方式,基於IP路由方式 這3種方式的比較
性能
基於DNS解析方式：本地DNS服務器和用戶終端DNS緩存能力使GSLB的負載獲得有效分擔
基於HTTP重定向方式：GSLB處理壓力大，容易成爲系統性能的瓶頸
基於IP路由方式：藉助IP網絡設備完成負載均衡，沒有單點性能瓶頸
準確度
基於DNS解析方式：定位準確度取決於本地DNS覆蓋範圍，本地DNS設置錯誤會形成定位不許確
基於HTTP重定向方式：在對用戶IP地址數據進行有效維護的前提下，定位準確且精度高
基於IP路由方式：就近性調度準確，但對設備健康性等動態信息響應會有延遲
效率
基於DNS解析方式：效率約等於DNS系統自己處理效率
基於HTTP重定向方式：依靠服務器作處理，對硬件資源的要求高
基於IP路由方式：效率約等於IP設備自己效率
擴展性
基於DNS解析方式：擴展性和通用性好
基於HTTP重定向方式：擴展性較差，需對各類應用協議進行定製開發
基於IP路由方式：通用性好，但適用範圍有限
商用性
基於DNS解析方式：在Web加速領域使用較多
基於HTTP重定向方式：國內流媒體CDN應用較多
基於IP路由方式：尚無商用案例緩存
備註：隨筆中內容來源於網上資料整理,僅供參考服務器