CN1921479A - 一种流媒体系统负荷分担方法及其系统 - Google Patents

Abstract

本发明公开了一种流媒体系统负荷分担方法及其系统，该方法包括：门户子系统实时监控各流媒体服务器的运行状态；终端向门户子系统发起一媒体文件列表请求，门户子系统生成一相关的媒体文件列表网页并发送至终端；终端根据媒体文件列表网页选择一待播放的媒体文件，门户子系统在各流媒体服务器中找寻能提供媒体文件服务的流媒体服务器，并根据能提供媒体文件服务的流媒体服务器的运行状态及负荷情况从中选择一负荷最轻流媒体服务器，再生成指向负荷最轻流媒体服务器的实时流协议的访问网址并发送至终端；终端根据访问网址发起向负荷最轻流媒体服务器的媒体访问，从而完成负荷分担。本发明实现负荷分担方便，并适合各种网络带宽要求的流服务等优点。

Description

一种流媒体系统负荷分担方法及其系统

技术领域

本发明涉及一种流媒体系统负荷的分担方法及其系统，特别是涉及一种在流媒体系统中实现多个流服务器间负荷分担的方法及其系统，适合建设从流媒体文件导航网站到流媒体文件播放完整的流媒体系统，并适合各种网络带宽要求的流服务。

背景技术

随着网络的发展，通过Internate网络欣赏音乐、电影、电视等逐渐普遍，目前已经有相关的国际标准通信协议，其中包括实时流协议RTSP(Real-timeStreaming Protocol)，以及遵循这些标准的流媒体播放器和流媒体服务器等相关设备。

提供这些带宽较宽的流服务需要系统有很强的处理能力，单台流媒体服务器一般不能满足大并发用户的需求，往往需要在一个流媒体系统中配置多台流服务器，这些流媒体服务器共同向终端提供服务，并且当某一台服务器故障时其他服务器分担其业务，整个系统能继续正常对外提供流服务。现在传统的服务器集群方案是利用四层交换机以及类似技术，其原理是所有的流媒体播放终端先将流服务器请求发送到四层交换机，由四层交换机将请求转发到流媒体服务器，流媒体服务器收到请求后再将媒体数据通过四层交换机转发给流媒体播放器，这种技术在WEB、WAP等带宽较窄的业务中运行较好，但并不很适合流媒体业务，原因是：

(1)、一个流媒体会话需要占用较宽的网络带宽，会话持续时间也比较长，四层交换机作为所有网络包的转发点往往成为整个系统的网络瓶颈，由于四层交换机的存在使得系统无法提供更多的并发请求支持。

(2)、四层交换机在系统中成为一个关键点，如果四层交换机本身发生故障将会影响整个系统对外提供服务，即便四层交换机做了冗余配置，四层交换机因故障发生切换时也会中断所有已经建立的流媒体播放会话，给用户带来不好的体验。

(3)、目前四层交换机技术要求所有流媒体服务器上提供的服务是等同的，也就是每个流媒体服务器都需要能提供系统所有的媒体文件访问，这给媒体存储带来一些比较高的要求。

(4)、四层交换机比较昂贵，特别是网络带宽较宽的四层交换机。

发明内容

本发明所要解决的技术问题在于提供一种流媒体系统负荷分担方法及其系统，用于解决现有四层交换机实现负荷分担所产生的系统网络瓶颈、流媒体播放中断、代价较高及不适于各种网络带宽要求的流服务等问题。

为了实现上述目的，本发明提供了一种流媒体系统负荷分担方法，应用于包括终端、流媒体服务器、门户子系统的流媒体系统，包括如下步骤：

所述门户子系统实时监控所述各流媒体服务器的运行状态；

所述终端向所述门户子系统发起一媒体文件列表请求，所述门户子系统生成一相关的媒体文件列表网页并发送至所述终端；

所述终端根据所述媒体文件列表网页选择一待播放的媒体文件，所述门户子系统在所述各流媒体服务器中找寻能提供所述媒体文件服务的流媒体服务器，并根据所述能提供所述媒体文件服务的流媒体服务器的运行状态及负荷情况从中选择一负荷最轻流媒体服务器，再生成指向所述负荷最轻流媒体服务器的实时流协议的访问网址并发送至所述终端；

所述终端根据所述访问网址发起向所述负荷最轻流媒体服务器的媒体访问，从而完成负荷分担。

