CN109525869A - 拉流的方法、装置及直播系统 - Google Patents

Abstract

本申请公开了一种拉流的方法、装置及直播系统，应用于直播系统的拉流节点中，其中所述方法包括：生成拉流请求；从与本节点处于连接状态的拉流节点中选择至少一个拉流节点作为目标拉流节点；判断所述目标拉流节点与本节点是否存在直接或间接的订阅关系；若所述目标拉流节点与本节点不存在订阅关系，则向所述目标拉流节点发送所述拉流请求，以请求从所述目标拉流节点中获取对应的切片子流。本申请实施例可以避免本节点和目标拉流节点因互相订阅产生的订阅环的问题，提高了拉流的效率。

Description

拉流的方法、装置及直播系统

技术领域

本申请涉及直播领域，尤其涉及拉流的方法、装置及直播系统。

背景技术

随着网络技术的发展，网络直播越来越普及，各式各样的社会活动都可以借助网络直播方式进行传播。

目前，直播系统采用的直播方式如下：主播端(终端)单方面推流到直播平台，然后通过直播平台的中转系统、CDN(Content Delivery Network，内容分发)服务器的分发，最终在观众端(终端)拉流并播放流媒体内容。而通常拉流的观众端往往数量庞大，如何提高众多观众端拉流的效率，降低观众端的拉流成本成为评价直播系统的重要指标。

发明内容

有鉴于此，本申请提供拉流的方法、装置及直播系统。

根据本申请实施例的第一方面，提供了一种拉流的方法，所述方法应用于直播系统的拉流节点中，所述方法包括：

生成拉流请求；

从与本节点处于连接状态的拉流节点中选择至少一个拉流节点作为目标拉流节点；

判断所述目标拉流节点与本节点是否存在直接或间接的订阅关系；

若所述目标拉流节点与本节点不存在订阅关系，则向所述目标拉流节点发送所述拉流请求，以请求从所述目标拉流节点中获取对应的切片子流。

根据本申请实施例的第二方面，提供了一种拉流的装置，所述装置应用于直播系统的拉流节点中，所述装置包括：

拉流请求生成模块，用于生成拉流请求；

目标拉流节点确定模块，用于从与本节点处于连接状态的拉流节点中选择至少一个拉流节点作为目标拉流节点；

订阅关系判断模块，用于判断所述目标拉流节点与本节点是否存在直接或间接的订阅关系；

拉流请求发送模块，用于若所述目标拉流节点与本节点不存在订阅关系，则向所述目标拉流节点发送所述拉流请求，以请求从所述目标拉流节点中获取对应的切片子流。

根据本申请实施例的第三方面，提供了一种直播系统，所述直播系统包括主播端、主播侧CDN服务器、主播侧网络服务器、切片服务器、观众侧CDN服务器以及观众侧对等网络，其中，所述观众侧对等网络中包括对等网络服务器以及多个拉流节点；

所述主播端用于采集音视频流并向所述主播侧CDN服务器推流；

所述主播侧CDN服务器用于将接收到的主播端发送的音视频流发送至所述主播侧网络服务器中；

所述主播侧网络服务器用于对接收到的音视频流进行处理，并将处理后的音视频流发送至切片服务器中；

所述切片服务器用于对接收到的主播侧网络服务器发送的音视频流进行切片处理，生成多个切片子流，并将所述切片子流发送至观众侧CDN服务器中；

所述观众侧CDN服务器用于将接收到的切片子流分发至接入的拉流节点中；

所述对等网络服务器用于接收拉流节点的注册，以及对所述观众侧的CDN服务器的切片子流分发情况进行管理；

所述拉流节点用于向所述观众侧CDN服务器请求切片子流；

其中，所述拉流节点还用于执行上述的拉流的方法的步骤。

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述的拉流的方法的步骤。

根据本申请实施例的第五方面，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述的拉流的方法的步骤。

本申请实施例提供的技术方案可以包括以下有益效果：

在本申请实施例中，拉流节点选定目标拉流节点以后，在向目标拉流节点发送拉流请求之前，可以首先判断目标拉流节点与本节点是否存在直接或间接的订阅关系，当两者不存在订阅关系时，才向目标拉流节点发送拉流请求，以请求从目标拉流节点中获取对应的切片子流，这样可以避免本节点和目标拉流节点因互相订阅产生的订阅环的问题，从而避免了拉流的数据因订阅环出现的数据出现死等的情况，提高了拉流的效率。

附图说明

图1是本申请一示例性实施例示出的一种拉流的方法实施例的步骤流程图；

图2是本申请一示例性实施例示出的直播系统的架构示意图；

图3是本申请一示例性实施例示出的环订阅示意图；

图4是本申请另一示例性实施例示出的一种拉流的方法实施例的步骤流程图；

图5是本申请的装置所在拉流节点的一种硬件结构图；

图6是本申请一示例性实施例示出的一种拉流装置实施例的结构框图；

图7是本申请一示例性实施例示出的一种直播系统实施例的结构框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

参考图1，示出了本申请一示例性实施例示出的一种拉流的方法实施例的步骤流程图，本申请实施例可以应用于直播系统的拉流节点中。

