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

流媒體服務器中的負載均衡系統(tǒng)設計

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

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

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

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

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

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

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

圖1. 中繼機制示意圖

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

圖2. TCP傳遞機制示意圖