負載均衡 （Load Balancing） 負載均衡建立在現有網絡結構之上，它提供了一種廉價有效透明的方法擴充網絡裝置和伺服器的帶寬、增加吞吐量、加強網絡資料處理能力、提高網絡的靈活性和可用性。
大型網站負載均衡的利器
- 全局負載均衡系統（GSLB）
- 内容緩存系統（CDN）
- 伺服器負載均衡系統（SLB）
DNS域名解析的基本過程
最初的負載均衡解決方案（DNS輪詢）
優點
- 基本上無成本，因為往往域名注冊商的這種解析都是免費的；
- 部署友善，除了網絡拓撲的簡單擴增，新增的Web伺服器隻要增加一個公網IP即可
缺點
- 健康檢查，如果某台伺服器當機，DNS伺服器是無法知曉的，仍舊會将通路配置設定到此伺服器。修改DNS記錄全部生效起碼要3-4小時，甚至更久；
- 配置設定不均，如果幾台Web伺服器之間的配置不同，能夠承受的壓力也就不同，但是DNS解析配置設定的通路卻是均勻配置設定的。使用者群的配置設定不均衡導緻DNS解析的不均衡。
- 會話保持，如果是需要身份驗證的網站，在不修改軟體構架的情況下，這點是比較緻命的，因為DNS解析無法将驗證使用者的通路持久配置設定到同一伺服器。雖然有一定的本地DNS緩存，但是很難保證在使用者通路期間，本地DNS不過期，而重新查詢伺服器并指向新的伺服器，那麼原伺服器儲存的使用者資訊是無法被帶到新伺服器的，而且可能要求被重新認證身份，來回切換時間長了各台伺服器都儲存有使用者不同的資訊，對伺服器資源也是一種浪費。
全局負載均衡系統（GSLB）
優勢
- 資料中心備援備份
- 多站點流量優化
- 確定使用者體驗
全局負載均衡系統（GSLB）的原理
DNS檢查工具網上有很多，感興趣的可以搜尋一下。
内容緩存系統（CDN）
- 内容緩存系統（CDN）之靜态加速
- 内容緩存系統（CDN）之動态加速
動态加速的特點
- 智能路由
- 傳輸控制協定（TCP）優化
- HTTP預載
伺服器負載均衡系統
應用背景
- 通路流量快速增長
- 業務量不斷提高
使用者需求
- 希望獲得7×24的不間斷可用性及較快的系統反應時間
負載均衡必須滿足性能、擴充、可靠性
伺服器負載均衡系統三種接入方式
| 部署方式 | 特點 | 優點 | 缺點 |
| 串聯路由模式 | 比較常見的部署方式 |
|
|
| 單臂模式 | 最常見的部署方式 |
|
|
| DSR | 伺服器回程封包不通過負載均衡裝置，直接傳回給用戶端； 延遲短，适合流媒體等對延時要求較高應用 |
|
|
伺服器負載均衡系統的常見排程算法
- 輪詢（Round Robin）
- 權重輪詢（Weighted Round Robin）
- 最少連接配接（Least Connections）
- 權重最少連接配接（Weighted Least Connections）
健康性檢查
健康性檢查算法的目的：通過某種探針機制，檢查伺服器群中真實伺服器的健康情況，避免把用戶端的請求分發給出現故障的伺服器，以提高業務的HA能力。
目前常用的健康性檢查算法：
- Ping（ICMP）
- TCP
- HTTP
- FTP
系統加速
優化功能-SSL加速
優化功能-HTTP壓縮
HTTP壓縮是在Web伺服器和浏覽器間傳輸壓縮文本内容的方法。F5 HTTP壓縮技術通過具有智能壓縮能力的 BIG-IP 系統可縮短應用傳遞時間并優化帶寬。HTTP壓縮采用通用的壓縮算法壓縮HTML、JavaScript或CSS檔案。壓縮的最大好處就是降低了網絡傳輸的資料量，進而提高用戶端浏覽器的通路速度。
優化功能-連接配接複用
優化功能-TCP緩存
會話保持
會話保持-用戶端源IP會話保持
源IP位址會話保持就是将同一個源IP位址的連接配接或者請求認為是同一個使用者，根據會話保持政策，在會話保持有效期内，将這些發自同一個源IP位址的連接配接/請求都轉發到同一台伺服器。
會話保持-Cookie會話保持
當采用基于源位址的會話保持無法做到負載均分時，例如用戶端發起連接配接請求的源IP位址相對固定，發生此類問題通常可采用基于應用層的會話保持方式，Cookie通常是存在于HTTP頭中，現如今基于HTTP的應用被廣泛使用，是以基于Cookie的會話保持越來越多的出現在伺服器負載均衡解決方案中。
局限性：
對于非HTTP協定，或者用戶端禁用Cookie，無效。
會話保持-URL哈希（Hash）會話保持
哈希會話保持的一個基本概念就是按照某個Hash因子，根據此因子以及背景存在多少台伺服器計算得到的結果來選擇将請求配置設定到那台伺服器。哈希會話保持的特點是在背景伺服器的健康狀态不發生改變的時候，每個特定的Hash因子被配置設定到的伺服器是固定的。其最大的優勢是哈希會話保持可以沒有會話保持表，而僅僅是根據計算的結果來确定被配置設定到那台伺服器，尤其在一些會話保持表查詢的開銷已經遠遠大于Hash計算開銷的情況下，采用Hash會話保持可以提高系統的處理能力和響應速度。
URL哈希會話保持通常針對背景采用Cache伺服器的應用場景，針對URL進行Hash計算，将同一個URL的請求配置設定到同一台Cache伺服器，這樣，對背景的Cache伺服器群來說，每台Cache伺服器上存放的内容都是不一樣的，提高Cache伺服器的使用率。
故障案例分析
Q&A案例分析（1）-循環跳轉
故障現象：
Web服務端對使用者通路的URL進行判斷，對于非https的請求，重定向到http站點，結果導緻使用者一直302跳轉。
原因分析：
采用了負載均衡SSL加速功能，在服務端看到所有的使用者請求都來自于http。
解決方案：
全站啟用SSL加速。
Q&A案例分析（2）-使用者Session丢失
故障現象：
使用者在http站點上送出資料到同域名的https站點，web程式抛出session丢失的異常，使用者送出資料失敗。
原因分析：
http和https在負載均衡裝置上被認為是2個獨立的服務，産生2個獨立的TCP連結，會命中不同的真實伺服器，導緻session丢失。
解決方案：
在負載均衡裝置上啟用基于真實伺服器的會話保持。
Q&A案例分析（3）-用戶端源IP取不到
故障現象：
服務端擷取不到使用者外網的IP位址，看到的都是大量來自于内網特定網段的IP位址。
原因分析：
負載均衡裝置啟用了使用者源位址轉換（SNAT）模式，修改了TCP封包中的使用者源IP。
解決方案：
負載均衡裝置會用使用者的外網IP改寫x-forwarded-for值，服務端通過擷取http協定中request header頭的x-forwarded-for值作為使用者源IP。IIS日志通過安裝插件形式顯示使用者源IP。
伺服器負載均衡裝置選型
1.價格因素
硬體裝置：F5、 Citrix 、Redware 、A10
軟體：LVS、Nginx、Haproxy、zen loadbalance
2.性能
4/7層吞吐量(機關bps)
4/7層建立連接配接數（機關CPS）
并發連接配接數
功能子產品性能名額（ssl加速、 HTTP壓縮、記憶體Cache）
3.滿足真實和未來需求
1）如果确認負載均衡裝置對所有應用的處理都是最簡單的4層處理，那麼理論上選擇的負載均衡裝置的4層性能稍高于實際性能需求即可。
2）如果确認負載均衡裝置對所有應用的處理都是簡單的7層處理，那麼理論上選擇的負載均衡裝置的7層性能稍高于實際性能需求即可。
3）如果負載均衡裝置處理的應用既有4層的也有7層的，建議按照7層應用的性能來考慮負載均衡裝置。
4）如果确認自己的應用經過負載均衡處理時，需要複雜的4層或者7層處理，例如需要根據用戶端的位址做政策性分發，需要根據tcp的内容做處理，需要根據HTTP頭或者HTTP封包做處理，那麼建議選擇的負載均衡裝置4/7層性能為真實性能需求的兩倍。
5）如果負載均衡裝置有混合的複雜流量處理并且還開啟了一些功能子產品，那麼建議選擇的負載均衡裝置4/7層性能為真實性能需求的3倍。
6）考慮到裝置需要輕載運作才能更加穩定，是以有可能的話在以上基礎上再增加30%的性能。
7）如果還要滿足未來幾年的發展需求，在以上基礎上還要留出未來發展所需要增加的性能。
8）不同負載均衡裝置廠家由于不同的架構，使得某些裝置在複雜環境下可能也表現的比較優秀，這個客戶可以對比判斷，但總體來說，以上建議适合于所有廠家的裝置。