所述的流媒体系统负荷分担方法，其中，所述门户子系统实时监控所述各流媒体服务器的运行状态的步骤又包括：

通过实时流协议的DESCRIBE命令向所述各流媒体服务器发出请求，指明根据所述各流媒体服务器是否正常应答判断所述各流媒体服务器工作是否正常；

通过所述门户子系统监听所述各流媒体服务器定时发过来的数据包，根据所述各流媒体服务器是否按时发送数据包来判断所述各流媒体服务器工作是否正常。

所述的流媒体系统负荷分担方法，其中，所述媒体文件列表网页中每个媒体文件的链接为指向所述门户子系统的网址。

所述的流媒体系统负荷分担方法，其中，所述数据包为HTTP数据包。

所述的流媒体系统负荷分担方法，其中，所述数据包还携带有所述各流媒体服务器的CPU占用率和/或当前并发会话数的负荷情况。

所述的流媒体系统负荷分担方法，其中，所述能提供所述媒体文件服务的流媒体服务器为负荷最轻流媒体服务器时，CPU最空闲，当前会话数最小。

所述的流媒体系统负荷分担方法，其中，所述流媒体服务器的数量及其在所述流媒体系统中所处的位置是可改变的。

本发明的另一目的是提供了一种流媒体系统负荷分担系统，包括终端、流媒体服务器、含有应用服务器的门户子系统，其中所述应用服务器又包括：

一门户导航模块，用于接收所述终端发起的一媒体文件列表请求，并生成一相关的媒体文件列表网页并发送至所述终端；

一负荷分担模块，用于当所述终端根据所述媒体文件列表网页选择一待播放的媒体文件时，在所述各流媒体服务器中找寻能提供所述媒体文件服务的流媒体服务器，并根据所述提供所述媒体文件服务的流媒体服务器的运行状态及负荷情况从中选择一负荷最轻流媒体服务器，再生成指向所述负荷最轻流媒体服务器的实时流协议的访问网址并发送至所述终端。

所述的流媒体系统负荷分担系统，其中，所述媒体文件列表网页中每个媒体文件的链接为指向所述门户子系统的网址。

所述的流媒体系统负荷分担系统，其中，所述能提供所述媒体文件服务的流媒体服务器为负荷最轻流媒体服务器时，CPU最空闲，当前会话数最小。

本发明实现负荷分担几乎不需增加额外成本；因不依赖特殊的网络设备，不会给系统引入新的关键点，所以本发明不会因为负荷分担而造成系统的性能瓶颈；比四层交换机故障给系统带来的影响小得多；由于负荷分担策略是用软件在门户子系统中实现，可支持的策略要比用四层交换机实现灵活很多，负荷分担不但可以做到区分不同流服务器提供不同文件内容服务情况，还可以允许将流媒体服务器放到网络其他地方，给系统组网带来更大的灵活性。

以下结合附图和具体实施例对本发明进行详细描述，但不作为对本发明的限定。

附图说明

图1为流媒体系统组网示意图；

图2为本发明一个负荷分担方法的流程图。

具体实施方式

本发明的目的是针对目前流行的四层交换机及其相似技术所存在的诸多问题，提供一种流媒体系统中流媒体服务器间负荷分担的实现方法，该方法较好解决了上面提到的所有问题。

本发明提出的一个完整的流媒体系统除了包含对外提供流服务的流媒体服务器外，流媒体服务器简称为流服务器，还应该有基于WEB、WAP等技术给用户提供媒体导航、信息查询等功能的门户子系统，用户使用流媒体业务一般都是通过WEB、WAP等浏览器访问流媒体系统的导航网页，找到想要欣赏媒体文件的相关链接，然后利用该链接发起流媒体服务请求。本发明充分利用这个特点，通过以下步骤实现流媒体服务器之间的负载均衡：

1)、门户子系统实时监控系统中各流媒体服务器的运行状态。

2)、用户通过门户子系统浏览媒体文件列表时，网页上代表每个媒体文件的链接并不是指向流媒体服务器的RTSP协议URL(Uniform Resource Locator，统一资源定位符或网页地址)，而是指向门户子系统本身一个负荷分担模块的一个URL。

3)、用户在浏览器中选中一个媒体文件，点击确认播放该文件时，实际上访问了门户子系统的负荷分担模块。

