CN114125489B - 数据流分发方法及系统 - Google Patents

Abstract

本申请公开了一种数据流分发方法，该方法包括：推流方推送数据流至第一边缘计算节点；第一边缘计算节点接收到所述数据流后，转推至所有CDN；监控系统定时采集每个边缘计算节点上的流，并将采集到的信息保存到存储结构中；拉流方向第二边缘计算节点请求获取所述数据流；第二边缘计算节点根据本地是否存有所述数据流及存储结构中的信息判断所述数据流的来源，并向拉流方返回所述数据流。本申请还公开了一种数据流分发系统、装置、计算机设备和计算机可读存储介质。由此，能够通过复用边缘计算节点和CDN的资源，并且进行改造，让上行的边缘计算节点承载下行的作用，来实现赛事直播数据流的分发，减少链路，减少服务器部署，做到足够灵活。

Description

数据流分发方法及系统

技术领域

本申请涉及直播技术领域，尤其涉及一种数据流分发方法、系统、装置、计算机设备及计算机可读存储介质。

背景技术

在现有直播体系中，常常会面临承接一些赛事服务的场景。赛事服务需要提供推流功能及给其他合作商提供拉流地址的功能。或者有时候，需要将直播房间的流，分发给其他合作商。以往一般的实现方式为：搭建固定的服务器，让赛事推流方或者房间主播推流到固定的服务器上，并提供该服务器的拉流地址，让合作商来该服务器进行拉流。

发明内容

本申请的主要目的在于提出一种数据流分发方法、系统、装置、计算机设备及计算机可读存储介质，旨在解决如何在不另外搭建固定服务器的基础上实现赛事服务的推拉流功能的问题。

为实现上述目的，本申请实施例提供了一种数据流分发方法，所述方法包括：

推流方推送数据流至第一边缘计算节点；

所述第一边缘计算节点接收到所述数据流后，转推至所连接的所有内容分发网络CDN；

监控系统定时采集每个边缘计算节点上的流，并将采集到的信息保存到存储结构中；

拉流方向第二边缘计算节点请求获取所述数据流；

所述第二边缘计算节点根据本地是否存有所述数据流及所述存储结构中的信息判断所述数据流的来源，并向所述拉流方返回所述数据流。

可选地，所述推流方推送数据流至第一边缘计算节点包括：

获取所述推流方发出的推流请求中的第一域名；

解析所述第一域名得到第一边缘计算节点的第一地址；

所述推流方根据所述第一地址推送所述数据流至所述第一边缘计算节点。

可选地，所述拉流方向第二边缘计算节点请求获取所述数据流包括：

获取所述拉流方的拉流请求中的第二域名；

解析所述第二域名得到第二边缘计算节点的第二地址；

所述拉流方根据所述第二地址向所述第二边缘计算节点请求获取所述数据流。

可选地，所述第二边缘计算节点根据本地是否存有所述数据流及所述存储结构中的信息判断所述数据流的来源，并向所述拉流方返回所述数据流包括：

当所述第二边缘计算节点与所述第一边缘计算节点相同时，所述第二边缘计算节点中存有所述数据流，直接向所述拉流方返回所请求的所述数据流。

可选地，所述第二边缘计算节点根据本地是否存有所述数据流及所述存储结构中的信息判断所述数据流的来源，并向所述拉流方返回所述数据流还包括：

当所述第二边缘计算节点不是所述第一边缘计算节点时，所述第二边缘计算节点向所述监控系统请求所述数据流对应的所述第一边缘计算节点地址并向所述第一边缘计算节点请求获取所述数据流，同时向所有所述CDN请求获取所述数据流；

所述第二边缘计算节点将上述请求中最快返回的所述数据流返回给所述拉流方。

可选地，所述监控系统采集到的信息包括流信息、边缘计算节点信息、时间戳。

可选地，所述向所述监控系统请求所述数据流对应的所述第一边缘计算节点地址并向所述第一边缘计算节点请求获取所述数据流包括：

向所述监控系统中的所述存储结构请求查询所述数据流对应的所述第一边缘计算节点地址；

当查询到的地址不为空且对应的所述时间戳与当前时间的距离小于阈值时，向所述第一边缘计算节点请求获取所述数据流。

此外，为实现上述目的，本申请实施例还提供一种数据流分发系统，所述系统包括：

推流方，用于推送数据流至第一边缘计算节点；

所述第一边缘计算节点，用于接收所述数据流并转推至所连接的所有内容分发网络CDN；

监控系统，用于定时采集每个边缘计算节点上的流，并将采集到的信息保存到存储结构中；

