CN110300306A - 基于rtmp协议直播流负载均衡算法 - Google Patents

Abstract

本发明公开了一种基于RTMP协议的直播流负载均衡具体实现算法。在多台流媒体分发服务器部署的工程应用场景中，通过该负载均衡处理算法，可以完成不同直播流的业务均匀分摊到工程中的所有流媒体分发服务器，保证服务器硬件资源利用最大化，有效解决因单点故障导致直播业务无法正常支持的问题；同时，该算法也支持针对多客户端重复请求相同的直播流在流媒体分发服务端进行重用与分发，减少直播流提供方压力，优化直播流播放效率。

Description

基于RTMP协议直播流负载均衡算法

技术领域

本发明涉及直播流领域，尤其涉及一种基于RTMP协议直播流负载均衡算法。

背景技术

基于RTMP协议直播流一般用来做直播流，用于一些电视台的直播地址，省时省力；但只适用于直播、点播等方面，不适用多场景、多视频播放等功能。不支持直播流复用，也不能很好支持多播放器同时播放等功能。

发明内容

本发明的目的是针对现有技术的缺陷，提供了一种的基于RTMP协议直播流负载均衡算法，其能对直播流进行可复用，多分发的功能，来支持多个人电脑端和移动设备端的实时播放，并对实时播放采用负载均衡的模式，使播放资源利用最大化，对请求重复的实时流视频资源进行复用，优化播放效率。

为了实现以上目的，本发明采用以下技术方案：

基于RTMP协议直播流负载均衡算法，包括以下步骤：

S0：用户通过直播流请求方发起音视频播放请求，请求信息包括但不限于：直播流提供方在业务系统中唯一标识符；

S1：负载均衡处理服务接受用户请求并在系统内部为该请求产生唯一的请求会话信息，会话信息核心数据包括：请求唯一会话标识符、请求视频源标识符、业务状态、音视频数据流播放地址，其中“业务状态”初始值为“请求态”，“音视频数据流播放地址”初始值为空，根据负载均衡算法进行“业务状态”与“音视频数据流播放地址”数据修订；

S2:负载均衡处理服务中的计算任务调度子模块获取所有“业务状态”为“请求态”的请求会话，并将该会话信息中的“业务状态”修订为“计算态”，然后将计算任务依据会话信息中的“请求视频源标识符”进行分组，用于支持“相同视频资源”的请求进行视频流的复用与分发，将分组后的计算任务，提交给不同的计算任务处理子模块进行计算处理；

S3：负载均衡处理服务中的计算任务处理子模块获取计算任务集合中的首个请求会话信息，解析请求会话信息中的视频资源进行负载均衡的计算处理；

S4：计算任务处理子模块通过负载均衡处理算法计算当前视频资源的音视频数据流播放地址；

S5：计算任务处理子模块判断音视频数据流地址是否属于可复用地址：若是，则直接修订会话信息中的“音视频数据流播放地址”为该音视频数据流地址并将“业务状态”修改为“可播放态”，直播流请求方依据该音视频数据流地址进行视频直播；若不是，先修订会话信息中的“音视频数据流播放地址”为该音视频数据流地址但不修订“请求状态”，然后由网络服务子模块向“直播流提供方”发起视频流请求信令；

S6：若视频流请求信令执行成功，此时“直播流提供方”会将该视频数据推送到“音视频数据流播放地址”上，计算任务处理子模块则修订会话信息中的“业务状态”为“可播放态”，直播流请求方可以依据该音视频数据流地址进行视频直播，同时计算任务处理子模块则继续处理下一条请求记录；

S7：若视频流请求信令执行失败，则计算任务处理子模块会删除该会话信息，直播流请求方因无法查询到会话信息导致请求失败，同时计算任务处理子模块继续处理下一条请求记录。

进一步的，任务调度子模块、计算任务处理子模块、网络服务子模块均采用多线程或者是多进程方式进行实现。

进一步的，S4中，负载计算的基础依据：集群系统中流媒体分发服务器的负载能力，单台流媒体分发服务器的负载能力按照已经支持的直播流路数为基准，或按照单台服务器网卡输出的网络流量为基准，载信息以负载均衡服务同步流媒体分发服务的负载数据为基础进行计算。