4)、门户子系统的负荷分担模块收到用户请求后，在能提供该媒体文件服务的流媒体服务器中，根据各个流媒体服务器运行状态以及负荷情况，选择负荷最轻的流媒体服务器，生成指向该流媒体服务器RTSP协议的访问URL，返回给终端。

5)、终端根据该URL发起向该流媒体服务器的媒体访问，整个负荷分担运算完成。

图1为流媒体系统组网示意图。从图1中可见流媒体系统中可以有多台流媒体服务器，此处流媒体服务器有流服务器1～5共5台，其中流服务器1～3在流媒体中心，流服务器4、5在网络边缘，整个系统流服务器数量位置不受负荷分担算法的限制，因此大大增强了组网灵活性。

图2为本发明一个负荷分担方法的流程图。负荷分担主要在门户子系统中实现。

本方法基于支持标准RTSP协议的终端、流媒体服务器来实施，下面说明以具有WAP2.0浏览器、高通公司QTV解决方案流媒体播放器的手机终端和APPLE公司QTSS流媒体服务器为例；相应的WAP门户以APACHE+TOMCAT集群和J2EE开发技术体系为例，APACHE+TOMCAT组成的集群方案中，任何一台服务器故障都不影响集群对WAP浏览器提供WAP服务，甚至可以做到任何一台服务器宕机不影响终端已经同服务器建立起来的会话，本发明的负荷分担方法可以在TOMCAT应用服务器上基于J2EE开发。

首先，门户子系统需要保存整个流媒体系统有多少台流媒体服务器，媒体流服务器供终端访问的IP地址是什么，如果各流媒体服务器存储的媒体文件不同，门户子系统还需要知道每个流媒体服务器可以提供哪些媒体文件的访问，这些信息可以用关系数据库来存储。参阅图2，下面介绍本发明的负荷分担方法。

步骤1：门户子系统中每个应用服务器都运行负荷分担模块23，应用服务器一启动，负荷分担模块23立即开始了解系统所有流媒体服务器24运行状态和当前负荷情况，实现这一功能有多种方式，比如负荷分担模块23可以通过RTSP的DESCRIBE命令(指明需要播放媒体的文件名)向流媒体服务器24发出请求，根据流媒体服务器24是否正常应答而判断该流媒体服务器24工作是否正常；也可以由负荷分担模块23监听各流媒体服务器24定时发过来的数据包(一般是HTTP包)，根据各流媒体服务器24是否按时发送数据包来判断各流媒体服务器24是否正常，当然数据包中还可携带有流媒体服务器24的负荷情况(CPU占用率，当前并发会话数)。各流媒体服务器24的运行状态信息存放在门户子系统中，所有应用服务器可以共享读取这些信息。

步骤2：终端21的WAP浏览器向应用服务器的门户导航模块22发送媒体文件列表请求，门户导航模块22生成相关媒体文件列表网页返回给WAP浏览器，这是一个标准的WAP业务请求流程，但网页中代表每个媒体文件的链接是一个指向门户子系统的HTTP URL，如可以是指向门户应用服务器的RTSPServlet这样一个Servlet，只是相关参数中携带媒体文件信息(比如文件名)。

步骤4：用户在网页上选择某个媒体文件要求播放，浏览器实际是向门户子系统RTSPServlet发起一个HTTP的Get请求，RTSPServlet根据URL参数中的文件信息查找数据库，获得可提供该文件媒体服务的所有流媒体服务器列表。

步骤5：RTSPServlet访问负荷分担模块23获取这些流媒体服务器24运行状态和负荷情况，从正常运行的流媒体服务器24中找一个负荷最轻的流服务器(一般可以是CPU最空闲、当前会话数最小)，生成如下所示的RTSP URL：

RTSP：//选中流服务器IP/用户要求播放媒体文件路径

步骤7：该RTSP URL返回给终端21，由终端21的浏览器自动运行手机上的流媒体播放器；

步骤8：流媒体播放器利用上述RTSP URL发起媒体访问请求，其目标流媒体服务器是上述所选择的负荷最轻的流媒体服务器，至此就完成了负荷分担整个流程，用户的下一次媒体文件选择将重复上述流程。

本发明的有益效果：

本发明的负荷分担是在门户子系统中通过软件实现的，门户子系统本来就是一个可运营流媒体系统必备的子系统，所以几乎没有增加额外成本，并且同样做到平时流媒体系统中多台流服务器负荷均匀分配，如果其中一台机器故障，其他服务器接管其负荷的需求。