以下首先对直播系统的架构进行说明：

参考图2一示例性实施例示出的直播系统的架构示意图，直播系统中可以包括主播端、主播侧CDN网络(包括分布在各地的多个CDN服务器)、主播网络、P2P(Peer-to-Peer，对等网络)源站(切片服务器)、观众侧CDN网络(包括分布在各地的多个CDN服务器)、观众侧P2P服务器(又称对等网络服务器)以及观众端。需要说明的是，由于本申请实施例着重于观众侧的描述，图2中把主播侧的CDN网络和主播网络画在一起，但实际上两者是分开的。

基于图2的直播系统的架构图，直播系统大致的工作流程如下：主播端可以通过RTMP(Real Time Messaging Protocol，实时消息传输协议)或者UDP(User DatagramProtocol，用户数据包协议)向主播侧CDN服务器推流，各地的CDN服务器将收到的音视频流都发到同一个主播网络服务器中，主播网络服务器会对接收到的音视频流进行处理，然后将处理后的音视频流转发至P2P源站进行切片，切片的大概过程是由P2P源站将接收的音视频流切割成1KB大小的数据包，并将每个数据包编号后按照自定义的格式封装成切片子流，P2P源站完成切片后将切片子流交由观众测的CND网络进行分发。观众端加入直播间后，会连接到CDN服务器，从CDN服务器中拉流。同时向P2P接入服务器上报接入消息，以与其他观众端进行P2P连接，最终组成P2P网络(即对等网络)。

在上述直播系统中，本申请实施例着重于观众侧的描述，在本申请实施例中，将P2P网络中的各个观众端称为拉流节点(简称节点)。

在一种实施方式中，组成P2P网络的过程可以包括如下过程：节点发现的过程以及节点之间建立连接的过程。

节点发现的过程：

当新节点接入CDN服务器(下文如无特别说明，该CDN服务器均指观众侧的CDN服务器)后，会主动向P2P服务器进行注册，完成注册以后，新节点可以向P2P服务器发送查询节点的请求，以请求从P2P服务器中获取已注册的节点组成的节点列表。随后，新节点根据自身的出度(本节点主动连接别的节点称为出度，别的节点主动连接本节点(即本节点被动连接)称为入度)能力、节点列表中各个待连接节点的上行质量等从返回的节点列表选择至少一个目标节点主动进行P2P连接。

节点之间建立连接的过程：

当新节点从P2P服务器获得的节点列表中选择至少一个目标节点以后，新节点会向至少一个目标节点发送P2P连接请求，目标节点收到P2P连接请求后，可以根据自身的入度和出度情况，决定是否回应。如果回应了，即代表可以与新节点进行P2P连接。如果新节点没有收到目标节点的回应，则说明打洞不成功，此时新节点会告诉P2P服务器需要向目标节点打洞，由P2P服务器告诉目标节点，此时目标节点就知道有新节点请求打洞，在符合接入条件情况下，目标节点就会主动和该新节点打洞，或者P2P服务器会重新发一份新的节点列表给新节点，新节点从该新的节点列表中重新选择目标节点进行主动连接。

在实际中，当节点间建立连接或者节点以后，可以按照一定时间间隔发送心跳包来维护该连接，其中，该心跳包可以包含节点的带宽上行能力(如带宽上行速率)。

此外，可以根据通信的两节点在预设时间段内发出的字节数量和接收的字节数量的比例来计算节点在该时间段内的丢包率。在具体实现中，针对发出数据的发出节点，其会统计两次心跳包间隔内发出的字节数量，并将该字节数量附加在下一次心跳包中传输至接收节点，则对于接收节点而言，其也会统计收到的两次心跳包间隔内接收到的字节数量，然后计算接收到的字节数量以及从心跳包中读取的该心跳间隔中发送节点发出的字节数量的比值作为发出节点的丢包率。同理，接收节点也会将心跳间隔内发送至发送节点的字节数量附加到下一次的心跳包中传输给发送节点，发送节点根据自身在该心跳间隔内接收的字节数量与接收节点传输的字节数量计算接收节点的丢包率。例如，两次心跳包(例如第一个心跳包与第二个心跳包)间隔内，A向B发送了10K字节。A在第二个心跳包告诉B自己发送了10K字节。B会计算两次心跳包间隔内自己收到的数据包个数，比如是9K字节。那么这次心跳间隔期间，A到B的丢包率就是(10K-9K)/10K＝10％。

基于上述的直播系统和P2P组网的描述，本申请实施例提出的一种拉流的方法实施例，着重于基于P2P网络，节点进行拉流的场景，如图1所示，本申请实施例可以包括如下步骤：

步骤101，生成拉流请求；

当本节点需要从其他节点或者CDN服务器中拉流时，可以通过拉流请求来拉流。

其中，拉流请求中可用包括本节点的上行能力。作为一种示例，本节点的上行能力可以为本节点的带宽上行能力，如带宽上行速率(即每秒输出的字节数)。

本实施例在拉流请求中携带本节点的上行能力，可以使得目标拉流节点获得的上行能力为本节点最新的上行能力。

