基于开源架构的流媒体静态集群应用研究

林 旻

(南京审计大学 实验中心，南京 211815)

在5G移动网络技术高速发展以及教育部大力推动在线课程的大背景下，慕课、微课、直播课等一系列线上教学途径成为高等教育教学模式的一部分。南京审计大学教育技术中心紧跟现代教育技术的发展步伐，设计并建设了一套基于开源架构的课程直播平台，积累了丰富的直播教学资源和实施经验，为师生的教学活动提供了新的途径，拓宽了教学活动的空间属性。

随着校内直播教学的不断发展，越来越多的教学活动通过线上直播的方式开展，原本单个服务器直播平台的性能已经无法满足教学需求，出现了播放卡顿、延迟高等问题。为了满足伴随教学活动日益增长的并发性能需求，基于开源架构的流媒体静态集群方案，通过多组服务器之间的互相协同来提高直播平台的并发性能，有效降低系统延迟，解决视频观看时的卡顿问题[1]。

1 技术介绍

NRM(Nginx-Rtmp-Module)是基于Nginx的开源流媒体模块。Nginx是基于BSD开源协议的高性能Web服务器平台，具有占用资源少、稳定性高、数据处理量大等特点。而Rtmp-module是Github开源软件平台的著名流媒体平台，支持RTMP和HLS流媒体协议，能够实现视频流的点播、直播、存储和转发等功能[2]。

流媒体服务器(Streaming Media Server)负责直播视频流的接收、存储和转发。流媒体服务器对CPU和内存资源的消耗较小，但对IO和网络资源的消耗较高。

静态转推：假设两台流媒体服务器A和B，A收到视频流S后，将S推送到B，这种情况被称为转推，因为转推地址是固定在流媒体服务器的配置文件中，不能动态调整，所以称作静态转推。静态转推的工作流程如图1所示。

图1 静态转推示意图

静态回源：假设两台流媒体服务器A和B，A上存在视频流S，当用户向B请求S，由于B上不存在S，所以B需要向A拉取S，这种情况被称作回源，因为回源地址是固定在流媒体服务器的配置文件中，不能动态调整，所以称作静态回源。静态回源的工作流程如图2所示。

图2 静态回源示意图

源服务器：负责接收OBS或其他直播推流软件的流媒体服务器，源服务器在接收到视频流后，会根据服务器中的固定配置将视频流推送给边缘服务器。

边缘服务器：为直播呈现平台(Web端、移动端)提供视频分发功能的流媒体服务器，在静态集群中，任意一台边缘服务器中都存着系统中所有的视频流。

2 基于NRM的流媒体服务器设计与实现

流媒体静态集群由一组相互独立又互相协作的流媒体服务器节点组成，我们的研究是在学校原有的开源直播平台上做升级改进。学校原有的流媒体服务器由Nginx-Rtmp-Module搭建，为了满足全平台播放(PC端+移动端)的要求，需要支持RTMP和HLS两种视频流协议，核心代码配置如下：

配置RTMP和HLS视频流

rtmp {

server {

listen 1935; #监听的端口

chunk_size 4096; #设置流整合大小

application lablive { #rtmp推流请求路径

live on; #开启直播

hls on; #开启HLS视频流

hls_path /usr/local/lablive/hlsFile; #设置HLS切片文件保存路径

hls_fragment 5s; #设置HLS分段长度

hls_playlist_length 10s; #设置HLS播放列表长度

}

}

}

在http标签下增加一个location，具体代码如下：

location /labhls {

types {

application/vnd.apple.mpegurl m3u8;

video/mp2t ts; #设置封闭格式

}

alias /usr/local/lablive/hlsFile; #设置文件位置

add_header Cache-Control no-cache; #设置缓存机制

add_header Access-Control-Allow-Origin *; #解决跨域

}

实际使用中，教师通过OBS或其他直播推流软件向NRM流媒体服务器推送视频流，直播呈现平台也从同一个NRM流媒体拉取视频流并播放给学生进行直播教学。NRM单流媒体服务器的具体的推流和拉流地址如表1所示。

表1 单个流媒体服务器的推拉流地址

根据流媒体服务器的数据处理特点，单个流媒体服务器在实际工作过程中的并发性能不仅受到服务器本身硬件(CPU的个/核数、内存资源等)的影响，还受到I/O硬能和网络资源的影响，特别是当流媒体服务器宕机或者网络出现故障的时候，整体的直播服务都将被迫停止[3]。所以需要通过多个流媒体服务器组成直播服务集群来提高系统整体的并发性、安全性和可靠性。

3 静态流媒体集群的设计与实现

