https://www.cnblogs.com/Alanf/p/8072312.html
負載均衡就是智能調度
全局負載均衡（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路由方式：尚無商用案例
備注：隨筆中內容來源於網上資料整理,僅供參考