在实际中，本节点可以为新加入的节点，或者为被P2P服务器拒绝从观众侧的CDN服务器中拉流的节点，本申请实施例对此不作限定。

其中，一种节点被P2P服务器拒绝从观众侧的CDN服务器中拉流的场景可以如下：

当本节点想要拉流时，首先将拉流请求发送P2P服务器。而P2P服务器中可以维护各个CDN服务器的订阅资格要求以及子流配额。若P2P服务器判断请求的节点需要拉流的CDN服务器的子流配额已满(即从CDN服务器中拉流的拉流节点的数量达到对应的子流配额)，则P2P服务器可以向当前节点发送拒绝响应，以拒绝当前节点从CDN服务器中拉流。或者，P2P服务器判定CDN服务器的子流配额没满，但本节点的上行能力不满足该CDN服务器的订阅资格要求，则P2P服务器也可以向当前节点发送拒绝响应。当本节点想要从CDN拉流的拉流请求被P2P服务器拒绝时，其可以从与本节点处于连接状态的拉流节点(即可用节点)中选择至少一个拉流节点作为目标拉流节点进行拉流。

例如，为CDN服务器配置的子流配额为3。基于先到先得的原则，节点1、2、3都可以直接从CDN服务器中拉流，当节点4加入时，它先询问P2P服务器拉流，P2P服务器因CDN服务器的子流配额饱和把节点4拒绝。

另一种节点被P2P服务器拒绝从观众侧的CDN服务器中拉流的场景可以如下：

P2P服务器可以按照预设的更新频率周期性地对CDN服务器的订阅资格要求更新，从而获得该CDN服务器的最新订阅资格要求。例如，P2P服务器通过与其连接的多个拉流节点按照预设时间间隔发送的心跳包获取该拉流节点的上行能力，然后基于所有拉流节点的上行能力，对拉流节点进行降序排序，并从排序后得到的拉流节点列表中获取排序在前的与预设的子流配额对应数量的拉流节点，作为计算节点。将计算节点中最小的上行能力作为该CDN服务器的最新订阅资格要求，或者将计算节点的上行能力的均值作为该CDN服务器的最新订阅资格要求。

其中，上述预设的子流配额对应数量可以根据预设子流配额(即一条流可以分成多少条子流)、与P2P服务器连接的拉流节点的数量以及预设子流百分比计算获得。在实现中，可以首先根据预设子流配额以及与P2P服务器连接的拉流节点的数量，计算需要拉流的子流总数量，然后计算预设子流百分比与所述需要拉流的子流总数量的乘积，从而得到需要从CDN服务器中拉流的数量；根据上述需要从CDN服务器中拉流的数量以及每个节点可以拉流的数量(即子流配额)，可以得到允许从CDN服务器中拉流的根节点数量，即子流配额对应的数量。例如，假设共有100个节点与P2P服务器连接，预设子流配额为10。那么，100个节点共计需要拉1000条子流。假如可以直接从CDN拉的子流百分比是10％，那么CDN的子流配额是1000*10％＝100。P2P服务器获知所有节点的上行能力之后，对上行能力从高到低排序，挑选(100(直接从服务器拉流的配额)/10(每个节点可以拉的子流数))＝10个拉流节点作为计算节点。

而CDN服务器的初始根拉流节点根据子流配额采取先到先得的原则确定，但随着各个拉流节点的上行能力的变化，初始根拉流节点中可能会存在上行能力较差的节点，针对这些上行能力较差的根拉流节点，P2P服务器可以通过拒绝其向CDN服务器发送的订阅请求来将其释放掉，从而让其他上行能力强的节点能够接入进来。本实施例将上行能力不符合最新订阅资格要求的根拉流节点作为上行能力较差的根拉流节点。

其中，预设的子流配额可以根据与P2P服务器连接的拉流节点的数量以及预设的配额比例确定。例如，预设的配额比例为与P2P服务器连接的拉流节点的数量的10％，当与P2P服务器连接的拉流节点的数量为1000个时，则可以确定子流配额为1000*10％＝100个。

另外，本节点还可以通过如下方式确定拉流需求：

本节点根据各子流的下载源的延时信息和丢包率，定期检查各子流的下载质量，然后评估各个子流在所有节点中的质量，如果有质量比当前下载源更好的节点，则本节点会向该更好的节点发出拉流请求。

步骤102，从与本节点处于连接状态的拉流节点中选择至少一个拉流节点作为目标拉流节点；

在本申请实施例的一种优选实施例中，步骤102进一步可以包括如下子步骤：

获取与本节点处于连接状态的拉流节点的丢包率以及子流时延，并根据所述丢包率以及子流时延确定所述拉流节点的评分；选取评分最高的N个拉流节点作为目标拉流节点，其中，N大于或等于1。

在具体实现中，本节点可以选择上行能力较强的至少一个可用节点作为目标拉流节点。其中，可用节点的上行能力通过该可用节点的丢包率以及子流时延确定。

其中，各可用节点的丢包率可以参照上述的丢包率计算方式，此处不再赘述。