静态流媒体集群是一种较为简单的流媒体集群方案，能够将单个流媒体服务器的出口压力分摊到多个流媒体服务器上[4]。集群中设有一台源服务器和多台边缘服务器，源服务器负责专门接收视频流并转推到其他边缘服务器上，集群中每一台边缘流媒体服务器上存在着相同的视频流，用户可以从任意一台边缘流媒体服务器上拉取视频流，集群中所有的转推和回源操作都固定设置在每个流媒体服务器的配置文件中，所以称作静态流媒体集群。静态流媒体集群具体结构如图3所示。

图3 静态集群示意图

在实际设计时，采用了一台源服务器来接收视频流，两台边缘服务器向用户提供视频流，具体配置如表2所示。

表2 静态集群服务器配置表

静态转推操作的实现主要采用Nginx-Rtmp-Module提供的push_module，让源服务器将接收到的视频流推送给边缘服务器，源服务器具体配置如下：

rtmp {

server {

listen 1935; #监听的端口

chunk_size 4096;

application lablive { #rtmp推流请求路径

live on;

push rtmp://172.24.200.47:1935/lablive; #转推到边缘服务器1

push rtmp://172.24.200.48:1935/lablive; #转推到边缘服务器2

hls on;

hls_path /usr/local/lablive/hlsFile; #设置HLS切片文件保存路径

hls_fragment 5s; #设置HLS分段长度

hls_playlist_length 10s; #设置HLS播放列表长度

}

}

}

静态回源操作的实现主要采用Nginx-Rtmp-Module提供的pull_module，让边缘服务器向源服务器拉取视频流，边缘服务器具体配置如下：

rtmp {

server {

listen 1935;#监听的端口

chunk_size 4096;

application lablive {

live on;

pull rtmp://172.24.200.46:1935/lablive;

hls on;

hls_path /usr/local/lablive/hlsFile; #设置HLS切片文件保存路径

hls_fragment 5s; #设置HLS分段长度

hls_playlist_length 10s; #设置HLS播放列表长度

}

}

}

实际使用中，教师通过OBS或其他直播推流软件向源服务器推送视频流，直播呈现平台从边缘服务器拉取视频流并播放给学生学习。具体的推流和拉流地址如表3所示。

表3 静态集群推拉流地址

相较于单个流媒体服务器，静态集群中每个边缘流媒体服务器中都存在相同的视频流，用户可以从任意一台边缘服务器上拉取视频流，同时边缘服务器还可以根据直播服务的带宽需求进行数量调整，可伸缩性强、可靠性高。

4 性能测试与分析

使用OBS作为推流软件分别对单个流媒体服务器和静态集群中源服务器进行推流，使用ST-Load作为负载测试工具分别对单个流媒体服务器和静态集群中的每个边缘服务器进行并发负载测试，考虑到NRM架构的特点和校内直播课程的实际使用人数需求，为了避免服务器负载过高，设置为单个进程模拟1 000个客户端进行并发测试，RTMP和HLS负载测试参数如表4、表5所示：

表4 RTMP负载测试参数

表5 HLS负载测试参数

通过测试发现，在相同硬件配置和相同拉流连接数的情况下，单个流媒体服务器和静态集群中单个边缘服务器负载能力相当，所以单个流媒体服务器的并发性能数是Publisher(Single)，那么静态集群单个连接服务器的并发数即是Publisher(Eedg)。

假设静态集群中的服务器总数量(源服务器+边缘服务器)为M，因为集群中最少应当存在一台源服务器和两台边缘服务器，所以M≥=3，静态集群的总并发数为：

Publisher(Cluster)=Publisher(E)*(M-1)> Publisher(E)*(2)>Plublisher(S)

当静态集群根据直播业务的并发需求调整边缘服务器数量时，假设调整数量为N，当调整为增加服务器数量时N>1，那么静态集群的总并发数为：

Publisher(Cluster)=Publisher(E)*(M+N-1)>>Plubisher(S)

当边缘服务器的调整为减少服务器数量时，减少的数量受到集群最小服务器数量的限制，所以M-N>=3，那么静态集群的总并发数为：

Publisher(Cluster)=Publisher(E)*(M-N-1)> Publisher(E)*(2)Plubisher(S)

5 结论

相较于单个流媒体服务器，静态集群可以根据直播服务的需求灵活调整边缘服务器的数量，不仅有效提高了直播平台的整体并发性，还能降低服务器硬件资源的浪费。同时，集群中任意一台边缘服务器的宕机或故障不会影响系统整体服务的有序进行，提高了直播平台的可靠性。

但是，正因为静态集群中每一个边缘服务器都存在着相同的视频流，所以在实际生产业务中，边缘服务器会存在用户不需要的视频流，造成隐形的资源浪费；同时，根据静态集群的逻辑特点，当源服务器出现故障时整个直播系统都将被迫瘫痪，存在一定的安全隐患，所以如何解决边缘服务器的隐形资源浪费和源服务器的安全隐患是本项目进一步研究的目标。