进一步的，S4中，负载计算处理流程如下：

S41：依据请求视频源标识符在会话集合中进行查询，检索条件：请求视频源标识符+业务状态,业务状态为“可播放态”或“播放态”，检索结果有如下情况：

(a)检索结果为空：资源没有请求；

(b)检索结果不为空：资源已经被请求过；

S42：针对检索结果(a)处理流程如下：

Sa1查询当前所有在线的流媒体服务器地址；

Sa3计算当前在线并且负载最轻的流媒体服务器即为支持业务的流媒体服务器，生成音视频数据流地址；

Sa4如果当前所有在线流媒体服务器负载均到达上限则计算失败；

S43：针对检索结果(b)处理流程如下：

Sb1查询当前所有在线的流媒体服务器地址；

Sb2统计检索结果，计算所有检索结果关联的流媒体服务器地址；

Sb3过滤掉检索结果中不在线的流媒体服务器地址，剩下的即为在线并且承载该路业务的流媒体服务器地址集合；

Sb4遍历该集合，统计该流媒体服务器地址相关的负载数量；

Sb5如果统计结果中所有流媒体服务负载均满，则依据步骤二进行处理；如果统计结果中有流媒体服务器可以承载业务即没有达到上限，则取负载最轻的流媒体服务器地址，返回已经存在的音视频数据流地址。

采用本发明技术方案，本发明的有益效果为：与现有技术相比，本发明的有益效果是：

1、本发明不再是传统的一对一模式：本发明使用多对多的业务模式，可以对资料使用最大化，容错率更高，更合理；任何终端都可以访问任何的视频资源，不会导致资源占用情况；如果有单个流媒体服务器停止工作后，可以保证视频流资源正常被访问。

2、本发明可以使视频资源，重复使用：本发明多个终端都可以访问同一视频资源，不会造成多次访问服务资源；同一视频资源提供服务，对稳定性有一定的提高

3、本发明采用负载均衡设计，使系统健壮性更高，更稳当，更能提高程序效率：本发明优化了访问请求在服务器组之间的分配，消除了服务器之间的负载不平衡，从而提高了系统的反应速度与总体性能；可以对服务器的运行状况进行监控，及时发现运行异常的服务器，并将访问请求转移到其它可以正常工作的服务器上，从而提高服务器组的可靠性；可以根据业务量的发展情况灵活增加服务器，系统的扩展能力得到提高，同时简化了管理。

附图说明

图1是本发明提供的基于RTMP协议直播流负载均衡算法实施例一示意图；

图2是本发明提供的基于RTMP协议直播流负载均衡算法实施例二示意图；

图3是本发明提供的基于RTMP协议直播流负载均衡算法应用场景示意图；

图4是本发明提供的基于RTMP协议直播流负载均衡算法实施例应用场景计算音视频数据流地址流程图。

具体实施方式

结合附图对本发明具体方案具体实施例作进一步的阐述。

基于RTMP协议直播流负载均衡算法，包括以下步骤：

S0：用户通过直播流请求方发起音视频播放请求，请求信息包括但不限于：直播流提供方在业务系统中唯一标识符；

S1：负载均衡处理服务接受用户请求并在系统内部为该请求产生唯一的请求会话信息，会话信息核心数据包括：请求唯一会话标识符、请求视频源标识符、业务状态、音视频数据流播放地址，其中“业务状态”初始值为“请求态”，“音视频数据流播放地址”初始值为空，根据负载均衡算法进行“业务状态”与“音视频数据流播放地址”数据修订；

S2:负载均衡处理服务中的计算任务调度子模块获取所有“业务状态”为“请求态”的请求会话，并将该会话信息中的“业务状态”修订为“计算态”，然后将计算任务依据会话信息中的“请求视频源标识符”进行分组，用于支持“相同视频资源”的请求进行视频流的复用与分发，将分组后的计算任务，提交给不同的计算任务处理子模块进行计算处理；

S3：负载均衡处理服务中的计算任务处理子模块获取计算任务集合中的首个请求会话信息，解析请求会话信息中的视频资源进行负载均衡的计算处理；

S4：计算任务处理子模块通过负载均衡处理算法计算当前视频资源的音视频数据流播放地址；