可用节点的子流时延可用根据该可用节点到CDN服务器的路径长度来确定，路径长度越长子流时延越大。例如，如图3所示，节点1从CDN服务器中拉流，则CDN服务器的切片子流到达节点4需要经过3跳，对应的路径长度为3；而CDN服务器的切片子流到达节点3需要经过2跳，对应的路径长度为2，则节点4的路径长度大于节点3的路径长度。可以按照预先设定的每一跳所需的时长，计算该路径长度对应的子流时延。

当本节点获得各个可用节点的丢包率以及子流时延以后，可以根据预设的评分算法，将每个可用节点的丢包率和子流时延进行融合得到该可用节点的评分。最终本节点选取评分排序在前的N个可用节点作为目标拉流节点。

步骤103，判断所述目标拉流节点与本节点是否存在直接或间接的订阅关系；

在实际中，本节点在向目标拉流节点发出拉流请求之前，还会先检查其与目标拉流节点间是否存在直接或间接的订阅关系，只有在不存在直接或间接订阅关系时才向目标拉流节点发出拉流请求，以避免出现订阅环的问题(订阅环会导致数据出现死等状态)。例如，如图3的环订阅示意图所示，假设本节点为节点1，节点1因上行能力不足被CDN服务器放弃了，那节点1就找可以连接的节点，假设目标拉流节点为节点7，当节点1订阅了节点7时，由于节点7与节点1存在间接的订阅关系(节点2和节点3与节点1存在直接的订阅关系)，那么就形成了一个订阅环，这个订阅环是一个孤立的P2P订阅系统。同理，当节点1订阅节点2-6任何一个时都会形成订阅环。

在本申请实施例的一种优选实施例中，步骤103可以包括如下子步骤：

获取本节点的订阅关系列表，其中，所述订阅关系列表中包括所有订阅本节点的已订阅节点的标识，以及，所有订阅所述已订阅节点的节点的标识；在所述订阅关系列表中查找所述目标拉流节点的标识；若查找成功，则判定所述目标拉流节点与本节点存在订阅关系；若查找不成功，则判定所述目标拉流节点与本节点不存在订阅关系。

具体的，该订阅关系列表中包括所有订阅本节点的已订阅节点的标识(即直接订阅本节点的节点)，以及，所有订阅所述已订阅节点的节点的标识(即间接订阅本节点的节点)；若在该订阅关系列表中找到目标拉流节点的标识，则表示两者存在订阅关系，否则，如果没有找到目标拉流节点的标识，则表示两者不存在订阅关系。

在一种实施方式中，所述获取本节点的订阅关系列表，包括：

接收已订阅本节点的已订阅节点上报的订阅关系，汇总本节点与所述已订阅节点的订阅关系以及所述已订阅节点上报的订阅关系，得到所述订阅关系列表，其中，所述已订阅节点上报的订阅关系为所述已订阅节点被其他节点订阅的订阅关系；

在具体实现中，在每个节点中都会维护一份其他节点从本节点中订阅切片子流的订阅关系列表。在该订阅关系数据表中，记录了直接或间接订阅本节点的拉流节点的标识。

例如，针对图3的订阅关系，节点4会把节点4被节点6和节点7订阅了的消息告诉节点2，节点2维护了相关的订阅关系列表，同时会告诉节点1，自己被节点4订阅，订阅节点4的有节点6和节点7，节点1也会维护一个订阅关系列表，节点1中维护的订阅关系列表如下表1所示。

表1

在另一种实施方式中，所述获取本节点的订阅关系列表，包括：

从对等网络服务器中请求所述订阅关系列表，其中，所述订阅关系列表为所述对等网络服务器接收到各个拉流节点上报的订阅关系后汇总得到的列表。

具体的，所有的节点都可向P2P服务器上报自己的订阅关系，由P2P服务器维护每个节点的订阅关系列表，则当本节点需要该订阅关系列表时，可以从P2P服务器中请求该订阅关系列表。

在本申请实施例的另一种优选实施例中，步骤103可以包括如下子步骤：

根据所述目标拉流节点的标识生成查询请求，并将所述查询请求发送至对等网络服务器中；当接收到所述对等网络服务器发送的允许订阅响应时，判定所述目标拉流节点与本节点不存在订阅关系，其中，所述允许订阅响应为所述对等网络服务器从服务器本地维护的本节点的订阅关系列表中查找不到所述目标拉流节点的标识时返回的响应信息。

具体而言，当本节点需要向目标拉流节点拉流时，可以先将目标拉流节点的标识发送至P2P服务器，以请求P2P服务器从本地维护的订阅关系列表中查找该目标拉流节点的标识。如果查找成功，表示两者存在订阅关系，则P2P服务器向本节点返回拒绝订阅响应；否则，如果查找失败，表示两者不存在订阅关系，则P2P服务器向本节点返回允许订阅响应。

例如，在表1中，假设本节点为节点1，目标拉流节点为节点7，在节点1向节点7发送拉流请求之前，问下P2P服务器，能不能订阅7，P2P服务器查询后发现节点7间接订阅了节点1，即节点7和节点1存在订阅关系，此时P2P服务器就会告诉节点1不能订阅节点7，这样就避免了订阅环的出现。

