前面我們對流媒體服務器的負載均衡內容作了一個概述，相信大家已經對這個知識有了一定的認識。那么現在我們來仔細分析一下它的系統設計和機制問題。從原理上面看看流媒體服務器的負載平衡時如何做到，那么具體的內容還請大家從文章中了解吧。

流媒體服務器中的負載均衡系統設計

流媒體服務器中的負載均衡系統是在基于LAN的分布式體系結構下實現的負載均衡,所有來自客戶端的請求被透明地分配到若干服務器上｡對用戶而言,整個分布式系統仿佛是臺單一的邏輯服務器｡這樣的集群系統能夠提供較強的可擴展性和較好的吞吐性能｡從商業角度而言,不僅可以保護原來的投資,而且也可以通過廉價的集群系統獲得高性能計算機所能達到的處理能力｡

然而要使這樣的集群系統保持較高的資源利用率面臨一定挑戰｡例如,現有的負載均衡方法都不能很好地解決本系統中涉及的問題,最早的負載均衡技術是通過 DNS來實現的,在DNS中為多個地址配置同一個域名,從而查詢該域名的客戶機將訪問不同的服務器,達到負載均衡的目的｡ DNS負載均衡雖然簡單而有效,但它不能區分服務器的差異,也不能反映服務器的當前運行狀態｡

有人采用反向代理服務器進行請求轉發的方法,該方法雖然能夠應用優化的負載均衡策略,使每次服務均由最空閑的內部服務器來提供,以達到負載均衡的目的｡但隨著并發連接數量的增加,代理服務器本身的負載也變得非常大,反向代理服務器本身反而會成為服務的瓶頸｡還有人采用支持負載均衡的地址轉換網關的方法,可以將一個外部IP地址映射為多個內部IP地址,對每次請求動態使用其中一個內部地址,達到負載均衡的目的｡

很多硬件廠商將此技術集成在設備中,采用隨機選擇､根據服務器的連接數量或者響應時間進行選擇的負載均衡策略來分配負載,然而硬件實現的負載控制器靈活性不強,不能支持更優化的負載均衡策略和更復雜的應用協議｡還有負載均衡方法是在某些協議內部實現的,例如HTTP協議中的重定向功能等,但它依賴于特定協議,因此使用范圍有限｡

流媒體服務器中采用的基于分配器的負載均衡機制

基于分配器的負載均衡機制是IP/TCP/HTTP的重定向分配｡一般需要一個特殊的前端節點,稱為分配器(dispatcher)｡所有的客戶端請求都經過分配器并由它分配到后端服務器處理｡這種基于分配器的請求分配機制通常對客戶端是透明的,采用的機制有兩種:

一種稱為中繼機制(relaying),如圖1所示,客戶端請求到達分配器后,由分配器按定的負載分配算法,將請求傳遞給被選中的服務器｡服務器處理后的結果傳回至分配器,再由分配器轉發給客戶端｡分配器的工作通常在操作系統的應用層完成,也有修改操作系統核心直接支持中繼機制的系統,其性能會有所改善,這種優化的方法稱為TCP銜接(TCP splicing);

圖1. 中繼機制示意圖

另外一種機制稱為TCP傳遞(TCP handoff),如圖2所示,客戶端的請求經過分配器分配到達服務器,服務器將處理后的結果不經過分配器而直接發送給客戶端｡中繼或TCP銜接機制要求所有的通信均要經過分配器(特別是處理結果信息量很大的情況下),因此容易在分配器形成通信瓶頸,TCP傳遞機制避免了這一問題,因此性能更好,但是需要對前端和后端節點進行修改,以支持TCP handoff ｡

圖2. TCP傳遞機制示意圖