拉流方，用于向第二边缘计算节点请求获取所述数据流；

所述第二边缘计算节点，用于在接收到拉流请求时，根据本地是否存有所述数据流及所述存储结构中的信息判断所述数据流的来源，并向所述拉流方返回所述数据流。

为实现上述目的，本申请实施例还提供一种数据流分发方法，应用于边缘计算节点，所述方法包括：

接收推流方推送的第一数据流；

将所述第一数据流转推至所连接的所有内容分发网络CDN；

接收拉流方发出的获取第二数据流的请求；

根据所述边缘计算节点中是否存有所述第二数据流及监控系统提供的信息判断所述第二数据流的来源，并向所述拉流方返回所述第二数据流。

可选地，所述方法在所述接收推流方推送的第一数据流后还包括：

在所述监控系统采集信息时将所述边缘计算节点的信息、所述第一数据流的信息及时间戳发送至所述监控系统，以保存在所述监控系统的存储结构中。

可选地，所述根据所述边缘计算节点中是否存有所述第二数据流及监控系统提供的信息判断所述第二数据流的来源，并向所述拉流方返回所述第二数据流包括：

当所述第二数据流与所述第一数据流相同时，所述边缘计算节点中存有所述第二数据流，直接将所述第二数据流返回至所述拉流方。

可选地，所述根据所述边缘计算节点中是否存有所述第二数据流及监控系统提供的信息判断所述第二数据流的来源，并向所述拉流方返回所述第二数据流还包括：

当所述边缘计算节点中没有所述第二数据流时，向所述监控系统请求所述第二数据流对应的第三边缘计算节点地址并向所述第三边缘计算节点请求获取所述第二数据流，同时向所有所述CDN请求获取所述第二数据流；

将上述请求中最快返回的所述第二数据流返回给所述拉流方。

可选地，所述向监控系统请求所述第二数据流对应的第三边缘计算节点地址并向所述第三边缘计算节点请求获取所述第二数据流包括：

向所述监控系统中的所述存储结构请求查询所述第二数据流对应的所述第三边缘计算节点地址；

当查询到的地址不为空且对应的所述时间戳与当前时间的距离小于阈值时，向所述第三边缘计算节点请求获取所述第二数据流。

为实现上述目的，本申请实施例还提供一种数据流分发装置，应用于边缘计算节点，所述装置包括：

接收模块，用于接收推流方推送的第一数据流；

转推模块，用于将所述第一数据流转推至所连接的所有内容分发网络CDN；

所述接收模块，还用于接收拉流方发出的获取第二数据流的请求；

返回模块，用于根据所述边缘计算节点中是否存有所述第二数据流及监控系统提供的信息判断所述第二数据流的来源，并向所述拉流方返回所述第二数据流。

为实现上述目的，本申请实施例还提供一种计算机设备，所述计算机设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的数据流分发程序，所述数据流分发程序被所述处理器执行时实现如上述的数据流分发方法。

为实现上述目的，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有数据流分发程序，所述数据流分发程序被处理器执行时实现如上述的数据流分发方法。

本申请实施例提出的数据流分发方法、系统、装置、计算机设备及计算机可读存储介质，能够通过复用边缘计算节点和CDN的资源，并且改造监控体系、转推方式和拉流方式，让上行的边缘计算节点承载下行的作用，来实现赛事直播数据流的分发，减少链路，减少服务器部署，做到足够灵活。

附图说明

图1为本申请第一实施例提出的一种数据流分发系统的应用环境架构图；

图2为现有的赛事直播架构的推拉流过程示意图；

图3为现有的直播体系的推拉流过程示意图；

图4为本申请第二实施例提出的一种数据流分发方法的流程图；

图5为所述数据流分发方法的一种特定具体实施例的流程示意图；

图6为本申请第三实施例提出的一种数据流分发方法的流程图；

图7为图6中步骤S306的细化流程示意图；

图8为本申请第四实施例提出的一种计算机设备的硬件架构示意图；

图9为本申请第五实施例提出的一种数据流分发装置的模块示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

实施例一

请参阅图1，图1为本申请第一实施例提出的一种数据流分发系统的应用环境架构图。本申请可应用于包括，但不仅限于监控系统1、推流方2、边缘计算节点4、CDN(ContentDelivery Network，内容分发网络)6、拉流方8的应用环境中。

在现有的赛事直播架构(如图2所示)中，推流方(例如主播或供应商)推流至一个或几个固定的服务器，然后将所述固定服务器的地址提供给拉流方(例如合作商)。所述拉流方再从所述固定服务器中进行拉流。这种赛事直播方案方案存在以下问题：