需要说明的是，本申请实施例并不限于上述判断本节点是否与目标拉流节点存在订阅关系的方式，本领域技术人员采用其他方式判断节点间的订阅关系均是可以的。

步骤104，若所述目标拉流节点与本节点不存在订阅关系，则向所述目标拉流节点发送所述拉流请求，以请求从所述目标拉流节点中获取对应的切片子流。

当本节点确定与目标拉流节点不存在订阅关系以后，可以向目标拉流节点发送拉流请求。针对目标拉流节点而言，当接收到拉流请求以后，也会判断自身的上行能力够不够空闲带宽来接受该拉流请求。

在一种实施方式中，目标拉流节点可以采用如下方式判断自身是否存在空闲带宽：

获取目标拉流节点一定时间段的丢包率；根据所述丢包率，确定目标拉流节点能传输的最大子流数；确定目标拉流节点的已被订阅子流数；若所述已被订阅子流数小于所述最大子流数，则判定目标拉流节点有空闲带宽；若所述已被订阅子流数大于或等于所述最大子流数，则判定目标拉流节点没有空闲带宽。

具体的，目标拉流节点可以周期性计算自身的丢包率，具体计算方式为计算两次心跳包发送间隔向目标拉流节点的各个可用节点发出的字节数量与收到的字节数量的比值。例如，节点1统计两次心跳包发送间隔内分别向与本节点连接的可用节点2、3、4发送10K字节，则节点1在该时间段内发出的字节数量为30K。对应的接收到节点2返回的字节数量为8K，接收到节点3返回的字节数量为6K，接收到节点4返回的字节数量为6K，则节点1在该时间段内收到的字节数量为30K，则节点1的丢包率为(30-20)/30＝33％。

获得丢包率以后，可以进一步根据该丢包率动态调整目标拉流节点能传输的最大子流数。一种实施方式可以为：若所述丢包率低于第一预设丢包率阈值，则按照预设增量增加子流，得到最大子流数；若所述丢包率高于第二预设丢包率阈值，则按照预设增量减少子流，得到最大子流数，其中，所述第二预设丢包率阈值大于或等于所述第一预设丢包率阈值。

例如，若当前被订阅的子流有3个，对应的丢包率比较低(低于第一预设丢包率阈值)，则可以按照预设增量增加子流，例如，增量为1，增加1个子流，使得最大子流数为4。或者，当对应的丢包率比较高(高于第二预设丢包率阈值)，则可以按照预设增量减少子流，例如，减少1个子流，使得最大子流数为2。

同时，目标拉流节点还可以根据已订阅节点的数量，确定已被订阅子流数量。如果已被订阅子流数小于最大子流数，则表示目标拉流节点有空闲带宽，例如，根据上例，最大子流数为4，已被订阅子流数为3，则目标拉流节点还有一个子流空闲可以被订阅。如果已被订阅子流数大于或等于最大子流数，则表示目标拉流节点没有空闲带宽，例如，若最大子流数为3，已被订阅子流数为3，则目标拉流节点没有空闲的子流可以被订阅。

如果目标拉流节点有空闲带宽，则可以接受该拉流请求，并向请求节点发送与拉流请求对应的切片子流。

如果没有空闲带宽，此时目标拉流节点可以进一步查询订阅自己的所有节点(即已订阅节点)的上行能力。例如，2号节点从1号节点中订阅获得1号切片子流，那么1号节点就是订阅节点，2号节点就是1号节点的已订阅节点。

其中，已订阅节点的上行能力可以为该已订阅节点的带宽上行速率。可以从节点间维护连接的心跳包中获得各个已订阅节点的带宽上行速率。

随后，可以将所有已订阅节点中最小的上行能力与发送拉流请求的节点(即请求节点)的上行能力比较，即比较已订阅节点中最小的带宽上行速率与请求节点的带宽上行速率。

如果该最小的上行能力小于请求节点的上行能力，则表示请求节点的上行能力比该最小的上行能力对应的已订阅节点的上行能力强，此时目标拉流节点可以释放该最小的上行能力对应的已订阅节点的订阅，并接受请求节点的订阅。

其中，释放该最小的上行能力对应的已订阅节点的订阅可以实现为，向该最小的上行能力对应的已订阅节点发送取消订阅消息，以通知该已订阅节点无需从本节点拉流。

当目标拉流节点接受本请求节点的订阅时，可以向本请求节点发送同意消息，同时可以直接向请求节点下发与拉流请求对应的切片子流。

在实际中，目标拉流节点在接受请求节点的订阅之前，还可以先判断本节点与请求节点之间是否存在订阅关系，如果在两者之间不存在订阅关系时才向请求节点发送同意消息，否则，则拒绝请求节点的订阅。关于目标拉流节点判断本节点与请求节点之间是否存在订阅关系的方式可以参照上述请求节点侧的订阅关系的判断。

需要说明的是，本申请实施例可以在接收订阅请求的目标拉流节点侧进行订阅关系的判断，也可以在请求节点侧进行订阅关系的判断，或者同时在两侧进行订阅关系的判断，本申请实施例对此不作限制。

