CN111613234B - 一种多阶段流调度方法、系统及其装置 - Google Patents

Abstract

本发明公开了一种多阶段流调度方法、系统及其装置，其方法包括首先在配置文件中将处理端信息配置好，包括处理端IP、PORT，以及C处理端的GPU标志；启动策略模块，策略模块读取配置文件，获取处理端A/B/C的IP、端口等，本调度方案充分利用各个阶段的码流，可以实现引用其他阶段流生成后续阶段需要的码流类型，或者阶段流在不同服务器间分发，然后充分利用服务器特性处理特定阶段流，譬如GPU服务器，可以特定处理解码、编码过程。这样的好处是减少某些阶段流重复生成工作，节省服务器性能，并且可以利用特定服务器处理特定阶段流，加快效率。

Description

一种多阶段流调度方法、系统及其装置

技术领域

本发明涉及安防领域，尤其是涉及一种多阶段流调度方法、系统及其装置。

背景技术

在安防行业，传统的流媒体服务器将分发和转码功能分开部署，传统的场景下，摄像机的码流都是统一的，流行的趋势也是统一的。随着安防行业的发展，已经出现了很多代摄像机，编码类型从mpeg2/mpeg4、H264到现在H265各种都有，并且终端播放设备所要求编码封装类型也是多种多样的，这就给平台集成商带来了很大的对接困扰。对于集成商来说，将码流整合统一类型输出，变成必要的工作。

现有技术方案是搭建转码服务器，使用调度模块，找到一个状态最佳的服务器，将输入流进行转码，输出到前端设备播放或者进行分发。但是不同的终端要求码流类型是不同的，譬如PC端需要PS类型，网页端需要SRTP类型，此时转码服务器需要对同一路码流做重复转码的工作，形成不同的类型，这种设计就造成服务器性能浪费。这是由于转码是个多阶段处理的过程，譬如解码、滤镜、编码等，不是只有输入和输出组成，而现有的调度方案，都是针对输入、输出两个阶段匹配和服务器性能综合考虑的，对于其他阶段的流，是无法利用或者服务器间共享的，这造成极大的浪费。

现有的调度方案，有基于流量请求的DNS调度，基于网络层负载的LVS调度，基于应用层的nginx调度，基于码流输入输出阶段的分发调度，这些调度方案，都是为了均衡服务器负载或者选择性能最佳服务器的方案。码流转码是处理一路流产生多阶段流的过程，顺序是原始流、解封装、解码、滤镜、编码、封装。在调度策略中，不仅要要考虑服务器的实际负载能力，还要考虑一个新请求与已有请求的业务相关性，譬如引用已有请求的某个阶段流，譬如解码阶段流，生成新请求需要的编码码流。综合考虑码流各个阶段流的这种业务相关性和服务器性能的调度方案，当前是没有的。

发明内容

本发明为克服上述情况不足，旨在提供一种能解决上述问题的技术方案，通过此调度方案，可以充分利用一路流的各个阶段流，提高转码效率，节省服务器性能，可以更好的利用服务器特性，让专有的服务器生成特定阶段的码流。

一种多阶段流调度方法，具体包括以下步骤:

S1,在配置文件中配置处理端的信息，包括处理端服务器IP，处理端监听端口，以及服务器特性，譬如性能参数、外网、GPU运行状态等；

S2,策略模块通过tcp协议主动连接处理端，发送check协议，获取处理端服务器的基本信息；

S3,上级notify请求到来，策略模块根据notify的源信息，建立树结构，保存源信息；根据目的信息，判断对源码流的处理流程，包含解封装、解码、滤镜、编码、封装中的一个或多个流程，并将这些阶段流保存到源信息树上；

S4,在所有处理端中查找一个或多个性能最佳的服务器，将上述的notify请求转发过去，并告知需要生成哪些阶段流，和策略模块保持完全一致；查找一个或多个服务器的原因是，根据服务器的特性，比如外网、GPU等做一些优化处理，会有多个服务器处理不同阶段，然后整合输出；

S5,收集处理端的响应时间，作为选择处理端的一个判断条件。如果服务器超时，做特殊记录，会触发报警反馈；

S6,处理端会对原始码流做探测处理，如果和策略模块不匹配，推送协议到策略模块，策略修改源信息；

S7,上级notify请求到来，根据源id，查找源信息树，根据notify的目的信息，查找此请求的引用阶段，生成目的流，如果此目的流，是第一次生成，将此阶段流的参数类型组成索引，保存的源信息树中。如果根据源id没有查找到源信息树，重复第步骤S3至步骤S6；

S8,上级delete请求到来，策略模块删除此会话的引用计数，查看原始流的各个阶段流的引用计数，如果都为0，策略模块删除此流树信息结构，并下发delete请求到处理端，删除此流的所有阶段流。

