實現大容量網絡直播的方法及其系統的製作方法
2023-05-28 03:50:46 1
專利名稱：實現大容量網絡直播的方法及其系統的製作方法
技術領域：
本發明涉及網絡傳輸技術，更具體地說，涉及一種實現大容量網絡直播的方法及其系統。
背景技術：
作為一種嶄新的傳播渠道，網絡直播有極強的現場感和交互性，給用戶帶來一種全新的交流模式。網絡直播承載著網絡的特性打破了地域的界限，具有極為廣泛的傳播面。通過網絡，幾十萬人可以同時交流和互動，對受眾的吸引力自然也會更大。網絡直播實時性、互動性及豐富多彩的音、視頻多媒體的特性帶給用戶全新的網絡視角和體驗，多媒體網絡直播服務的形式主要包括現場直播、嘉賓主持論壇、遠程在線訪談、網絡發布會等。
目前的網絡直播一般是通過客戶端主動從伺服器上拉取數據來實現的，即通過不斷刷新的方式，但每一次刷新，都會造成客戶端的瀏覽器與伺服器的連接斷開，然後又重新連接。
由於客戶端需要每隔幾秒又重新到伺服器拉取數據，在數據量小或用戶不多的情況下，並沒有什麼問題，但如果當用戶成倍增長，數據量極度膨脹時，這樣就會因為大量獲取重複數據，造成網絡佔用率高，網速過慢，無法達到大規模直播的需要。
發明內容
本發明要解決的技術問題在於，針對現有技術的上述網絡佔用率高、無法達到大規模網絡直播的缺陷，提供一種實現大容量網絡直播的方法及其系統，有效地降低網絡佔用率並節約伺服器資源。
本發明解決其技術問題所採用的技術方案是構造一種實現大容量網絡直播的方法，該方法包括以下步驟a.負載均衡伺服器接收到客戶端的請求後，將該用戶請求定位到直播伺服器上；b.所述客戶端獲得由所述直播伺服器返回的直播頁面後，並獲得由所述直播伺服器分配的邏輯房間；以及c.通過所述直播頁面內嵌的腳本程序將直播消息顯示在瀏覽器上。
在本發明所述的方法中，所述步驟a包括所述負載均衡伺服器將所有直播伺服器的網址及用戶請求保存在共享內存中，並通過採用取模策略將新來的用戶請求依次重定向到具體一臺直播伺服器上。
在本發明所述的方法中，所述取模策略是指將用戶請求數與所述直播伺服器總數取模得到所述具體一臺直播伺服器的序號。
在本發明所述的方法中，所述步驟b包括將用戶登錄的基本信息通過中心控制管理伺服器發送給管理伺服器，並由所述管理伺服器將邏輯房間配置信息通過所述中心控制管理伺服器發送給所述直播伺服器；所述管理伺服器將直播消息通過所述中心控制管理伺服器發送給所述直播伺服器，並由所述直播伺服器將所述直播消息向所述客戶端發送。
在本發明所述的方法中，所述直播頁面通過直播消息顯示頁面與網友聊天信息顯示頁面進行顯示，所述直播消息顯示頁面與所述網友消息顯示頁面都是本地頁面。
在本發明所述的方法中，所述步驟b還包括根據http協議，所述客戶端的瀏覽器與所述直播伺服器建立直播消息顯示頁面的長連接，並由所述直播伺服器通過所述長連接將直播消息實時向所述客戶端發送；根據http協議，所述直播伺服器接收到用戶需要獲取一個頁面的請求或接收到用戶提交的聊天信息時，就與所述客戶端的瀏覽器建立短連接。
在本發明所述的方法中，所述長連接是指獲取所述直播頁面後，所述瀏覽器並不會關閉與所述直播伺服器的連接，如果有新的直播消息到達所述直播伺服器，所述直播伺服器就會將直播消息通過所述長連接的直播頁面直接發送給用戶。
在本發明所述的方法中，所述短連接是指所述直播伺服器處理完所述頁面的請求或所述聊天消息，就會關閉與所述瀏覽器的連接。
在本發明所述的方法中，所述步驟c包括當所述客戶端接收到由所述直播伺服器發來的直播消息，所述瀏覽器就會執行內嵌於所述直播頁面的腳本程序，從而實現直播消息的顯示。
一種實現大容量網絡直播的系統，包括直播伺服器，用於處理客戶端的連接與用戶登錄請求，接收與響應客戶端的聊天消息，並向客戶端轉發直播頁面與直播消息；負載均衡伺服器，用於保存所述直播伺服器的負載記錄，並根據該記錄對用戶請求進行重定向；中心控制管理伺服器，用於向所述直播伺服器轉發消息；管理伺服器，用於配置或修改邏輯房間信息、錄入訪談內容以及統計在線用戶請求，並通過所述中心控制管理伺服器向所述直播伺服器下發直播消息。
本發明的有益效果是，實現大容量(如10萬級)的用戶在線觀看直播，並提供交互的功能，並通過增加伺服器，系統很容易擴展，適用於不同的需求，具體有(1)採用linux系統的Epoll模式增加伺服器的處理能力；(2)採用多線程處理用戶請求，相關線程只需處理自己所負責業務流程的數據；(3)單個線程處理多個http請求，減少進程切換，提高系統性能；(4)採用內存預分配，整個伺服器運行中不釋放內存，避免內存洩漏，減少內存碎片，無需花費申請內存的CPU時間；(5)直播頁面採用全cache(緩存)或預處理機制，加快http請求處理。
下面將結合附圖及實施例對本發明作進一步說明，附圖中圖1是本發明的整體實現方案的示例圖；圖2是本發明分配邏輯房間的實例圖；圖3是本發明的直播伺服器內存的頁面集的實例圖；圖4是本發明的HTTP請求處理的流程圖；圖5是本發明的具體實施例的伺服器部署結構圖。
具體實施例方式
如圖1所示，一種實現大容量網絡直播的系統，包括直播伺服器，用於處理客戶端的連接與用戶登錄請求，接收與響應客戶端的聊天消息，並向客戶端轉發直播頁面與直播消息；負載均衡伺服器，用於保存所述直播伺服器的負載記錄，並根據該記錄對用戶請求進行重定向；中心控制管理伺服器，用於向所述直播伺服器轉發消息；管理伺服器，用於配置或修改邏輯房間信息、錄入訪談內容以及統計在線用戶請求數，並通過所述中心控制管理伺服器向所述直播伺服器下發直播消息。
負載均衡伺服器將接收到的用戶請求後，將所有直播伺服器的網址及用戶請求保存在共享內存中，並通過採用取模策略將新來的用戶請求依次重定向到直播伺服器中，即將新來的用戶請求依次重定向到共享內存中的某一臺直播伺服器上，取模策略是指將用戶請求數與直播伺服器總數取模得到某臺具體伺服器的序號，也就是說請求數％直播伺服器總數＝某臺具體伺服器的序號，假如有5臺直播伺服器，那麼通過採用取模策略得出的結果可表示為用戶請求1-直播伺服器1；用戶請求2-直播伺服器2；用戶請求3-直播伺服器3；用戶請求4-直播伺服器4；
用戶請求5-直播伺服器5；用戶請求6-直播伺服器1；……當定位到某臺具體的直播伺服器後，直播伺服器就可以與用戶進行交互。
直播伺服器根據用戶的請求先將直播頁面的框架發送給客戶端，客戶端通過瀏覽器就可以分別獲取到頁面框架裡面的頁面(內容)，因為一個完整的直播頁面主要由直播消息顯示頁面與網友聊天信息顯示頁面兩大塊組成的，直播消息顯示頁面與網友消息顯示頁面都是本地頁面。當客戶端獲取到由直播伺服器返回的直播頁面後，也獲得了由管理伺服器將配置房間信息通過中心控制管理伺服器發送給直播伺服器，並由直播伺服器根據該配置房間信息分配的邏輯房間。直播伺服器按以下方法來實現分配邏輯房間的。
如圖2所示，直播伺服器首先根據用戶請求的信息確定用戶請求的直播ID，查找直播的相關房間，如果該直播沒有房間，或所有房間已滿，則創建一個房間，如果有房間並且沒滿，則增加該用戶的長連接句柄到房間的句柄集合中(例如，直播1房間1長連接句柄集合，直播1房間2長連接句柄集合，直播1房間3長連接句柄集合…直播2房間1長連接句柄集合等等)，這樣會便於在房間內群發消息，並設置用戶信息中的房間屬性，表明用戶在哪個房間。
由上述可知，當客戶端獲取到由直播伺服器返回的直播頁面後，客戶端的瀏覽器與直播伺服器就會建立直播消息顯示頁面的長連接，直播伺服器通過該長連接將直播消息向客戶端的直播消息顯示頁面實時發送。這樣就形成了一個沒有下載完成的頁面，直播伺服器端只有發送直播消息，客戶端實時接收直播消息。
上述長連接是指客戶端獲取了直播頁面後，只要用戶不主動去刷新瀏覽器，瀏覽器是不會關閉與直播伺服器的連接，如果有新的直播消息，直播消息會通過該長連接的直播頁面直接發送到客戶端。
如圖3所示，直播伺服器對普通靜態頁面的處理請求為將每個直播的相關的一組靜態頁面存儲在內存中，當接收到用戶請求後，按照請求需要獲得文件名及訪談名稱，直播伺服器就查找相關的頁面。假如請求為「GET/chat_top.html？test」，需要獲取伺服器上的test訪談的chat_top.html頁面，每個訪談都可以有數個頁面(即直播頁面集)，每個直播頁面集包括有file1 file2 file3…fileN個文件。這些頁面都通過頁面模板及配置信息生成。全部緩存在直播伺服器的內存中，以提高訪問速度。
直播伺服器接收到用戶需要獲取一個頁面的請求或接收到用戶提交的聊天信息時，就與所述客戶端的瀏覽器建立短連接。網友聊天信息顯示區的頁面為本地頁面，由直播伺服器將聊天信息通過直播頁面發送給當前邏輯房間內的每個用戶，即直播伺服器將嘉賓、主持人發言(訪談內容)通過直播頁面發送給當前邏輯房間(也稱為聊天室)內的每個用戶。短連接是指每次獲取聊天信息顯示頁面後，瀏覽器都需要刷新一次，這樣瀏覽器就關閉與所述直播伺服器的連接，然後再重新連接。例如用戶發言屬於短連接。用戶可以以匿名登陸或註冊登陸的方式在聊天室裡面發言。下面先以直播伺服器對用戶匿名登陸的處理流程進行說明。
如圖4所示，當用戶提交如下請求「GET/chatcom.html？test HTTP/1.1.」就可獲取直播消息頁面，如果提交的請求中不帶cookie信息(cookie信息是當你訪問某個站點時，隨某個HTML網頁發送到客戶端瀏覽器中的一小段信息)，表明用戶進行匿名登陸。
直播伺服器首先獲取用戶需要得到的訪談名稱，以上面的例子來說就是test，並將用戶分配到一個具體的房間裡(因為用戶匿名登陸發言，需要在刷新聊天信息顯示頁面，這時客戶端的瀏覽器與直播伺服器的連接就會斷開，直播伺服器就得重新分配了邏輯房間)，並返回http相應的頭部，將http頭部的Connection的欄位設置為Keep-Alive屬性(Keep-Alive是http協議的一個屬性，可以提供http的持續作用功能)。上述Connecton欄位的Keep-Alive屬性保證了和客戶端的長連接。保證了該頁面一直在下載態，這樣只要有新的消息添加到直播頁面的尾部，瀏覽器就可立即收到了新的消息。然後，設置用戶的臨時cookie，該cookie包含了為用戶生成了一個隨機用戶ID與用戶序號(用戶ID與用戶序號用來表示用戶信息在伺服器上存儲的內存下標)。最後，以javascript腳本的模式向客戶端返回已經進行過的聊天信息，如果等待有新的直播消息，就繼續推送(push)給用戶。下面以直播伺服器對用戶登陸的處理流程進行說明。
當用戶提交如下請求「GET/chatcom.html？test HTTP/1.1.」，就可獲取直播消息頁面，如果提交的請求中附帶cookie信息，表明用戶進行註冊登陸。
直播伺服器首先獲取用戶需要得到的訪談名稱，以上面的例子來說就是test。並獲取用戶cookie，從用戶cookie獲取sessionkey進行交驗，再設置用戶信息，將用戶分配到一個具體的房間裡(因為註冊用戶登陸，需要在刷新聊天信息顯示頁面，這時客戶端的瀏覽器與直播伺服器建立的連接就會斷開，直播伺服器就得重新分配了邏輯房間)，並返回http相應的頭部，將頭部的Connection欄位設置為Keep-Alive，以保證和用戶的長連接。然後，設置用戶的cookie，該cookie包含了用戶ID、暱稱與用戶序號(用戶ID、暱稱與用戶序號用來表示用戶信息在伺服器上存儲的內存下標)。最後，以javascript腳本的模式返回已經進行過的聊天信息，如果等待有新的直播消息，就繼續推送(push)給用戶。下面以直播伺服器對用戶在網友聊天信息顯示頁面(聊天室)進行發言的處理流程進行說明。
用戶可以以匿名登陸或註冊登陸的方式在聊天室裡面進行發言。用戶在所分配的邏輯房間(可稱為聊天室)裡的發言只在當前邏輯房間有效，嘉賓、主持人發言對所有房間(本訪談)都有效。這裡所述的邏輯房間對用戶是透明的，用戶不需要知道自己所在的房間，因為這個是由直播伺服器分配的，如果當前房間已經滿了，那麼直播伺服器則重新創建一個房間。一個房間在一臺直播伺服器上，不存在一個房間分別在兩個直播伺服器上的情況。
當用戶在進行發言時，即提交聊天信息，用戶可以使用http協議中的Post模式來提交信息，用戶首先以Post模式將發言信息與用戶的基本信息(如用戶ID、暱稱與用戶序號等等)提交到直播伺服器，例如可表示為「POST/TalkHTTP/1.1」。該類請求不需要直播伺服器響應，直播服務端在收到該消息後即可關閉連接。當直播伺服器獲取到用戶的cookie信息，就會根據用戶的基本信息去判斷該用戶的合法型，如果合法，則從用戶以Post模式提交的發言信息與用戶的基本信息中，提取相關的聊天信息，並定位用戶所在的邏輯房間，然後通過該邏輯房間內每個用戶的長連接句柄，在該房間內轉發信息。
所述管理伺服器將錄入的訪談內容等直播消息通過所述中心控制管理伺服器發送給所述直播伺服器，並由所述直播伺服器向所述客戶端發送。這樣在客戶端的直播消息顯示頁面與網友聊天信息顯示頁面就可以實時顯示。該顯示是通過所述直播頁面上內嵌的腳本程序來實現的。
由上述可知，客戶端瀏覽器顯示的直播頁面分為兩部分直播消息顯示頁面與網友聊天信息顯示頁面。直播消息包括顯示頁面顯示嘉賓訪談或體育直播的消息(附帶音視頻的)，也包括在網友聊天信息顯示頁面所顯示的網友聊天的信息以及嘉賓訪談的文字信息，直播頁面通過調用不同的函數將消息顯示到這兩個個區域。直播信息以如下的腳本方式發送到客戶端，腳本程序可表示為script language＝javascriptparent.addTalkMsg( )；/script需要說明的是，直播頁面是隱藏的，它的功能就是負責接收直播伺服器發來的消息，並不負責消息的顯示。但可以由一個單獨的顯示頁面來實現，該頁面是直播頁面的父頁面。顯示頁面上實現了addTalkMsg等函數。這樣直播消息頁面收到如script language＝javascriptparent.addTalkMsg之類的腳本，將執行其父頁面(負責顯示信息的頁面)的addTalkMsg函數。並通過document.write的方式將信息寫到頁面上。
採取以上的技術方案，就可以實現單機支持20000個用戶同時上線的網絡直播，設定有5臺單機，那麼就可以實現支持10萬級大容量用戶同時上線，伺服器的部署可以採取如圖5所示的結構。由於北方是通過網通來上網，南方通過電信來上網，可以將直播伺服器的南北網絡分開，聊天室系統可以採用一個樹型可擴充的體系結構。
權利要求
1.一種實現大容量網絡直播的方法，其特徵在於，包括以下步驟a.負載均衡伺服器接收到客戶端的請求後，將該用戶請求定位到直播伺服器上；b.所述客戶端獲得由所述直播伺服器返回的直播頁面後，並獲得由所述直播伺服器分配的邏輯房間；以及c.通過所述直播頁面內嵌的腳本程序將直播消息顯示在瀏覽器上。
2.根據權利要求1所述的方法，其特徵在於，所述步驟a包括所述負載均衡伺服器將所有直播伺服器的網址及用戶請求保存在共享內存中，並通過採用取模策略將新來的用戶請求依次重定向到具體一臺直播伺服器上。
3.根據權利要求2所述的方法，其特徵在於，所述取模策略是指將用戶請求數與所述直播伺服器總數取模得到所述具體一臺直播伺服器的序號。
4.根據權利要求1所述的方法，其特徵在於，所述步驟b包括將用戶登錄的基本信息通過中心控制管理伺服器發送給管理伺服器，並由所述管理伺服器將邏輯房間配置信息通過所述中心控制管理伺服器發送給所述直播伺服器；所述管理伺服器將直播消息通過所述中心控制管理伺服器發送給所述直播伺服器，並由所述直播伺服器將所述直播消息向所述客戶端發送。
5.根據權利要求1或4所述的方法，其特徵在於，所述直播頁面通過直播消息顯示頁面與網友聊天信息顯示頁面進行顯示，所述直播消息顯示頁面與所述網友消息顯示頁面都是本地頁面。
6.根據權利要求5所述的方法，其特徵在於，所述步驟b還包括根據http協議，所述客戶端的瀏覽器與所述直播伺服器建立直播消息顯示頁面的長連接，並由所述直播伺服器通過所述長連接將直播消息實時向所述客戶端發送；根據http協議，所述直播伺服器接收到用戶需要獲取一個頁面的請求或接收到用戶提交的聊天信息時，就與所述客戶端的瀏覽器建立短連接。
7.根據權利要求6所述的方法，其特徵在於，所述長連接是指獲取所述直播頁面後，所述瀏覽器並不會關閉與所述直播伺服器的連接，如果有新的直播消息到達所述直播伺服器，所述直播伺服器就會將直播消息通過所述長連接的直播頁面直接發送給用戶。
8.根據權利要求6所述的方法，其特徵在於，所述短連接是指所述直播伺服器處理完所述頁面的請求或所述聊天消息，就會關閉與所述瀏覽器的連接。
9.根據權利要求7或8所述的方法，其特徵在於，所述步驟c包括當所述客戶端接收到由所述直播伺服器發來的直播消息，所述瀏覽器就會執行內嵌於所述直播頁面的腳本程序，從而實現直播消息的顯示。
10.一種實現大容量網絡直播的系統，其特徵在於，包括直播伺服器，用於處理客戶端的連接與用戶登錄請求，接收與響應客戶端的聊天消息，並向客戶端轉發直播頁面與直播消息；負載均衡伺服器，用於保存所述直播伺服器的負載記錄，並根據該記錄對用戶請求進行重定向；中心控制管理伺服器，用於向所述直播伺服器轉發消息；管理伺服器，用於配置或修改邏輯房間信息、錄入訪談內容以及統計在線用戶請求，並通過所述中心控制管理伺服器向所述直播伺服器下發直播消息。
全文摘要
本發明涉及一種實現大容量網絡直播的方法，其特徵在於，包括以下步驟a.負載均衡伺服器接收到客戶端的請求後，將該用戶請求定位到直播伺服器上；b.所述客戶端獲得由所述直播伺服器返回的直播頁面後，並獲得由所述直播伺服器分配的邏輯房間；以及c.通過所述直播頁面內嵌的腳本程序將直播消息顯示在瀏覽器上。本發明還同時公開了一種實現大容量網絡直播的系統。本發明實現10萬級的大容量用戶在線觀看直播，並提供交互的功能，並通過增加伺服器，系統很容易擴展，適用於不同的需求。
文檔編號H04L12/18GK1992621SQ20051012137
公開日2007年7月4日 申請日期2005年12月27日 優先權日2005年12月27日
發明者吳雙, 劉鵬 申請人:騰訊科技(深圳)有限公司