在本申请实施例的一种优选实施例中，当本节点接收到目标拉流节点发送的同意订阅消息时或者接收到目标拉流节点发送的切片子流时，本节点可以将本节点与目标拉流节点的订阅关系上报至P2P服务器中，以便于P2P服务器维护订阅关系列表。

另外，对于目标拉流节点而言，如果其丢包率比较高，则表示该节点的能力下降，此时可以减少最大子流数，如将最大子流数减少为2个，而已订阅子流数有3个，则可以剔除最差的子流。具体可以为将已订阅节点的上行能力最差的已订阅节点释放，以此提高目标拉流节点上行能力。

另一方面，如果已订阅节点中最小的带宽上行速率大于本请求节点的带宽上行速率，则表示本请求节点的上行能力比该最小的带宽上行速率对应的已订阅节点的上行能力弱，此时目标拉流节点可以向本请求节点发送订阅失败响应，以拒绝请求节点的订阅。则针对本请求节点而言，需要从与其连接的节点中选取其他节点发送拉流请求。

参考图4，示出了本申请另一示例性实施例示出的一种拉流的方法实施例的步骤流程图，在图1的基础上，在步骤104之后，本申请实施例还可以包括如下步骤：

步骤105，将接收到的切片子流发送至订阅本节点的拉流节点中。

具体的，当本节点获得切片子流以后，还可以主动向订阅该本节点的拉流节点发送该切片子流。例如，如图3的所示，若本节点为节点1，当其从目标拉流节点中获得切片子流以后，可以主动向订阅其的节点2和节点3发送切片子流。节点2接收到切片子流后，可以主动将切片子流发送至订阅其的节点4，节点4接收到切片子流后，可以主动将切片子流发送至订阅其的节点6和节点7。同理，节点3接收到切片子流后，可以主动将切片子流发送至订阅其的节点5。

本实施例采用主动向订阅的节点推流的方式，好处是时延较低，适于低延时场景，比如直播场景。

与前述方法的实施例相对应，本申请还提供了拉流装置实施例。

本申请的装置实施例可以应用在拉流节点上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在节点的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本申请的装置所在设备的一种硬件结构图，除了图5所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的设备通常根据该装置的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图6，示出了本申请一示例性实施例示出的一种拉流装置实施例的结构框图，所述装置应用于直播系统的拉流节点中，所述装置包括如下模块：

拉流请求生成模块601，用于生成拉流请求；

目标拉流节点确定模块602，用于从与本节点处于连接状态的拉流节点中选择至少一个拉流节点作为目标拉流节点；

订阅关系判断模块603，用于判断所述目标拉流节点与本节点是否存在直接或间接的订阅关系；

拉流请求发送模块604，用于若所述目标拉流节点与本节点不存在订阅关系，则向所述目标拉流节点发送所述拉流请求，以请求从所述目标拉流节点中获取对应的切片子流。

在本申请实施例的一种优选实施例中，所述目标拉流节点确定模块602具体用于：

获取与本节点处于连接状态的拉流节点的丢包率以及子流时延，并根据所述丢包率以及子流时延确定所述拉流节点的评分；

选取评分最高的N个拉流节点作为目标拉流节点，其中，N大于或等于1。

在本申请实施例的一种优选实施例中，所述订阅关系判断模块703包括：

订阅关系表获取子模块，用于获取本节点的订阅关系列表，其中，所述订阅关系列表中包括所有订阅本节点的已订阅节点的标识，以及，所有订阅所述已订阅节点的节点的标识；

订阅关系查找子模块，用于在所述订阅关系列表中查找所述目标拉流节点的标识；若查找成功，则判定所述目标拉流节点与本节点存在订阅关系；若查找不成功，则判定所述目标拉流节点与本节点不存在订阅关系。

在本申请实施例的一种优选实施例中，所述订阅关系表获取子模块具体用于：

接收本节点的已订阅节点上报的订阅关系，汇总本节点与所述已订阅节点的订阅关系以及所述已订阅节点上报的订阅关系，得到所述订阅关系列表，其中，所述已订阅节点上报的订阅关系为所述已订阅节点被其他节点订阅的订阅关系；

或者，

从对等网络服务器中请求所述订阅关系列表，其中，所述订阅关系列表为所述对等网络服务器接收到各个拉流节点上报的订阅关系后汇总得到的列表。

在本申请实施例的一种优选实施例中，所述订阅关系判断模块603包括：

查询请求发送子模块，用于根据所述目标拉流节点的标识生成查询请求，并将所述查询请求发送至对等网络服务器中；

响应接收子模块，用于当接收到所述对等网络服务器发送的允许订阅响应时，判定所述目标拉流节点与本节点不存在订阅关系，其中，所述允许订阅响应为所述对等网络服务器从服务器本地维护的本节点的订阅关系列表中查找不到所述目标拉流节点的标识时返回的响应信息。

在本申请实施例的一种优选实施例中，所述装置还包括：

订阅关系上报模块，用于当接收到所述目标拉流节点返回的同意订阅消息时或者接收到所述目标拉流节点发送的切片子流时，将本节点与所述目标拉流节点的订阅关系上报至对等网络服务器中。