S5：计算任务处理子模块判断音视频数据流地址是否属于可复用地址：若是，则直接修订会话信息中的“音视频数据流播放地址”为该音视频数据流地址并将“业务状态”修改为“可播放态”，直播流请求方可以依据该音视频数据流地址进行视频直播；若不是，先修订会话信息中的“音视频数据流播放地址”为该音视频数据流地址但不修订“请求状态”，然后由网络服务子模块向“直播流提供方”发起视频流请求信令；

S6：若视频流请求信令执行成功，此时“直播流提供方”会将该视频数据推送到“音视频数据流播放地址”上，计算任务处理子模块则修订会话信息中的“业务状态”为“可播放态”，直播流请求方可以依据该音视频数据流地址进行视频直播，同时计算任务处理子模块则继续处理下一条请求记录；

S7：若视频流请求信令执行失败，则计算任务处理子模块会删除该会话信息，直播流请求方因无法查询到会话信息导致请求失败，同时计算任务处理子模块继续处理下一条请求记录。

任务调度子模块、计算任务处理子模块、网络服务子模块均采用多线程或者是多进程方式进行实现。

S4中，负载计算的基础依据：集群系统中流媒体分发服务器的负载能力，单台流媒体分发服务器的负载能力按照已经支持的直播流路数为基准，或按照单台服务器网卡输出的网络流量为基准，载信息以负载均衡服务同步流媒体分发服务的负载数据为基础进行计算。

S4中，负载计算处理流程如下：

S41：依据请求视频源标识符在会话集合中进行查询，检索条件：请求视频源标识符+业务状态,业务状态为“可播放态”或“播放态”，检索结果有如下情况：

(a)检索结果为空：资源没有请求；

(b)检索结果不为空：资源已经被请求过；

S42：针对检索结果(a)处理流程如下：

Sa1查询当前所有在线的流媒体服务器地址；

Sa3计算当前在线并且负载最轻的流媒体服务器即为支持业务的流媒体服务器，生成音视频数据流地址；

Sa4如果当前所有在线流媒体服务器负载均到达上限则计算失败；

S43：针对检索结果(b)处理流程如下：

Sb1查询当前所有在线的流媒体服务器地址；

Sb2统计检索结果，计算所有检索结果关联的流媒体服务器地址；

Sb3过滤掉检索结果中不在线的流媒体服务器地址，剩下的即为在线并且承载该路业务的流媒体服务器地址集合；

Sb4遍历该集合，统计该流媒体服务器地址相关的负载数量；

Sb5如果统计结果中所有流媒体服务负载均满，则依据步骤二进行处理；如果统计结果中有流媒体服务器可以承载业务即没有达到上限，则取负载最轻的流媒体服务器地址，返回已经存在的音视频数据流地址。

如图1所示，实施例一、本发明直播流可重复配置举例如下，

以个人电脑端和移动设备端为例：

移动设备8可以通过网络设备产生视频流，并推送到流媒体分发服务器中，然后其他终端通过请求获取到音视频数据流来请求播放移动设备8的实时流。

场景1：个人电脑1要访问移动设备8的实时视频，具体步骤如下：

1.移动设备8移动设备8通过网络设备，产生实时视频流；

2.移动设备8移动设备8把实时音视频流推送到流媒体分发服务器上；

3.其他终端个人电脑1请求移动设备8的实时视频，网络内容系统服务器会通过流媒体分发服务器来计算出一个音视频数据流地址；

4.个人电脑1获取音视频数据流地址来访问移动设备8的实时视频；

经过以上4步就完成了个人电脑1访问移动设备8实时视频的过程。

场景2：个人电脑1和移动设备1都要访问移动设备8的实时视频，具体步骤如下：

1.移动设备1通过网络设备，产生实时视频流；

2.移动设备1把实时视频流推送到流媒体分发服务器上；

3.其他终端个人电脑1和移动设备1请求移动设备8的实时视频，网络内容系统服务器会通过流媒体分发服务器来计算出一个音视频数据流地址；

4.个人电脑1和移动设备1获取音视频数据流地址来访问移动设备8的实时视频。

经过以上4步就完成了个人电脑1和移动设备1访问移动设备8实时视频的过程。

实施例二，如图2所示，实施例、本发明的直播流负载均衡算法配置举例如下：