与现有的四层交换机方案相比，该方法不依赖特殊的网络设备，不给系统引入新的关键点，所以不会因为负荷分担而造成系统的性能瓶颈，如果给系统增加新的流服务器，整个流媒体系统对外提供服务的能力将线性增加。

进一步地，由于门户子系统本身早就有成熟的集群方案，单台门户服务器故障不会影响门户子系统的正常功能，因而也就不会影响整个系统对用户提供服务，比四层交换机故障给系统带来的影响小得多。

进一步地，由于负荷分担策略是用软件在门户子系统中实现，可支持的策略要比用四层交换机实现灵活很多，负荷分担不但可以做到区分不同流服务器提供不同文件内容服务情况，还可以允许将流媒体服务器放到网络其他地方，比如网络边缘，以减小集中建设流媒体系统带来的流媒体系统出口网络瓶颈问题，给系统组网带来很大的灵活性。

当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (10)

1、一种流媒体系统负荷分担方法，应用于包括终端、流媒体服务器、门户子系统的流媒体系统，其特征在于，包括如下步骤：

所述门户子系统实时监控所述各流媒体服务器的运行状态；

所述终端向所述门户子系统发起一媒体文件列表请求，所述门户子系统生成一相关的媒体文件列表网页并发送至所述终端；

所述终端根据所述媒体文件列表网页选择一待播放的媒体文件，所述门户子系统在所述各流媒体服务器中找寻能提供所述媒体文件服务的流媒体服务器，并根据所述能提供所述媒体文件服务的流媒体服务器的运行状态及负荷情况从中选择一负荷最轻流媒体服务器，再生成指向所述负荷最轻流媒体服务器的实时流协议的访问网址并发送至所述终端；

所述终端根据所述访问网址发起向所述负荷最轻流媒体服务器的媒体访问，从而完成负荷分担。

2、根据权利要求1所述的流媒体系统负荷分担方法，其特征在于，所述门户子系统实时监控所述各流媒体服务器的运行状态的步骤又包括：

通过实时流协议的DESCRIBE命令向所述各流媒体服务器发出请求，根据所述各流媒体服务器是否正常应答判断所述各流媒体服务器工作是否正常；

通过所述门户子系统监听所述各流媒体服务器定时发过来的数据包，根据所述各流媒体服务器是否按时发送数据包来判断所述各流媒体服务器工作是否正常。

3、根据权利要求1或2所述的流媒体系统负荷分担方法，其特征在于，所述媒体文件列表网页中每个媒体文件的链接为指向所述门户子系统的网址。

4、根据权利要求2所述的流媒体系统负荷分担方法，其特征在于，所述数据包为HTTP数据包。

5、根据权利要求2或4所述的流媒体系统负荷分担方法，其特征在于，所述数据包还携带有所述各流媒体服务器的CPU占用率和/或当前并发会话数的负荷情况。

6、根据权利要求1、2或4所述的流媒体系统负荷分担方法，其特征在于，所述能提供所述媒体文件服务的流媒体服务器为负荷最轻流媒体服务器时，CPU最空闲，当前会话数最小。

7、根据权利要求1、2或4所述的流媒体系统负荷分担方法，其特征在于，所述流媒体服务器的数量及其在所述流媒体系统中所处的位置是可改变的。

8、一种流媒体系统负荷分担系统，包括终端、流媒体服务器、含有应用服务器的门户子系统，其特征在于，所述应用服务器又包括：

一门户导航模块，用于接收所述终端发起的一媒体文件列表请求，并生成一相关的媒体文件列表网页并发送至所述终端；

一负荷分担模块，用于当所述终端根据所述媒体文件列表网页选择一待播放的媒体文件时，在所述各流媒体服务器中找寻能提供所述媒体文件服务的流媒体服务器，并根据所述提供所述媒体文件服务的流媒体服务器的运行状态及负荷情况从中选择一负荷最轻流媒体服务器，再生成指向所述负荷最轻流媒体服务器的实时流协议的访问网址并发送至所述终端。

9、根据权利要求8所述的流媒体系统负荷分担系统，其特征在于，所述媒体文件列表网页中每个媒体文件的链接为指向所述门户子系统的网址。

10、根据权利要求8或9所述的流媒体系统负荷分担系统，其特征在于，所述能提供所述媒体文件服务的流媒体服务器为负荷最轻流媒体服务器时，CPU最空闲，当前会话数最小。