在本申请实施例的一种优选实施例中，所述装置还包括：

切片子流发送模块，用于将接收到的切片子流发送至订阅本节点的拉流节点中。

与前述方法的实施例相对应，本申请还提供了直播系统的实施例。

请参考图7，示出了本申请一示例性实施例示出的一种直播系统实施例的结构框图，所述直播系统包括主播端701、主播侧CDN服务器702、主播侧网络服务器703、切片服务器704、观众侧CDN服务器705以及观众侧对等网络，其中，所述观众侧对等网络中包括对等网络服务器706以及多个拉流节点707；

所述主播端701用于采集音视频流并向所述主播侧CDN服务器推流；

所述主播侧CDN服务器702用于将接收到的主播端发送的音视频流发送至所述主播侧网络服务器中；

所述主播侧网络服务器703用于对接收到的音视频流进行处理，并将处理后的音视频流发送至切片服务器中；

所述切片服务器704用于对接收到的主播侧网络服务器发送的音视频流进行切片处理，生成多个切片子流，并将所述切片子流发送至观众侧CDN服务器中；

所述观众侧CDN服务器705用于将接收到的切片子流分发至接入的拉流节点中；

所述对等网络服务器706用于接收拉流节点的注册，以及对所述观众侧的CDN服务器的切片子流分发情况进行管理；

所述拉流节点707用于向所述观众侧CDN服务器请求切片子流；

其中，所述拉流节点707还用于执行上述拉流的方法实施例中的步骤。

对于装置及直播系统实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。

以上所描述的装置实施例以及直播系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现上述方法实施例的步骤。

本申请还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法实施例的步骤。

本说明书中描述的主题及功能操作的实施例可以在以下中实现：数字电子电路、有形体现的计算机软件或固件、包括本说明书中公开的结构及其结构性等同物的计算机硬件、或者它们中的一个或多个的组合。本说明书中描述的主题的实施例可以实现为一个或多个计算机程序，即编码在有形非暂时性程序载体上以被数据处理装置执行或控制数据处理装置的操作的计算机程序指令中的一个或多个模块。可替代地或附加地，程序指令可以被编码在人工生成的传播信号上，例如机器生成的电、光或电磁信号，该信号被生成以将信息编码并传输到合适的接收机装置以由数据处理装置执行。计算机存储介质可以是机器可读存储设备、机器可读存储基板、随机或串行存取存储器设备、或它们中的一个或多个的组合。

本说明书中描述的处理及逻辑流程可以由执行一个或多个计算机程序的一个或多个可编程计算机执行，以通过根据输入数据进行操作并生成输出来执行相应的功能。所述处理及逻辑流程还可以由专用逻辑电路—例如FPGA(现场可编程门阵列)或ASIC(专用集成电路)来执行，并且装置也可以实现为专用逻辑电路。

适合用于执行计算机程序的计算机包括，例如通用和/或专用微处理器，或任何其他类型的中央处理单元。通常，中央处理单元将从只读存储器和/或随机存取存储器接收指令和数据。计算机的基本组件包括用于实施或执行指令的中央处理单元以及用于存储指令和数据的一个或多个存储器设备。通常，计算机还将包括用于存储数据的一个或多个大容量存储设备，例如磁盘、磁光盘或光盘等，或者计算机将可操作地与此大容量存储设备耦接以从其接收数据或向其传送数据，抑或两种情况兼而有之。然而，计算机不是必须具有这样的设备。此外，计算机可以嵌入在另一设备中，例如车载终端、移动电话、个人数字助理(PDA)、移动音频或视频播放器、游戏操纵台、全球定位系统(GPS)接收机、或例如通用串行总线(USB)闪存驱动器的便携式存储设备，仅举几例。

适合于存储计算机程序指令和数据的计算机可读介质包括所有形式的非易失性存储器、媒介和存储器设备，例如包括半导体存储器设备(例如EPROM、EEPROM和闪存设备)、磁盘(例如内部硬盘或可移动盘)、磁光盘以及CD ROM和DVD-ROM盘。处理器和存储器可由专用逻辑电路补充或并入专用逻辑电路中。

虽然本说明书包含许多具体实施细节，但是这些不应被解释为限制任何发明的范围或所要求保护的范围，而是主要用于描述特定发明的具体实施例的特征。本说明书内在多个实施例中描述的某些特征也可以在单个实施例中被组合实施。另一方面，在单个实施例中描述的各种特征也可以在多个实施例中分开实施或以任何合适的子组合来实施。此外，虽然特征可以如上所述在某些组合中起作用并且甚至最初如此要求保护，但是来自所要求保护的组合中的一个或多个特征在一些情况下可以从该组合中去除，并且所要求保护的组合可以指向子组合或子组合的变型。

类似地，虽然在附图中以特定顺序描绘了操作，但是这不应被理解为要求这些操作以所示的特定顺序执行或顺次执行、或者要求所有例示的操作被执行，以实现期望的结果。在某些情况下，多任务和并行处理可能是有利的。此外，上述实施例中的各种系统模块和组件的分离不应被理解为在所有实施例中均需要这样的分离，并且应当理解，所描述的程序组件和系统通常可以一起集成在单个软件产品中，或者封装成多个软件产品。

