专利名称:实现大容量网络直播的方法及其系统的制作方法
技术领域：
本发明涉及网络传输技术，更具体地说，涉及一种实现大容量网络直播的方法及其系统。
背景技术：
作为一种崭新的传播渠道，网络直播有极强的现场感和交互性，给用户带来一种全新的交流模式。网络直播承载着网络的特性打破了地域的界限，具有极为广泛的传播面。通过网络，几十万人可以同时交流和互动，对受众的吸引力自然也会更大。网络直播实时性、互动性及丰富多彩的音、视频多媒体的特性带给用户全新的网络视角和体验，多媒体网络直播服务的形式主要包括现场直播、嘉宾主持论坛、远程在线访谈、网络发布会等。
目前的网络直播一般是通过客户端主动从服务器上拉取数据来实现的，即通过不断刷新的方式，但每一次刷新，都会造成客户端的浏览器与服务器的连接断开，然后又重新连接。
由于客户端需要每隔几秒又重新到服务器拉取数据，在数据量小或用户不多的情况下，并没有什么问题，但如果当用户成倍增长，数据量极度膨胀时，这样就会因为大量获取重复数据，造成网络占用率高，网速过慢，无法达到大规模直播的需要。
发明内容本发明要解决的技术问题在于，针对现有技术的上述网络占用率高、无法达到大规模网络直播的缺陷，提供一种实现大容量网络直播的方法及其系统，有效地降低网络占用率并节约服务器资源。
本发明解决其技术问题所采用的技术方案是构造一种实现大容量网络直播的方法，该方法包括以下步骤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＝javascript>parent.addTalkMsg( )；</script>需要说明的是，直播页面是隐藏的，它的功能就是负责接收直播服务器发来的消息，并不负责消息的显示。但可以由一个单独的显示页面来实现，该页面是直播页面的父页面。显示页面上实现了addTalkMsg等函数。这样直播消息页面收到如<script language＝javascript>parent.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/18GK1992621SQ200510121375
公开日2007年7月4日 申请日期2005年12月27日
发明者吴双, 刘鹏 申请人:腾讯科技(深圳)有限公司导出引文BiBTeX, EndNote, RefMan