(1)服务器搭建成本：服务器的搭建需要耗费时间，且服务器本身需要承担一定的成本，每次活动的时间都是不一样的。如果在两次赛事中有间隔时间，可以继续闲置服务器，等待下一次赛事。但是这样会造成资源浪费和成本增加。如果退订服务器，在下一次赛事前重新申请，会浪费大量人力成本，部署重复的事情。

(2)服务器进出口压力：不同的赛事服务所对接的合作商是不一样的，有时候只需要给几个合作商提供拉流地址，有时候则需要给几十个甚至上百个合作商提供拉流地址。一个服务器的出口带宽是固定的，当大量拉流的时候，会出现带宽不够，进而影响拉流的质量。当然也可以部署很多台机器，但多台服务器在合作商比较少的时候会造成资源浪费。

(3)区域固定，网络延迟大：服务器是部署在固定地方的，例如部署在上海。但是合作商的是分布在全国各地的，例如当合作商处于山西时，从地理位置上，两者相聚太远，很容易受到网络传输的影响，从而导致拉流卡顿或延迟比较高。

(4)单点抖动风险：即只有一个服务器，如果一个服务器出问题，会影响这个服务器上的所有流。如果部署多个服务器，则存在资源浪费问题。

(5)需要主播或是赛事推流方配合：如果需要将房间主播的流分发给其他运营商，则需要主播提前将流推到固定的服务器上。如果是赛事则需要推流方的配合。

(6)服务器节点IP固定：服务器的节点是提前申请好的，申请之后IP就固定了。因此当需要调整的时候，需要通知推流方和拉流方，同时变换拉流地址中的IP。

为了解决上述诸多问题，本实施例对边缘计算节点、监控体系、转推体系、拉流体系进行了一系列改造。