移动设备1、移动设备2、移动设备3、移动设备4、移动设备5、移动设备6都可以播放音视频流；网络设备产生视频流，传输给移动设备端，然后移动设备端推送流到流媒体分发服务器1、流媒体分发服务器2、流媒体分发服务器N中，然后其他个人电脑、移动设备通过负载均衡模块获取到音视频数据流地址来请求播放移动设备的实时流

场景1：个人电脑1拉流要访问移动设备1的实时视频：

1.移动设备1发送推流请求到网络内容系统服务；

2.网络内容系统服务通过计算发送推流请求到流媒体分发服务器中；

3.个人电脑1通过拉流请求到负载均衡处理服务，负载均衡处理服务返回音视频数据流地址给个人电脑1端；

4.个人电脑1端通过音视频数据流地址请求流，并实现视频播放。

经过以上4步就完成了个人电脑1访问移动设备1实时视频的过程。

场景2：个人电脑1和移动设备7都要访问移动设备1、移动设备4的实时视频：

1.移动设备1、移动设备7通过网络设备，产生实时视频流；

2.移动设备1、移动设备7把实时视频流推送到多个不同流媒体分发服务器上；

3.其他终端个人电脑1和移动设备7请求移动设备1、移动设备4的实时视频，网络内容系统服务器会通过负载均衡处理服务来计算出一个音视频数据流地址；

4.个人电脑1和移动设备7获取音视频数据流地址来访问移动设备1、移动设备4的实时视频。

经过以上4步就完成了个人电脑1和移动设备7访问移动设备1、移动设备4实时视频的过程。

实施例三、如图3所示，本发明应用场景如下：

播放客户端播放视频，发送请求到网络内容服务获取音视频数据流地址，根据音视频数据流地址来播放视频资源，发布客户端推送音视频数据流到媒体分发服务器；供播放客户端播放流具体步骤如下：

1：播放客户端给网络内容服务发起请求获取音视频数据流地址，网络内容服务再给负载均衡服务发送请求，负载均衡服务再通过判断媒体分发服务器工作状态来产生音视频数据流地址，产生的音视频数据流地址通过负载均衡服务返回给网络内容服务，网络内容服务再音视频数据流地址返回给播放客户端。

2：播放客户端给网络内容服务发起请求获取音视频数据流地址，网络内容服务再给负载均衡服务发送请求，负载均衡服务再通过判断媒体分发服务器工作状态来产生音视频数据流地址，产生的音视频数据流地址通过负载均衡服务返回给网络内容服务；网络内容服务再发布流请求给发布客户端，发布客户端根据音视频数据流地址，推送音视频数据流给媒体分发服务器，供播放客户端拉流使用。

3：最后，发布客户端推送音视频数据流给媒体分发服务器，播放客户端从媒体分发服务器中拉取音视频数据流来播放。

实施例四、如图4所示，应用场景计算音视频数据流地址如流程图所示：

计算音视频数据流地址，参数包括会话标识和资源ID。根据资源ID、播放状态查找请求表，播放状态问可播放和播放态，若查找存在，则进行下述步骤：

1.遍历播放表，统计播放表中所有在线并播放该资源的服务器总负载和该资源的播放数量，包括IP，总负载，播放数量，统计播放表中所有在线服务器总负载，包括IP，总负载。

2.判断IP，总负载，播放数量是否为零，这里的数量为零表示有请求但播放还未完成，若是，则复用请求表中的音视频数据流地址，返回成功；

3.上一步骤若判断为否，则在IP，总负载，播放数量列表中遍历查找不需要转载的服务器，选择总负载未达到总负载转载水位和播放器数量未到达单路转载水位的服务器，存在多个U币需要转载的服务器时先比较总负载，总负载小的出流，总负载相同，则比较播放数量，播放数量小的出流，两个数量都相同，则取任意一个出流。

4.判断上述记录是否存在，若是，则构件播放音视频数据流地址，返回成功。

如查找不存在，则进行下述步骤：

1.根据播放表获取总负载最轻的服务器；

2.对负载数量是否超过上限进行判断，若是，则返回失败，若否，则构件播放音视频数据流地址，返回成功。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (4)

1.基于RTMP协议直播流负载均衡算法，其特征在于，包括以下步骤：