由此，主题的特定实施例已被描述。其他实施例在所附权利要求书的范围以内。在某些情况下，权利要求书中记载的动作可以以不同的顺序执行并且仍实现期望的结果。此外，附图中描绘的处理并非必需所示的特定顺序或顺次顺序，以实现期望的结果。在某些实现中，多任务和并行处理可能是有利的。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (11)

1.一种拉流的方法，其特征在于，所述方法应用于直播系统的拉流节点中，所述方法包括：

生成拉流请求；

从与本节点处于连接状态的拉流节点中选择至少一个拉流节点作为目标拉流节点；

判断所述目标拉流节点与本节点是否存在直接或间接的订阅关系；

若所述目标拉流节点与本节点不存在订阅关系，则向所述目标拉流节点发送所述拉流请求，以请求从所述目标拉流节点中获取对应的切片子流。

2.根据权利要求1所述的方法，其特征在于，所述从与本节点处于连接状态的拉流节点中选择至少一个拉流节点作为目标拉流节点，包括：

获取与本节点处于连接状态的拉流节点的丢包率以及子流时延，并根据所述丢包率以及子流时延确定所述拉流节点的评分；

选取评分最高的N个拉流节点作为目标拉流节点，其中，N大于或等于1。

3.根据权利要求1或2所述的方法，其特征在于，所述判断所述目标拉流节点与本节点是否存在订阅关系，包括：

获取本节点的订阅关系列表，其中，所述订阅关系列表中包括所有订阅本节点的已订阅节点的标识，以及，所有订阅所述已订阅节点的节点的标识；

在所述订阅关系列表中查找所述目标拉流节点的标识；

若查找成功，则判定所述目标拉流节点与本节点存在订阅关系；

若查找不成功，则判定所述目标拉流节点与本节点不存在订阅关系。

4.根据权利要求3所述的方法，其特征在于，所述获取本节点的订阅关系列表，包括：

接收本节点的已订阅节点上报的订阅关系，汇总本节点与所述已订阅节点的订阅关系以及所述已订阅节点上报的订阅关系，得到所述订阅关系列表，其中，所述已订阅节点上报的订阅关系为所述已订阅节点被其他节点订阅的订阅关系；

或者，

从对等网络服务器中请求所述订阅关系列表，其中，所述订阅关系列表为所述对等网络服务器接收到各个拉流节点上报的订阅关系后汇总得到的列表。

5.根据权利要求1或2所述的方法，其特征在于，所述判断所述目标拉流节点与本节点是否存在订阅关系，包括：

根据所述目标拉流节点的标识生成查询请求，并将所述查询请求发送至对等网络服务器中；

当接收到所述对等网络服务器发送的允许订阅响应时，判定所述目标拉流节点与本节点不存在订阅关系，其中，所述允许订阅响应为所述对等网络服务器从服务器本地维护的本节点的订阅关系列表中查找不到所述目标拉流节点的标识时返回的响应信息。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当接收到所述目标拉流节点返回的同意订阅消息时或者接收到所述目标拉流节点发送的切片子流时，将本节点与所述目标拉流节点的订阅关系上报至对等网络服务器中。

7.根据权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

将接收到的切片子流发送至订阅本节点的拉流节点中。

8.一种拉流的装置，其特征在于，所述装置应用于直播系统的拉流节点中，所述装置包括：

拉流请求生成模块，用于生成拉流请求；

目标拉流节点确定模块，用于从与本节点处于连接状态的拉流节点中选择至少一个拉流节点作为目标拉流节点；

订阅关系判断模块，用于判断所述目标拉流节点与本节点是否存在直接或间接的订阅关系；

拉流请求发送模块，用于若所述目标拉流节点与本节点不存在订阅关系，则向所述目标拉流节点发送所述拉流请求，以请求从所述目标拉流节点中获取对应的切片子流。

9.一种直播系统，其特征在于，所述直播系统包括主播端、主播侧CDN服务器、主播侧网络服务器、切片服务器、观众侧CDN服务器以及观众侧对等网络，其中，所述观众侧对等网络中包括对等网络服务器以及多个拉流节点；

所述主播端用于采集音视频流并向所述主播侧CDN服务器推流；

所述主播侧CDN服务器用于将接收到的主播端发送的音视频流发送至所述主播侧网络服务器中；

所述主播侧网络服务器用于对接收到的音视频流进行处理，并将处理后的音视频流发送至切片服务器中；

所述切片服务器用于对接收到的主播侧网络服务器发送的音视频流进行切片处理，生成多个切片子流，并将所述切片子流发送至观众侧CDN服务器中；

所述观众侧CDN服务器用于将接收到的切片子流分发至接入的拉流节点中；

所述对等网络服务器用于接收拉流节点的注册，以及对所述观众侧的CDN服务器的切片子流分发情况进行管理；

所述拉流节点用于向所述观众侧CDN服务器请求切片子流；

其中，所述拉流节点还用于执行权利要求1-7任一项所述的拉流的方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求1-7任一项所述方法的步骤。

11.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1-7任一项所述方法的步骤。