在现有的直播体系(如图3所示)中，边缘计算节点为上行节点(只能推流不能拉流)，部署在全国各地，接收直播平台上所有正常主播的推流。由于主播的分布是分散的，因此接收主播推流的边缘计算节点也是部署在全国各地的。每个边缘计算节点会有一个IP地址，并且会有一个域名，DNS((Domain Name System，域名系统)服务会将所述IP地址注册到DNS解析中。域名和IP的映射关系是1对N的，一个域名可以对应多个IP。主播通过域名进行推流时，根据所述域名通过DNS解析获取具体的边缘计算节点IP。推流到该边缘计算节点后，会选择一家CDN进行转推，用户则从CDN进行拉流观看。

但是，这种现有的直播体系不能直接应用于赛事数据流分发，原因如下：

(1)主播即推流方用域名进行推流，一个域名对应多个IP，不知道DNS解析后，会推流到哪个边缘计算节点上，拉流方也不知道去哪个边缘计算节点进行拉流。

(2)CDN直接面对用户，只提供给用户拉流，从CDN到边缘计算节点是单向数据传输，边缘计算节点无法从CDN进行拉流。

综合上述问题，本实施例提出了一种改进后的数据流分发系统，可以适用于赛事数据流。其中，所述推流方2使用域名并根据域名解析推流至一个边缘计算节点4。所述边缘计算节点4接收到所述推流后，转推至所有CDN 6。所述监控系统1定时采集每个边缘计算节点2上的流，并将采集到的信息(流信息、节点信息、时间戳)保存到存储结构中。拉流方8使用域名并根据域名解析向一个边缘计算节点4进行拉流。边缘计算节点4根据预设策略向所述拉流方8返回数据流。

在本实施例中，所述预设策略为：

(1)当所述边缘计算节点4中有拉流方8请求的数据流(即该数据流刚好是推流到所述边缘计算节点4)时，直接向所述拉流方8返回所请求的数据流。

(2)当所述边缘计算节点4中没有拉流方8请求的数据流(即该数据流不是推流到所述边缘计算节点4)时，所述边缘计算节点4采用以下两种方式进行拉流，并且将返回最快的数据流返回给所述拉流方8。

(a)向所述监控系统1请求所述数据流对应的边缘计算节点4的地址，并向该地址请求获取所述数据流。

(b)向所有所述CDN 6请求获取所述数据流。

本实施例对于监控体系的改造即监控系统1，解决的是不知道数据流在哪一个边缘计算节点上的问题，通过采集每个边缘计算节点4上的流相关的信息，并保存在存储结构中，可以精准定位数据流所在的机器。具体而言，所采集和存储的信息包括流信息、边缘计算节点信息和时间戳。其中，所述时间戳是指最后一次更新时间，用来反应所采集的信息是否还有效，从而保证实时性。例如，所述存储结构可以定义为包含以下三个字段：stream_name(流名)，server_ip(流所在服务器/边缘计算节点IP地址)，update_time(时间戳，即最后一次更新时间)。

监控系统1可以获取到所有的边缘计算节点4的IP，定时采集所有IP上正在推的流，并更新到存储结构中。同时监控系统1还可以提供查询接口，以供边缘计算节点4实时查询流所在的机器和最后一次更新时间。

对于转推体系的改造在于，原来推流到边缘计算节点4后，只转推一家CDN 6，而在本实施例中，针对赛事的数据流，转推所有CDN 6，这样所有CDN6中都有赛事数据流。

对于拉流体系的改造实际上是改造边缘计算节点4，使边缘计算节点4具有拉流的功能，将单向传输改为双向传输。边缘计算节点4对接CDN 6，向CDN6请求拉流(如果CDN有这条流)。边缘计算节点4接收到拉流请求后，如果本地没有该流，会向所有CDN 6发起拉流请求，如果CDN 6有该流，则会将流返回给边缘计算节点4，否则不返回数据。

通过上述改造，本实施例解决了上面的各个问题。例如：

(1)服务器搭建成本：本实施例复用边缘计算节点的机器，不存在服务器成本问题。因为无论赛事是否使用这些机器，边缘计算节点一定是需要部署给主播使用的。

(2)服务器进出口压力：无论是主播/赛事推流方，还是拉流方，都可以通过域名进行推流，而域名后面是成百的边缘计算节点，直接分担了带宽的进出口压力。

(3)区域固定，网络延迟大：边缘计算节点部署在全国各地，主播和赛事推流方都可以通过域名解析，获取离自己最近的边缘计算节点。拉流方也可以通过域名解析，访问离自己最近的边缘计算节点。而流转推给CDN后，CDN有丰富的网络链路，本身会完成流在全网的分发功能。拉流方访问CDN的时候，是通过域名解析，获取离拉流方最近的CDN节点，而CDN已经完成流的分发，所以可以缩短推流端和拉流端之间的链路，相应的延迟也会被降低。

(4)单点抖动风险：丰富的边缘计算节点可以避免单点，多个CDN也避免了单点。并且当接收到拉流请求的边缘计算节点本地没有该流时，同时回源该流对应的边缘计算节点和各家CDN，也避免了其中任何一个出现问题导致的风险。

(5)需要主播或是赛事推流方配合：无论是主播还是赛事推流方，都是通过域名进行推流，不限定IP，所以更换节点不需要通知推流方。

(6)服务器节点IP固定：通过域名进行推流和拉流，解析出的边缘计算节点IP是动态的，不存在这个问题。

实施例二

如图4所示，为本申请第二实施例提出的一种数据流分发方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以整个所述数据流分发系统作为执行主体对该方法进行说明。

该方法包括以下步骤：

S200，推流方推送数据流至第一边缘计算节点。

在本实施例中，所述数据流主要是指赛事数据流，下面以赛事数据流为例进行说明。可以理解，本实施例提供的方法也可以适用于其他类型的数据流，在此不再赘述。所述赛事数据流由推流方(例如主播或供应商)进行推流，并且需要将可以拉流的服务器地址提供给拉流方(例如合作商)。当然，本实施例采用改造后的边缘计算节点作为推流和拉流的服务器后，不需要提供固定的服务器地址给拉流方，拉流方可以从任意边缘计算节点进行拉流。另外，所述赛事数据流只在赛事活动时间需要推流和拉流，一般情况下，活动时间不固定，且两次赛事之间有间隔时间。而当赛事活动时间开始时，可能会有大量拉流，对带宽要求较高。

当所述推流方使用域名进行推流，首先获取所述推流方发出的推流请求中的域名(第一域名)。通过DNS解析所述第一域名得到一个边缘计算节点(第一边缘计算节点)的IP地址。所述推流方推送所述数据流至所述第一边缘计算节点。

S202，所述第一边缘计算节点接收到所述数据流后，转推至所连接的所有CDN。

不同于原来推流到边缘计算节点后，只转推一家CDN，在本实施例中，针对赛事的数据流，转推所述第一边缘计算节点所连接的所有CDN，这样所有CDN中都有赛事数据流。

S204，监控系统定时(例如每隔10秒)采集每个边缘计算节点上的流，并将采集到的信息保存到存储结构中。

所述监控系统采集到的信息包括流信息(例如流名)、边缘计算节点信息(例如节点IP)、时间戳。其中，所述时间戳是指最后一次更新时间，用来反应所采集的信息是否还有效，从而保证实时性。所述存储结构可以定义为包含以下三个字段：stream_name(流名)，server_ip(流所在服务器/边缘计算节点IP地址)，update_time(时间戳，即最后一次更新时间)。

S206，拉流方向第二边缘计算节点请求获取所述数据流。

拉流方使用域名(第二域名)进行拉流，首先获取所述拉流方的拉流请求中的第二域名，通过DNS解析所述第二域名得到一个边缘计算节点(称为第二边缘计算节点)的地址。所述拉流方根据该地址向所述第二边缘计算节点请求获取所述数据流。

S208，所述第二边缘计算节点根据本地是否存有所述数据流及所述存储结构中的信息判断所述数据流的来源，并向所述拉流方返回所述数据流。

具体而言：

(1)当所述第二边缘计算节点与所述第一边缘计算节点相同(刚好解析出的IP地址就是推流的IP地址，也就是说所述第二边缘计算节点本地有所述数据流)时，直接向所述拉流方返回所请求的数据流。

(2)当所述第二边缘计算节点不是所述第一边缘计算节点(所述第二边缘计算节点本地没有所述数据流)时，所述第二边缘计算节点向所述监控系统请求所述数据流对应的所述第一边缘计算节点的IP地址，并向所述第一边缘计算节点请求获取所述数据流。同时，所述第二边缘计算节点向所有所述CDN请求获取所述数据流。

所述第二边缘计算节点将上述请求中最快返回的所述数据流返回给所述拉流方。也就是说，所述第一边缘计算节点和所有所述CDN中，哪一路径最先返回数据流，就将该数据流返回给所述拉流方。

优选地，所述第二边缘计算节点向所述监控系统中的所述存储结构请求查询所述数据流对应的所述第一边缘计算节点IP地址后，当查询到的地址不为空且对应的所述时间戳与当前时间的距离小于阈值(例如10秒)时，表示所述存储结构内保存的该条信息在有效期内(即流信息和节点信息的更新是实时的)，则向该地址对应的所述第一边缘计算节点请求获取所述数据流。否则，默认无法获取所述第一边缘计算节点的IP地址，或者信息已经过期，流信息已经不可用。

本实施例提出的数据流分发方法，可以通过复用边缘计算节点和CDN的资源，并且改造监控体系、转推方式和拉流方式，让上行的边缘计算节点承载下行的作用，来实现赛事直播数据流的分发，减少链路，减少服务器部署，做到足够灵活。

为了更详尽的对该方法的上述各步骤进行解释说明，以下以特定的具体实施例为例进行说明。本领域技术人员当知，下述具体实施例的内容并不用于限制本发明的发明思想，本领域技术人员可以轻易依据下述实施例具体描述内容进行适当的内容发散和扩展。

如图5所示，为所述特定具体实施例的一种流程示意图。

(1)主播或赛事推流方直接用域名进行推流(假设推流的流名为live_123)，DNS解析后获得一个边缘计算节点IP(假设为边缘计算节点A)。

(2)边缘计算节点A接收到推流后，将流转推到所连接的所有CDN(假设CDN为3家，分别为A、B、C)。

(3)监控系统定时(假设频率为10秒)采集边缘计算节点A上的流，采集到流live_123在边缘计算节点A上，因此会将该条信息保存到存储结构中：live_123:A:时间戳(当前时间)。

(4)拉流方使用域名进行拉流。分为两种情况：

(4-1)正好拉流方通过域名解析到边缘计算节点A，则边缘计算节点A本地直接将流返回给就拉流方。

(4-2)如果没有解析到边缘计算节点A(而是解析到边缘计算节点B)，则边缘计算节点B会同时进行以下步骤：

(4-2-1)向监控系统请求流live_123的server_ip和update_time，如果server_ip不为空，且update_time与当前时间的距离小于10秒，则证明更新是实时的，所以会直接向(server_ip对应的)边缘计算节点A发起拉流请求，边缘计算节点A本地直接将流返回给边缘计算节点B。

否则，默认无法获取对应边缘计算节点的IP，或者信息已经过期，流数据已经不可用。

(4-2-2)向所有CDN发起拉流请求(哪一家CDN最先返回live_123的流)。

(4-2-1)和(4-2-2)中哪一路径最先返回数据，边缘计算节点B则将得到的该路数据流返回给拉流方。

实施例三

如图6所示，为本申请第三实施例提出的一种数据流分发方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。下面以边缘计算节点作为执行主体对该方法进行说明。

该方法包括以下步骤：

S300，接收推流方推送的第一数据流。

在本实施例中，所述数据流主要是指赛事数据流，下面以赛事数据流为例进行说明。可以理解，本实施例提供的方法也可以适用于其他类型的数据流，在此不再赘述。所述赛事数据流由推流方(例如主播或供应商)进行推流，并且需要将可以拉流的服务器地址提供给拉流方(例如合作商)。当然，本实施例采用改造后的边缘计算节点作为推流和拉流的服务器后，不需要提供固定的服务器地址给拉流方，拉流方可以从任意边缘计算节点进行拉流。另外，所述赛事数据流只在赛事活动时间需要推流和拉流，一般情况下，活动时间不固定，且两次赛事之间有间隔时间。而当赛事活动时间开始时，可能会有大量拉流，对带宽要求较高。

当所述推流方使用域名进行推流，首先获取所述推流方发出的推流请求中的域名。通过DNS解析该域名得到一个边缘计算节点的IP地址。所述推流方根据该地址推送第一数据流至所述边缘计算节点，所述边缘计算节点接收到推送的所述第一数据流。

值得注意的是，在监控系统采集信息时，所述边缘计算节点将所述边缘计算节点的信息、所述第一数据流的信息及时间戳(当前时间)发送至所述监控系统，以保存在所述监控系统的存储结构中。

S302，将所述第一数据流转推至所连接的所有CDN。

不同于原来推流到边缘计算节点后，只转推一家CDN，在本实施例中，针对赛事的第一数据流，转推所述边缘计算节点所连接的所有CDN，这样所有CDN中都有赛事数据流。

S304，接收拉流方发出的获取第二数据流的请求。

拉流方使用域名进行拉流，首先获取所述拉流方的拉流请求中的该域名，通过DNS解析该域名得到一个边缘计算节点的地址。所述拉流方根据该地址向所述边缘计算节点请求获取所述第二数据流，所述边缘计算节点接收该拉流请求。

S306，根据所述边缘计算节点中是否存有所述第二数据流及监控系统提供的信息判断所述第二数据流的来源，并向所述拉流方返回所述第二数据流。

具体而言，进一步参阅图7，为上述步骤S306的细化流程示意图。可以理解，该流程图不用于对执行步骤的顺序进行限定。根据需要，还可以对该流程图中的部分步骤进行添加或删减。在本实施例中，所述步骤S306具体包括：

S3060，判断所述第二数据流与所述第一数据流是否相同。若是，则执行步骤S3062；否则执行步骤S3064-S3066。

S3062，所述边缘计算节点直接将所述第二数据流返回至所述拉流方。

当所述第二数据流与所述第一数据流相同(也就是说所述边缘计算节点本地有所述第二数据流)时，直接向所述拉流方返回所请求的所述第二数据流。

当然，所述边缘计算节点之前可能已接收到多个不同的第一数据流，当拉流方请求获取第二数据流时，只要所述第二数据流是所述多个不同的第一数据流之一，所述边缘计算节点即可直接向所述拉流方返回所述第二数据流。

S3064，向监控系统请求所述第二数据流对应的边缘计算节点(称为第三边缘计算节点)地址并向所述第三边缘计算节点请求获取所述第二数据流，同时向所有所述CDN请求获取所述第二数据流。

优选地，在所述边缘计算节点向所述监控系统中的所述存储结构请求查询所述第二数据流对应的所述第三边缘计算节点地址后，当查询到的地址不为空且对应的所述时间戳与当前时间的距离小于阈值(例如10秒)时，向所述第三边缘计算节点请求获取所述第二数据流。

S3066，将步骤S3064中所述请求中最快返回的所述第二数据流返回给所述拉流方。

也就是说，所述第三边缘计算节点和所有所述CDN中，哪一路径最先返回所述第二数据流，就将该数据流返回给所述拉流方。

本实施例提出的数据流分发方法，可以通过复用边缘计算节点和CDN的资源，并且改造监控体系、转推方式和拉流方式，让上行的边缘计算节点承载下行的作用，来实现赛事直播数据流的分发，减少链路，减少服务器部署，做到足够灵活。

实施例四

如图8所示，为本申请第四实施例提出一种计算机设备20的硬件架构示意图。本实施例中，所述计算机设备20可包括，但不仅限于，可通过系统总线相互通信连接的存储器21、处理器22、网络接口23。需要指出的是，图8仅示出了具有组件21-23的计算机设备20，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。在本实施例中，所述计算机设备20可以是所述边缘计算节点。

所述存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，所述存储器21可以是所述计算机设备20的内部存储单元，例如该计算机设备20的硬盘或内存。在另一些实施例中，所述存储器21也可以是所述计算机设备20的外部存储设备，例如该计算机设备20上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，所述存储器21还可以既包括所述计算机设备20的内部存储单元也包括其外部存储设备。本实施例中，所述存储器21通常用于存储安装于所述计算机设备20的操作系统和各类应用软件，例如数据流分发装置60的程序代码等。此外，所述存储器21还可以用于暂时地存储已经输出或者将要输出的各类数据。

所述处理器22在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器22通常用于控制所述计算机设备20的总体操作。本实施例中，所述处理器22用于运行所述存储器21中存储的程序代码或者处理数据，例如运行所述数据流分发装置60等。

所述网络接口23可包括无线网络接口或有线网络接口，该网络接口23通常用于在所述计算机设备20与其他电子设备之间建立通信连接。

实施例五

如图9所示，为本申请第五实施例提出一种数据流分发装置60的模块示意图。所述数据流分发装置60可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。

在本实施例中，所述数据流分发装置60包括：

接收模块600，用于接收推流方推送的第一数据流。

转推模块602，用于将所述第一数据流转推至所连接的所有CDN。

所述接收模块600，还用于接收拉流方发出的获取第二数据流的请求。

返回模块604，用于根据所述边缘计算节点中是否存有所述第二数据流及监控系统提供的信息判断所述第二数据流的来源，并向所述拉流方返回所述第二数据流。

上述各个模块的具体功能参阅上述第一实施例至第四实施例的相关说明，在此不再赘述。

实施例六

本申请还提供了另一种实施方式，即提供一种计算机可读存储介质，所述计算机可读存储介质存储有数据流分发程序，所述数据流分发程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的数据流分发方法的步骤。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请实施例的优选实施例，并非因此限制本申请实施例的专利范围，凡是利用本申请实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请实施例的专利保护范围内。

Claims (16)

1.一种数据流分发方法，其特征在于，所述方法包括：

推流方推送数据流至第一边缘计算节点；

所述第一边缘计算节点接收到所述数据流后，转推至所连接的所有内容分发网络CDN；

监控系统定时采集每个边缘计算节点上的流，并将采集到的信息保存到存储结构中；

拉流方向第二边缘计算节点请求获取所述数据流；

所述第二边缘计算节点根据本地是否存有所述数据流及所述存储结构中的信息判断所述数据流的来源，并向所述拉流方返回所述数据流，其中，当所述第二边缘计算节点本地没有所述数据流时，根据所述存储结构中的信息向存有所述数据流的边缘计算节点和所有所述CDN同时请求获取所述数据流。

2.根据权利要求1所述的数据流分发方法，其特征在于，所述推流方推送数据流至第一边缘计算节点包括：

获取所述推流方发出的推流请求中的第一域名；

解析所述第一域名得到第一边缘计算节点的第一地址；

所述推流方根据所述第一地址推送所述数据流至所述第一边缘计算节点。

3.根据权利要求1或2所述的数据流分发方法，其特征在于，所述拉流方向第二边缘计算节点请求获取所述数据流包括：

获取所述拉流方的拉流请求中的第二域名；

解析所述第二域名得到第二边缘计算节点的第二地址；

所述拉流方根据所述第二地址向所述第二边缘计算节点请求获取所述数据流。

4.根据权利要求1所述的数据流分发方法，其特征在于，所述第二边缘计算节点根据本地是否存有所述数据流及所述存储结构中的信息判断所述数据流的来源，并向所述拉流方返回所述数据流包括：

当所述第二边缘计算节点与所述第一边缘计算节点相同时，所述第二边缘计算节点中存有所述数据流，直接向所述拉流方返回所请求的所述数据流。

5.根据权利要求4所述的数据流分发方法，其特征在于，所述第二边缘计算节点根据本地是否存有所述数据流及所述存储结构中的信息判断所述数据流的来源，并向所述拉流方返回所述数据流还包括：

当所述第二边缘计算节点不是所述第一边缘计算节点时，所述第二边缘计算节点向所述监控系统请求所述数据流对应的所述第一边缘计算节点地址并向所述第一边缘计算节点请求获取所述数据流，同时向所有所述CDN请求获取所述数据流；

所述第二边缘计算节点将上述请求中最快返回的所述数据流返回给所述拉流方。

6.根据权利要求5所述的数据流分发方法，其特征在于，所述监控系统采集到的信息包括流信息、边缘计算节点信息、时间戳。

7.根据权利要求6所述的数据流分发方法，其特征在于，所述向所述监控系统请求所述数据流对应的所述第一边缘计算节点地址并向所述第一边缘计算节点请求获取所述数据流包括：

向所述监控系统中的所述存储结构请求查询所述数据流对应的所述第一边缘计算节点地址；

当查询到的地址不为空且对应的所述时间戳与当前时间的距离小于阈值时，向所述第一边缘计算节点请求获取所述数据流。

8.一种数据流分发系统，其特征在于，所述系统包括：

推流方，用于推送数据流至第一边缘计算节点；

所述第一边缘计算节点，用于接收所述数据流并转推至所连接的所有内容分发网络CDN；

监控系统，用于定时采集每个边缘计算节点上的流，并将采集到的信息保存到存储结构中；

拉流方，用于向第二边缘计算节点请求获取所述数据流；

所述第二边缘计算节点，用于在接收到拉流请求时，根据本地是否存有所述数据流及所述存储结构中的信息判断所述数据流的来源，并向所述拉流方返回所述数据流，其中，当所述第二边缘计算节点本地没有所述数据流时，根据所述存储结构中的信息向存有所述数据流的边缘计算节点和所有所述CDN同时请求获取所述数据流。

9.一种数据流分发方法，应用于边缘计算节点，其特征在于，所述方法包括：

接收推流方推送的第一数据流；

将所述第一数据流转推至所连接的所有内容分发网络CDN；

接收拉流方发出的获取第二数据流的请求；

根据所述边缘计算节点中是否存有所述第二数据流及监控系统提供的信息判断所述第二数据流的来源，并向所述拉流方返回所述第二数据流，其中，当所述边缘计算节点本地没有所述第二数据流时，根据所述监控系统提供的信息向存有所述数据流的边缘计算节点和所有所述CDN同时请求获取所述第二数据流。

10.根据权利要求9所述的数据流分发方法，其特征在于，所述方法在所述接收推流方推送的第一数据流后还包括：

在所述监控系统采集信息时将所述边缘计算节点的信息、所述第一数据流的信息及时间戳发送至所述监控系统，以保存在所述监控系统的存储结构中。

11.根据权利要求9或10所述的数据流分发方法，其特征在于，所述根据所述边缘计算节点中是否存有所述第二数据流及监控系统提供的信息判断所述第二数据流的来源，并向所述拉流方返回所述第二数据流包括：

当所述第二数据流与所述第一数据流相同时，所述边缘计算节点中存有所述第二数据流，直接将所述第二数据流返回至所述拉流方。

12.根据权利要求11所述的数据流分发方法，其特征在于，所述根据所述边缘计算节点中是否存有所述第二数据流及监控系统提供的信息判断所述第二数据流的来源，并向所述拉流方返回所述第二数据流还包括：

当所述边缘计算节点中没有所述第二数据流时，向所述监控系统请求所述第二数据流对应的第三边缘计算节点地址并向所述第三边缘计算节点请求获取所述第二数据流，同时向所有所述CDN请求获取所述第二数据流；

将上述请求中最快返回的所述第二数据流返回给所述拉流方。

13.根据权利要求12所述的数据流分发方法，其特征在于，所述向监控系统请求所述第二数据流对应的第三边缘计算节点地址并向所述第三边缘计算节点请求获取所述第二数据流包括：

向所述监控系统中的所述存储结构请求查询所述第二数据流对应的所述第三边缘计算节点地址；

当查询到的地址不为空且对应的所述时间戳与当前时间的距离小于阈值时，向所述第三边缘计算节点请求获取所述第二数据流。

14.一种数据流分发装置，应用于边缘计算节点，其特征在于，所述装置包括：

接收模块，用于接收推流方推送的第一数据流；

转推模块，用于将所述第一数据流转推至所连接的所有内容分发网络CDN；

所述接收模块，还用于接收拉流方发出的获取第二数据流的请求；

返回模块，用于根据所述边缘计算节点中是否存有所述第二数据流及监控系统提供的信息判断所述第二数据流的来源，并向所述拉流方返回所述第二数据流，其中，当所述边缘计算节点本地没有所述第二数据流时，根据所述监控系统提供的信息向存有所述数据流的边缘计算节点和所有所述CDN同时请求获取所述第二数据流。

15.一种计算机设备，其特征在于，所述计算机设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的数据流分发程序，所述数据流分发程序被所述处理器执行时实现如权利要求9至13中任一项所述的数据流分发方法。

16.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有数据流分发程序，所述数据流分发程序被处理器执行时实现如权利要求1至7或9至13中任一项所述的数据流分发方法。

Images