S0：用户通过直播流请求方发起音视频播放请求，请求信息包括：直播流提供方在业务系统中唯一标识符；

S1：负载均衡处理服务接受用户请求并在系统内部为该请求产生唯一的请求会话信息，会话信息核心数据包括：请求唯一会话标识符、请求视频源标识符、业务状态、音视频数据流播放地址，其中“业务状态”初始值为“请求态”，“音视频数据流播放地址”初始值为空，根据负载均衡算法进行“业务状态”与“音视频数据流播放地址”数据修订；

S2:负载均衡处理服务中的计算任务调度子模块获取所有“业务状态”为“请求态”的请求会话，并将该会话信息中的“业务状态”修订为“计算态”，然后将计算任务依据会话信息中的“请求视频源标识符”进行分组，用于支持“相同视频资源”的请求进行视频流的复用与分发，将分组后的计算任务，提交给不同的计算任务处理子模块进行计算处理；

S3：负载均衡处理服务中的计算任务处理子模块获取计算任务集合中的首个请求会话信息，解析请求会话信息中的视频资源进行负载均衡的计算处理；

S4：计算任务处理子模块通过负载均衡处理算法计算当前视频资源的音视频数据流播放地址；

S5：计算任务处理子模块判断音视频数据流地址是否属于可复用地址：若是，则直接修订会话信息中的“音视频数据流播放地址”为该音视频数据流地址并将“业务状态”修改为“可播放态”，直播流请求方依据该音视频数据流地址进行视频直播；若不是，先修订会话信息中的“音视频数据流播放地址”为该音视频数据流地址但不修订“请求状态”，然后由网络服务子模块向“直播流提供方”发起视频流请求信令；

S6：若视频流请求信令执行成功，此时“直播流提供方”会将该视频数据推送到“音视频数据流播放地址”上，计算任务处理子模块则修订会话信息中的“业务状态”为“可播放态”，直播流请求方可以依据该音视频数据流地址进行视频直播，同时计算任务处理子模块则继续处理下一条请求记录；

S7：若视频流请求信令执行失败，则计算任务处理子模块会删除该会话信息，直播流请求方因无法查询到会话信息导致请求失败，同时计算任务处理子模块继续处理下一条请求记录。

2.如权利要求1所述的基于RTMP协议直播流负载均衡算法，其特征在于：任务调度子模块、计算任务处理子模块、网络服务子模块均采用多线程或者是多进程方式进行实现。

3.如权利要求1所述的基于RTMP协议直播流负载均衡算法，其特征在于：

S4中，负载计算的基础依据：集群系统中流媒体分发服务器的负载能力，单台流媒体分发服务器的负载能力按照已经支持的直播流路数为基准，或按照单台服务器网卡输出的网络流量为基准，载信息以负载均衡服务同步流媒体分发服务的负载数据为基础进行计算。

4.如权利要求1所述的基于RTMP协议直播流负载均衡算法，其特征在于，

S4中，负载计算处理流程如下：

S41：依据请求视频源标识符在会话集合中进行查询，检索条件：请求视频源标识符+业务状态,业务状态为“可播放态”或“播放态”，检索结果有如下情况：

(a)检索结果为空：资源没有请求；

(b)检索结果不为空：资源已经被请求过；

S42：针对检索结果(a)处理流程如下：

Sa1查询当前所有在线的流媒体服务器地址；

Sa3计算当前在线并且负载最轻的流媒体服务器即为支持业务的流媒体服务器，生成音视频数据流地址；

Sa4如果当前所有在线流媒体服务器负载均到达上限则计算失败；

S43：针对检索结果(b)处理流程如下：

Sb1查询当前所有在线的流媒体服务器地址；

Sb2统计检索结果，计算所有检索结果关联的流媒体服务器地址；

Sb3过滤掉检索结果中不在线的流媒体服务器地址，剩下的即为在线并且承载该路业务的流媒体服务器地址集合；

Sb4遍历该集合，统计该流媒体服务器地址相关的负载数量；

Sb5如果统计结果中所有流媒体服务负载均满，则依据步骤二进行处理；如果统计结果中有流媒体服务器可以承载业务即没有达到上限，则取负载最轻的流媒体服务器地址，返回已经存在的音视频数据流地址。