一种多阶段流调度系统，包括上级、策略端以及处理端，其中策略模块运行用于查找处理端，查找处理端的处理进程，更新源资源树的信息以及生成请求发送到处理端；处理端由多台具备视频处理的服务器构成。

一种多阶段流调度装置，包括用于运行多阶段流调度方法以及多阶段流调度系统的计算机硬件设备以及网络设备。

本发明的有益效果：由于现有调度方案，是针对原始流和封装流做匹配分发，没有对解封装、解码、滤镜、编码几个阶段流进行充分利用，这是一种浪费。本调度方案充分利用各个阶段的码流，可以实现引用其他阶段流生成后续阶段需要的码流类型，或者阶段流在不同服务器间分发，然后充分利用服务器特性处理特定阶段流，譬如GPU服务器，可以特定处理解码、编码过程。这样的好处是减少某些阶段流重复生成工作，节省服务器性能，并且可以利用特定服务器处理特定阶段流，加快效率。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

图1是本发明中策略模块的流程图一。

图2是本发明中策略模块的流程图二。

图3是本发明中策略模块的流程图三。

具体实施方式

本发明实施例中，设计到的方案是接入多条地铁的音视频，按接入一条线的视频举例说明。视频源有H264、MPEG4、MPEG2三种编码格式，输出编码类型要求H264，所以需要转码。有PC端播放和网页播放两种类型，需要输出不同的封装格式。平台部署3个处理端A、B、C，其中C是GPU服务器，一个策略模块调度。

首先在配置文件中将处理端信息配置好，包括处理端IP、PORT，以及C处理端的GPU标志。

启动策略模块，策略模块读取配置文件，获取处理端A/B/C的IP、端口。连接处理端，此时用策略服务器和处理端的每个进程都建立一个连接，策略模块保存这些连接，并定时发送心跳信息，保持长连接。处理端是多进程处理，和每个进程建立一个连接，是为了均衡进程的处理能力，让进程的性能得到最大利用。

策略模块向处理端发送check协议，这是一个私有协议，目的获取处理端的cpu使用率、cpu核数、内存使用率、网卡性能、网络上行/下行的流量等全局信息，以及每个进程的cpu使用率、进程连接数等信息。策略选择性能最佳的服务器，依靠这些服务器的基本信息做判断。

策略模块有一个全局的红黑树，根据视频源的唯一id为索引，保存源的基本信息。源的基本信息中包含原始流的接入、解封装流、解码流、滤镜流、编码流、封装流对应的处理端以及对每个阶段流的引用计数，原则上保证每一种流，只生成一次，原始流、解封装、解码流只能有一种类型，滤镜、编码、封装可以有多种类型，譬如编码可能有H264、H265等，因此保存滤镜、编码、封装的阶段流时，需要生成独立的三颗红黑树，根据对应的滤镜参数、编码参数、封装参数作为索引。这是策略模块的基本数据结构。

策略模块运行主要分为四个阶段，逐次运行。第一个阶段是查找处理端，第二个阶段查找处理端的处理进程，第三个阶段更新源资源树的信息，第四个阶段生成请求发送到处理端。

第一个阶段，查找处理端。首先需要根据源唯一id，在全局红黑树上查找，然后根据notify协议的目的信息，计算出最终出流阶段，这里主要依靠notify协议目的信息，构建查找索引，从资源树中查找引用阶段，根据引用阶段信息也就取到处理该阶段流的处理端，譬如notify请求中有滤镜参数，那该请求必须要解码、滤镜、编码、封装四个流程，根据最终的封装参数索引在资源树的封装红黑中查找，如果有，查找结束，引用封装流，否则依次在编码红黑树、滤镜红黑树、解码阶段、解封装阶段、原始流查找引用阶段，所以说最小引用阶段就是原始流。然后判断该处理端的当前性能，如果性能不满足条件，将此阶段流发送到其他服务器处理，称引用到其他服务器的流为外部引用流，只有本处理端无法处理的情况下，才会出现这种情况。外部引用流还有一个应用，应对热点视频，接入只能一次，大量请求涌入，策略模块会对这路流内部分发，然后由不同的处理端，发送到不同的终端。如果分析notify目的信息中有转码处理，优先选择GPU服务器处理，会出现由A处理端接入，内部转发到C处理端(GPU)，处理到编码阶段流，再发送到A或B服务器，生成封装流，发送到终端。由A/B服务器处理输入/输出阶段，利用服务器高宽带特性，主要做分发处理，由C处理端负责转码功能，利用其GPU特性，高效转码。如果有外网请求，必须选择外网处理端处理，本项目中没有此需求。

判断服务器性能的公式：

；

P:处理器的性能指标参数

I:否决条件，0表示否决条件成立，1表示否决条件不成立，譬如外网服务器；

S(i):权重；

X(i):属性值,cpu利用率、内存使用率等；

Pre：优先权，优先时值为Base，不优先时值为0；

Base：基数，与同一个数量级，为0-1时，Base为1，为0-100时，Base为100；

第二个阶段，在第一阶段选择好一个或多个处理端基础上，为处理端选择处理进程。选择进程时，主要参考进程的cpu使用率、网络连接数比率(当前网络连接数和单个进程最大连接数相除)两部分。策略模块会为这两部分分别设置一个权重，权重的概念是表示占最终性能值得比例。譬如cpu使用率的权重是70，网络连接数比率是30，我们认为对于进程的选择，cpu占70％的比重。权重这个值不是固定的，在项目使用过程中，收集信息，然后分析出合适的权重。

第三个阶段，更新源资源树的信息。根据notify中目的信息，可以计算出该请求需要引用那个阶段的流，以及会生成哪些阶段，这些信息都需要保存。如果是一个新的源，需要创建一个源的红黑树，并做初始化，并且同时创建此源的滤镜红黑树、编码红黑树、封装红黑树，用于保存此源各个阶段的生成流的信息。更新资源树信息，一方面要将此请求中新产生的阶段流，插入到源信息树对应阶段的位置，另一个方面更新引用关系以及阶段引用的计数。本阶段要保存涉及到此源的信息，目的为了在第一阶段查找引用阶段。

第四个阶段，生成请求发送到处理端。此时，策略模块主要功能已经完毕，本阶段的任务是，为选择好的处理端进程发送协议请求，该请求内容基本和上级给策略模块发送的notify协议一致。策略模块中添加了该请求引用的阶段信息，根据该信息可以找到引用阶段流，同时告知该请求需要生成哪些阶段的流。

最后一部分就是删除，收到上级的delete命令，策略模块，根据会话的引用阶段以及输出阶段，判断会话是否删除。当输出阶段的引用计数都是0时，会话可以被删除。

以上描述，就是策略模块的具体实现流程，也就是调度方案的实现流程。

一种多阶段流调度系统，包括上级、策略端以及处理端，其中策略模块运行用于查找处理端，查找处理端的处理进程，更新源资源树的信息以及生成请求发送到处理端；处理端由多台具备视频处理的服务器构成。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。

Claims (7)

1.一种多阶段流调度方法，其特征在于，具体包括以下步骤:

S1,在配置文件中配置处理端的信息，包括处理端服务器IP，处理端监听端口，以及服务器特性；

S2,策略模块通过tcp协议主动连接处理端，发送check协议，获取处理端服务器的基本信息；

S3,上级notify请求到来，策略模块根据notify的源信息，建立树结构，保存源信息；根据目的信息，判断对源码流的处理流程，并将这些阶段流保存到源信息树上；

S4,在所有处理端中查找一个或多个性能最佳的服务器，将步骤S3的notify请求转发至该服务器，并告知需要生成哪些阶段流，并与策略模块保持完全一致；

S5,收集处理端的响应时间，作为选择处理端的一个判断条件；

S6,处理端对原始码流做探测处理，当与策略模块不匹配，推送协议到策略模块，策略修改源信息；

S7,上级notify请求到来，根据源id，查找源信息树，根据notify的目的信息，查找此请求的引用阶段，生成目的流；

S8,上级delete请求到来，策略模块删除此会话的引用计数，查看原始流的各个阶段流的引用计数，如果都为0，策略模块删除此流树信息结构，并下发delete请求到处理端，删除此流的所有阶段流。

2.根据权利要求1所述的多阶段流调度方法，其特征在于，步骤S3中源码流的处理流程包含解封装、解码、滤镜、编码、封装中的一个或多个流程。

3.根据权利要求1所述的多阶段流调度方法，其特征在于，步骤S5中当服务器超时，还包括触发报警反馈。

4.根据权利要求1所述的多阶段流调度方法，其特征在于，步骤S5中当服务器超时，做特殊记录。

5.根据权利要求1所述的多阶段流调度方法，其特征在于，步骤S7中，如果根据源id没有查找到源信息树，重复第步骤S3至步骤S6。

6.根据权利要求1所述的多阶段流调度方法，其特征在于，步骤S7中，如果此目的流，是第一次生成，将此阶段流的参数类型组成索引，保存的源信息树。

7.根据权利要求1所述的多阶段流调度方法，其特征在于，步骤S2中，处理端服务器的基本信息，包含性能参数、外网、GPU运行状态。

Images