CN112788135B - 资源调度方法、设备及存储介质 - Google Patents
资源调度方法、设备及存储介质 Download PDFInfo
- Publication number
- CN112788135B CN112788135B CN202110008115.5A CN202110008115A CN112788135B CN 112788135 B CN112788135 B CN 112788135B CN 202110008115 A CN202110008115 A CN 202110008115A CN 112788135 B CN112788135 B CN 112788135B
- Authority
- CN
- China
- Prior art keywords
- node
- resource
- p2sp
- hash
- accessed
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 129
- 238000003860 storage Methods 0.000 title claims abstract description 13
- 230000008569 process Effects 0.000 claims abstract description 30
- 101150060512 SPATA6 gene Proteins 0.000 claims description 289
- 239000012634 fragment Substances 0.000 claims description 33
- 238000012545 processing Methods 0.000 claims description 17
- 230000003111 delayed effect Effects 0.000 claims description 11
- 238000004590 computer program Methods 0.000 claims description 9
- 238000012544 monitoring process Methods 0.000 claims description 7
- 239000002699 waste material Substances 0.000 abstract description 6
- 230000002035 prolonged effect Effects 0.000 abstract 1
- 230000005540 biological transmission Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 6
- 238000012546 transfer Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000001133 acceleration Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000004080 punching Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000004904 shortening Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
- H04L67/1065—Discovery involving distributed pre-established resource-based relationships among peers, e.g. based on distributed hash tables [DHT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本发明公开了一种资源调度方法、设备及存储介质。本发明中,通过将现有由Tracker调度服务器提前向多个P2SP节点派发待访问资源改为仅由确定的目标P2SP节点获取待访问资源,从而减少了预测误差造成的资源浪费和内耗;在目标P2SP节点获取待访问资源的过程中,目标P2SP节点还向下发资源请求的P2P节点分享获取到的待访问资源,实现了待访问资源的边获取边分享,有效提高了P2P分享率;通过将P2P节点与接入P2P网络的P2SP节点预先建立P2P链接,从而提升了资源可服务时长;通过将P2P节点与P2SP节点预先建立P2P链接,大大减少首包过程,从而能够更好地适用于极短视频场景中。
Description
技术领域
本发明实施例涉及P2P技术领域,特别涉及一种资源调度方法、设备及存储介质。
背景技术
P2P(peer-to-peer)技术,即对等网络传输技术,是近年来兴起的一种新型通讯网络传输技术。它在传输方式上打破了传统网络的服务器/客户端(Client-Server,C/S)模式,建立了一种客户端对客户端的直接通信机制。在对等网络中,每一节点既作为客户端,又充当他人的服务端,从某种意义上,每一节点都处在同等地位。对等网络是对分布式概念的成功拓展,它将传统方式下的服务器负担分配到网络中的每一节点上,不仅可以大大减轻服务器处理压力,也能节省大量的内容分发网络(Content Delivery Network,CDN)流量成本。
对于服务质量要求更高的一些场景,如短视频点播等业务,服务商会部署一些性能更高的超级节点(可以称之为P2SP节点),用于提升服务质量。这些P2SP节点往往会部署在服务商自己组建的廉价机房内部或者是家庭网络中,混入到P2P网络中提供更加优质且稳定的P2P传输服务。
然而,由于混入到P2P网络中的P2SP节点,往往只提供P2P分享,为了保证这些P2SP节点能够提供P2P分享,目前的资源调度方案,通常是由Tracker调度服务器提前预测哪些P2SP节点将会参与到P2P分享,进而将需要分享的资源预先派发到预测的P2SP节点,当派发的资源下载完成后,这些P2SP节点才会加入到P2P分享。虽然这种方式可以让P2SP节点参与到P2P网络中,为网络中的P2P节点提供P2P分享,但是这种由Tracker预派发的方式,会存在预测误差,这就会导致P2P服务的周期变长,进而影响P2P分享效率。同时,也会因为预测误差,导致预部署的资源无人访问,进而造成资源浪费,并增加内耗。
除此之外,目前应用于资源调度方案,需要从P2SP节点获取资源的P2P节点,需要先通过内容索引服务器定位到待访问资源对应的P2SP节点,然后再向定位的P2SP节点进行建连,并请求资源,这就导致一些极短视频场景中,整个首包过程,进一步影响P2P分享率。
发明内容
本发明实施例的目的在于提供一种资源调度方法、设备及存储介质,旨在解决上述技术问题。
为解决上述技术问题,本发明的实施例提供了一种资源调度方法,应用于P2P节点,所述资源调度方法包括:
在接收到用户对待访问资源的访问请求时,确定所述待访问资源的统一资源定位符URL;
对所述URL进行哈希处理,得到所述URL对应的哈希序列号;
从预先建连的P2SP节点中选取与所述哈希序列号匹配的目标P2SP节点,并向所述目标P2SP节点下发资源请求,供所述目标P2SP节点获取并向所述P2P节点分享所述资源片段。
本发明的实施例还提供了一种资源调度方法,应用于Tracker调度服务器,所述资源调度方法包括:
在接收P2P节点下发的哈希列表获取请求时,统计管理的哈希索引表中记录的哈希索引的索引个数;
从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号,所述节点序列号用于标识P2SP节点,每一所述哈希索引对应的节点序列号集中记录的节点序列号互不相同;
根据所述索引个数、选取的所述节点序列号及所述节点序列号所属的所述哈希索引生成所述哈希列表,并将所述哈希列表下发给所述P2P节点。
本发明的实施例还提供了一种资源调度方法,应用于P2SP节点,所述资源调度方法包括:
在接收到P2P节点下发的资源请求时,根据所述资源请求中携带的资源请求范围,确定当前需要访问的资源片段;
查找本地缓存中是否存在所述资源片段;
若存在,则从所述本地缓存读取所述资源片段,并向所述P2P节点分享所述资源片段;
否则,根据所述资源请求中携带的URL确定所述资源片段所属的待访问资源,从内容分发网络CDN请求所述待访问资源,并在从所述CDN下载所述待访问资源的过程中,将获取到的所述资源片段分享至所述P2P节点。
本发明的实施例还提供了一种资源调度设备,包括:
至少一个处理器;以及,
与所述至少一个处理器通信连接的存储器;其中,
所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行如上文所述的应用于P2P节点的资源调度方法,或者应用于Tracker调度服务器的资源调度方法,或者应用于P2SP节点的资源调度方法。
本发明的实施例还提供了一种计算机可读存储介质,存储有计算机程序,所述计算机程序被处理器执行时实现如上文所述的应用于P2P节点的资源调度方法,或者应用于Tracker调度服务器的资源调度方法,或者应用于P2SP节点的资源调度方法。
本发明实施例提供的资源调度方法、设备及存储介质,P2P节点在接收到用户对待访问资源的访问请求时,通过对访问请求中携带的URL进行哈希处理,进而从预先建连的P2SP节点中选取与哈希处理后得到的哈希序列号匹配的P2SP节点作为目标P2SP节点,最终只需向目标P2SP节点下发资源请求,供目标P2SP节点获取并向P2P节点分享待访问资源即可。即,将现有由Tracker调度服务器提前向多个P2SP节点派发待访问资源改为仅由确定的目标P2SP节点获取待访问资源,从而减少了预测误差造成的资源浪费和内耗。
同时,在目标P2SP节点获取待访问资源的过程中,目标P2SP节点还向下发资源请求的P2P节点分享获取到的待访问资源,实现了待访问资源的边获取边分享,从而缩短了等待时长,即加快了资源可服务时长,有效提高了P2P分享率。
除此之外,P2P节点与接入P2P网络的P2SP节点预先建立P2P链接,从而使得本发明实施例提供的P2SP内容调度方案能够进一步提升资源可服务时长。
同时,通过将P2P节点与P2SP节点预先建立P2P链接,能够大大减少首包过程,使得本发明实施例提供的P2SP节点的调度方案能够更好地适用于极短视频场景中。
另外,在所述接收到用户对待访问资源的访问请求之前,所述还包括:向Tracker调度服务器下发哈希列表获取请求,供所述Tracker调度服务器确定管理的哈希索引表中记录的哈希索引的索引个数,并从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号,并根据所述索引个数、选取的所述节点序列号及所述节点序列号所属的所述哈希索引生成所述哈希列表,所述节点序列号用于标识所述P2SP节点,每一所述哈希索引对应的节点序列号集中记录的节点序列号互不相同;接收所述Tracker调度服务器下发的所述哈希列表,并根据所述哈希列表中记录的所述节点序列号定位需要建连的所述P2SP节点;基于预设的建连方式,与定位的所述P2SP节点建连。本发明的实施例,在实现P2P节点从同一P2P网络中的P2SP节点获取待访问资源前,预先与每一个哈希索引对应的节点序列号集群中P2SP节点建立连接,从而实现了与每一个哈希索引对应的至少一个P2SP节点的连接,进而在后续接收到用户的待访问资源的访问请求时,能够确保可以提供待访问资源的P2SP节点已经与P2P节点建立连接,进而缩短了获取待访问资源的等待时间。
另外,所述从预先建连的P2SP节点中选取与所述哈希序列号匹配的目标P2SP节点,包括:根据所述哈希列表中记录的所述索引个数和所述哈希序列号,确定目标哈希索引;根据所述目标哈希索引,从预先建连的P2SP节点中定位与所述目标哈希索引匹配的所述哈希索引,并从定位的所述哈希索引对应所述节点序列号中,选取与所述哈希序列号匹配的所述节点序列号对应的所述P2SP节点,得到所述目标P2SP节点。本发明的实施例,给出了一种从预先建连的P2SP节点中选取能够为P2P节点提供待访问资源的目标P2SP节点的一种具体实现方式,实现了将现有由Tracker调度服务器提前向多个P2SP节点派发待访问资源改为仅由确定的目标P2SP节点获取待访问资源,从而减少了预测误差造成的资源浪费和内耗。
另外,在所述基于预设的建连方式,与定位的所述P2SP节点建连之后,所述方法还包括:监测与定位的所述P2SP节点之间的建连是否断开;若断开,则获取定位的所述P2SP节点对应的所述节点序列号所属的所述哈希索引,并从所述Tracker调度服务器获取所述哈希索引对应的节点序列号集中重新选取需要下发的节点序列号;基于预设的所述建连方式,与重新获取的所述节点序列号对应的P2SP节点建连。本发明的实施例,在实现P2P节点与P2SP节点之间的预建连后,通过监测与已经建立连接的P2SP节点之间的链路,并在监测到链路断开时,重新从Tracker调度服务器获取哈希索引,进而确定可以建连的P2SP节点,并与重新确定的P2SP节点建连,从而保证了每一个哈希索引都对应有至少一个与P2P节点连接的P2SP节点,确保预建连的P2SP节点中始终存在能够提供不同哈希序列号对应的待访问资源的P2SP节点。
另外,在所述基于预设的建连方式,与定位的所述P2SP节点建连之后,所述方法还包括:接收所述Tracker调度服务器下发的所述哈希列表;将当前时刻接收到的所述哈希列表与所述当前时刻之前接收到的所述哈希列表进行匹配;若不匹配,则根据所述当前时刻接收的所述哈希列表中记录的所述节点序列号重新定位需要建连的所述P2SP节点;基于预设的所述建连方式,与重新定位的所述P2SP节点建连。本发明的实施例,在整个资源调度过程中,P2P节点与P2SP节点之间的连接是实时更新的,即P2P节点能够与接入P2P网络的所有所属哈希索引不同的P2SP节点预建连。
另外,所述资源请求包括是否可延迟标签、资源对应的完整URL、资源请求范围和请求失效时间;在请求的所述待访问资源为视频资源的首包数据时,所述是否可延迟标签对应的标志信息为预设的不可延迟标志符;其中,在所述标志信息为预设的不可延迟标志符,且所述目标P2SP节点的本地缓存中不存在所述资源请求范围对应的所述首包数据时,供所述目标P2SP节点从内容分发网络CDN请求所述首包数据,并在从所述CDN下载所述首包数据的过程中,将获取到的所述首包数据分享至所述P2P节点;在所述标志信息为预设的可延迟标志符,且所述目标P2SP节点的本地缓存中不存在所述资源请求范围对应的所述首包数据时,供所述目标P2SP节点将所述资源请求添加到预先构建的等待队列,等待从CDN获取到所述资源片段时,并将获取到的所述首包数据分享至所述P2P节点。本发明的实施例给出了一种资源请求包括的具体内容,并且规定视频资源的首包数据不支持延迟,从而有效避免了时延导致首屏等待时间过长,造成用户界面一直黑屏,影响用户体验的问题。
另外,所述从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号,包括:确定所述节点序列号集中每一节点序列号对应的所述P2SP节点支持链接的P2P节点的节点格式,以及预设选取指标对应的指标值;根据所述节点格式和所述指标值,确定所述节点序列号集中满足要求的所述P2SP节点;获取满足要求的所述P2SP节点对应的所述节点序列号,得到需要下发的所述节点序列号。本发明的实施例,通过基于节点序列号集中每一节点序列号对应的所述P2SP节点支持链接的P2P节点的节点格式,以及预设选取指标对应的指标值来选取需要下发的P2SP节点,从而保证了最终与P2P节点预建连的P2SP节点能够更好地为P2P节点提供资源分享,进而提高P2P分享率。
另外,所述方法还包括:接收加入到P2P网络中的所述P2SP节点的注册请求,从所述注册请求中提取携带的所述P2SP节点对应的历史节点序列号;统计每一所述哈希索引对应的节点序列号集中记录的所述节点序列号的序列号个数;根据所述历史节点序列号和所述序列号个数,为所述P2SP节点分配节点序列号,并添加到对应的所述哈希索引对应的所述节点序列号集中。本发明的实施例,在整个资源调度过程中,Tracker调度服务器不断接收加入到P2P网络中的P2SP节点的注册请求,并为发起注册请求的P2SP节点分配节点序列号,从而实现了对管理的哈希索引表的实时更新,确保了哈希索引表中记录了P2P网络中所有可以提供资源分享的P2SP节点,进而能够更好地服务于需要获取待访问资源的P2P节点。
另外,所述根据所述历史节点序列号和所述序列号个数,为所述P2SP节点分配节点序列号,包括:计算每一所述哈希索引对应的所述序列号个数之间的差值百分比;若所述差值百分比大于预设阈值,则将所述序列号个数最少的所述哈希索引对应的所述节点序列号集中的所述节点序列号分配给所述P2SP节点;否则,将所述历史节点序列号分配给所述P2SP节点。本发明的实施例,给出了一种为申请注册的P2SP节点分配节点序列号的具体方式,通过这种负载均衡的方式,有效避免了P2SP节点频繁地变换所属的哈希索引,进而提高了缓存命中率。
另外,在所述从内容分发网络CDN请求完整的所述待访问资源之前,所述方法还包括:判断所述本地缓存中是否存在完整的所述资源片段;若存在,则执行所述从本地缓存读取所述待访问资源的步骤;否则,获取所述资源请求中是否可延迟标签对应的标志信息,并在所述标志信息为预设的不可延迟标志符时,从所述CDN请求所述资源片段,并在从所述CDN下载所述资源片段的过程中,将获取到的所述资源片段分享至所述P2P节点;在所述标志信息为预设的可延迟标志符时,将所述资源请求添加到预先构建的等待队列,等待从CDN获取到所述资源片段时,执行所述将获取到的所述资源片段分享至所述P2P节点的步骤。本发明的实施例提供了一种根据资源请求中是否可延迟标签的标志信息进行资源调度的方式,使得P2SP节点能够针对P2P节点需要优先获取的数据,比如影响视频内容播放的首屏数据,能够在本地缓存没有完整的首屏数据时,及时进行CDN回源,进而快速将首屏数据分享给P2P节点,避免长时间等待,而对于优先级相对低的数据,通过将资源请求挂到等待队列,在数据到达后才进行分享,从而尽可能降低了同一时刻对资源的占用。
另外,所述从内容分发网络CDN请求完整的所述待访问资源,包括:从所述资源请求中获取所述资源请求范围的起始点;判断所述起始点是否为0;若是,则从所述CDN请求完整的所述待访问资源;否则,分别从所述CDN请求从0开始到所述起始点对应的所述待访问资源的片段,以及从所述起始点开始到所述待访问资源的终止点对应的所述待访问资源的资源片段。本发明的实施例,通过设置用于向P2P节点提供资源分享的P2SP节点,在从CDN获取待访问资源的过程中,向下发资源请求的P2P节点分享获取到的待访问资源,实现了待访问资源的边获取边分享,从而缩短了等待时长,即加快了资源可服务时长,有效提高了P2P分享率。
另外,所述从内容分发网络CDN请求完整的所述待访问资源,包括:在从所述CDN中获取到所述待访问资源的头部信息后,根据所述头部信息预估获取所述资源请求范围对应的所述待访问资源的超时时间;判断所述超时时间是否大于所述资源访问请求中携带的请求失效时间;若大于,则通知所述P2P节点所述待访问资源还未准备好,以使所述P2P节点直接从所述CDN获取所述待访问资源;否则,将所述资源请求添加到预先构建的等待队列,等待从CDN获取到所述资源片段时,执行所述将获取到的所述资源片段分享至所述P2P节点的步骤。本发明的实施例,通过根据待访问资源的头部信息预估获取所述资源请求范围对应的所述待访问资源的超时时间,进而根据预估的超时时间与资源请求中携带的请求失效时间确定P2P节点究竟是等待P2SP节点下发待访问资源,还是直接从CDN获取待访问资源,使得用户能够实时获知当前进度,避免长时间的等待,从而更好地提升了用户体验。
附图说明
一个或多个实施例通过与之对应的附图中的图片进行示例性说明,这些示例性说明并不构成对实施例的限定,附图中具有相同参考数字标号的元件表示为类似的元件,除非有特别申明,附图中的图不构成比例限制。
图1是本发明第一实施例提供的应用于P2P节点的资源调度方法的流程图;
图2是本发明第一实施例提供的资源调度方法实现过程中涉及的P2P节点、Tracker调度服务器、P2SP节点和CDN的架构示意图;
图3是基于图2所示的架构中P2P节点、Tracker调度服务器、P2SP节点和CDN进行资源调度的交互示意图;
图4是本发明第二实施例提供的应用于Tracker调度服务器的资源调度方法的流程图;
图5是本发明第三实施例提供的应用于P2SP节点的资源调度方法的流程图;
图6是本发明第四实施例的部署于P2P节点的资源调度装置的结构示意图;
图7是本发明第五实施例的部署于Tracker调度服务器的资源调度装置的结构示意图;
图8是本发明第六实施例的部署于P2SP节点的资源调度装置的结构示意图;
图9是本发明第七实施例的资源调度设备的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合附图对本发明的各实施例进行详细的阐述。然而,本领域的普通技术人员可以理解,在本发明各实施例中,为了使读者更好地理解本申请而提出了许多技术细节。但是,即使没有这些技术细节和基于以下各实施例的种种变化和修改,也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便,不应对本发明的具体实现方式构成任何限定,各个实施例在不矛盾的前提下可以相互结合相互引用。
本发明的第一实施例涉及一种资源调度方法,应用于P2P节点。
可理解的,P2P节点,即对等网络节点是指在内容分发网络(Content DeliveryNetwork,CDN)行业里常见的用户共享带宽加速服务。由用户通过个人电脑、路由器等设备共享家庭闲置的上行网络带宽,成为一个微型的CDN分发服务节点,使得其他客户在下载、直播、游戏等场景时获得就近加速体验。
也就是说,P2P节点,可以是个人电脑、路由器等终端设备。
下面对本实施例的资源调度方法的实现细节进行说明,以下内容仅为方便理解而提供的实现细节,并非实施本方案的必须。
本实施例的具体流程如图1所示,具体包括以下步骤:
步骤101,在接收到用户对待访问资源的访问请求时,确定所述待访问资源的统一资源定位符URL。
可理解的,所述同一资源定位符(Uniform Resource Locator,URL)是因特网的万维网服务程序上用于指定信息位置的表示方法。故而,根据URL便可以定位待访问资源所在的具体位置。
此外,可理解的,在实际应用中所述待访问资源包括,但不限于文本资源、音视频资源、图片资源等。
步骤102,对所述URL进行哈希处理,得到所述URL对应的哈希序列号。
由于哈希算法已经较为成熟,本实施例对于如何使用哈希算法对URL进行哈希处理,进而得到哈希序列号的实现方式不再赘述,本领域技术人员可以自行查阅相关文献实现。
步骤103,从预先建连的P2SP节点中选取与所述哈希序列号匹配的目标P2SP节点,并向所述目标P2SP节点下发资源请求,供所述目标P2SP节点获取并向所述P2P节点分享所述资源片段。
可理解的,为了保证P2P节点在接收到用户对待访问资源的访问请求时,无需通过内容索引服务器定位到待访问资源对应的P2SP节点,然后再向定位的P2SP节点进行建连,并请求资源,在实现本实施例提供的资源调度方法之前,即在接收到用户对待访问资源的访问请求之前,P2P节点就需要实现与同一P2P网络中能够提供资源分享的P2SP节点建立连接,从而保证在接收到用户对待访问资源的访问请求时,能够快速从预先建立的P2SP节点中选取与待访问资源的URL对应的哈希序列号匹配的P2SP节点,作为向P2P节点提供待访问资源的目标P2SP节点。
关于P2P节点与同一P2P网络中的P2SP节点的预建连,在实际应用中,需要借助Tracker调度服务器。
具体的,Tracker调度服务器管理了接入P2P网络,并向其下发了注册请求的所有P2SP节点的节点序列号。因此,P2P节点在借助Tracker调度服务器实现与同一P2P网络中的P2SP节点的预建连时,具体是通过向Tracker调度服务器下发哈希列表获取请求,进而根据Tracker调度服务器下发的哈希列表中记录的节点序列号定位需要建连的P2SP节点,最终基于预设的建连方式,比如网络打洞的方式,与定位的P2SP节点建立。
关于网络打洞的建连方式,具体涉及网络地址转换(Network AddressTranslation,NAT)的使用原理,在实际应用中,本领域技术人员可以通过查阅相关资料自行实现,此处不再赘述。
此外,需要说明的,上述所说的哈希列表,具体是由Tracker调度服务器根据管理的哈希索引表中记录的哈希索引的索引个数,并从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号,并根据所述索引个数、选取的所述节点序列号及所述节点序列号所属的所述哈希索引生成的。
此外,在本实施例中,所述节点序列号具体用于标识所述P2SP节点,且每一所述哈希索引对应的节点序列号集中记录的节点序列号互不相同。
也就是说,在实际应用中,P2P节点会与每一哈希索引下的至少一个P2SP节点预先建连。
基于此,在P2P节点与P2SP预建连后,所述从预先建连的P2SP节点中选取与所述哈希序列号匹配的目标P2SP节点,具体为:
(1)根据所述哈希列表中记录的所述索引个数和所述哈希序列号,确定目标哈希索引。
具体的说,在实际应用中,哈希索引表中哈希索引是基于哈希桶,即通常所说的HASH BUCKET确定的。
比如,配置的HASH BUCKET大小为3,则生成的哈希索引表中的哈希索引一次为哈希索引1,哈希索引2和哈希索引3这三个哈希索引。即,哈希索引的索引个数等于HASHBUCKET的大小。
此外,为了更好地理解本实施例提供的资源调度方法,关于Tracker调度服务器管理的哈希索引表的结构,在实际应用中可以如表1所示:
表1哈希索引表
哈希索引 | 节点序列号集 |
Index1 | 节点序列号11、节点序列号12、节点序列号13...节点序列号1L |
Index2 | 节点序列号21、节点序列号22、节点序列号23...节点序列号1M |
Index3 | 节点序列号31、节点序列号32、节点序列号33...节点序列号1N |
需要说明的是,在实际应用中,每个哈希索引对应的节点序列号集中的节点序列号,可以存在相同的,比如对于Index1对应的节点序列号集中存在的节点序列号11、节点序列号12、节点序列号13...节点序列号1L,可以是L个相同的节点序列号,即这L个节点序列号对应的P2SP节点均用于提供相同的待访问资源,也可以是互不相同的L个节点序列号,即这L个节点序列对应的P2SP节点是用于分别提供不同的待访问资源的。
进一步地,为了实现根据索引个数和待访问资源的URL哈希处理得到的哈希序列号,定位不同哈希索引对应的节点序列号集中节点序列号对应的P2SP节点,每一个哈希索引对应的节点序列号集中的节点序列号需要互不相同,即Index1对应的节点序列号集中的节点序列号11、节点序列号12、节点序列号13...节点序列号1L,与Index2对应的节点序列号集中的节点序列号21、节点序列号22、节点序列号23...节点序列号1M,以及Index3对应的节点序列号集中的节点序列号31、节点序列号32、节点序列号33...节点序列号1N是不相同的。
同理,Index2对应的节点序列号集中的节点序列号21、节点序列号22、节点序列号23...节点序列号1M,与Index3对应的节点序列号集中的节点序列号31、节点序列号32、节点序列号33...节点序列号1N也是不相同的。
基于此,P2P节点在接收到Tracker调度服务器下发的携带有索引个数和从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号(至少为一个)时,根据所述哈希列表中记录的所述索引个数和所述哈希序列号,确定目标哈希索引,具体为:将所述哈希序列号作为被除数,将所述索引个数作为除数,进而通过将二者相除取余,得到确定目标P2SP节点所要用到的目标哈希索引。
(2)根据所述目标哈希索引,从预先建连的P2SP节点中定位与所述目标哈希索引匹配的所述哈希索引,并从定位的所述哈希索引对应所述节点序列号中,选取与所述哈希序列号匹配的所述节点序列号对应的所述P2SP节点,得到所述目标P2SP节点。
比如说,哈希列表中记录的索引个数为3,从Index1对应的节点序列号集中选取的节点序列号为节点序列号11,从Index2对应的节点序列号集中选取的节点序列号为节点序列号22,从Index3对应的节点序列号集中选取的节点序列号为节点序列号31和节点序列号33。
若通过取余,确定的目标哈希索引为3,则最终从预先建连的P2SP节点中选取与哈希序列号节点匹配的目标P2SP节点的操作,具体是从Index3对应的节点序列号31和节点序列号33中选取。
进一步地,若通过将URL对应的哈希序列号与节点序列号31和节点序列号33进行对比,发现哈希节点序列号与节点序列号33匹配,则选取节点序列号33对应的P2SP节点作为目标P2SP节点。
此外,在实际应用中,为了确定每一P2SP节点所属的哈希索引对应的节点序列号集群。Tracker调度服务器需要预先为接入P2P网络,并且向其发起注册请求的P2SP节点分配对应的节点序列号,并划分P2SP节点所对应的哈希索引。
为了更好地理解本实施例中提供的资源调度方法,以下结合图2所示的资源调度架构,以及图3所示的针对图2所示的资源调度架构中的各节点的交互,对资源调度进行具体说明。
如图2、图3所示,本实施例中所说的资源调度架构包括P2P节点、Tracker调度服务器、与P2P节点预建连的P2SP节点,以及CDN。
对于接入P2P网络的P2SP节点,如图2中的P2SP节点1、P2SP节点2和P2SP节点3,想要向P2P节点提供资源分享服务,在接入P2P网络后,需要从Tracker调度服务器获取对应的哈希索引,即表1中所说的Index1,或Index2,或Index3。
假设,经Tracker调度服务器出了后,最终在哈希索引表中记录的是P2SP节点1对应Index1,同时分配的节点序列号为节点序列号11;P2SP节点2对应Index2,同时分配的节点序列号为节点序列号21;P2SP节点3对应Index3,同时分配的节点序列号为节点序列号31。
对于P2P节点,在执行上述步骤101至步骤103的资源调度方法之前,需要先从Tracker调度服务器获取哈希列表。
对于Tracker调度服务器,在接收到P2P节点下发的获取哈希列表的请求后,先统计管理的哈希索引表中记录的哈希索引的索引个数;然后,从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号;最后,根据所述索引个数、选取的所述节点序列号及所述节点序列号所属的所述哈希索引生成所述哈希列表,并将所述哈希列表下发给所述P2P节点。
接着,P2P节点在接收到Tracker调度服务器下发的哈希列表后,会根据所述哈希列表中记录的所述节点序列号定位需要建连的所述P2SP节点,如图2中的P2SP节点1、P2SP节点2和P2SP节点3,进而基于预设的建立方式,如网络打洞方式,与定位的P2SP节点1、P2SP节点2和P2SP节点3建立,即使P2P节点与P2SP节点1、P2SP节点2和P2SP节点3建立P2P链接。
具体的,在实际应用中,P2P节点从Tracker调度服务器获取哈希列表,进而根据哈希列表与同一P2P网络中的P2SP节点预建连的操作,是在P2P节点中的软件开发工具包(Software Development Kit,SDK)启动时,与Tracker调度服务器下发的哈希列表中记录的选取的所有节点序列号对应的P2SP节点进行预建连。
可理解的,由于哈希列表中记录了每一哈希索引对应的节点序列号集中选取的节点序列号,故而P2P节点在根据哈希序列表与P2SP预建连后,便可以确保P2P节点能够与同一P2P网络中能够提供不同资源分享服务的P2SP节点进行通信。
进一步地,为了保证P2P节点在接收到用户对待访问资源的访问请求时,能够直接与同一P2P网络中能够提供不同资源分享服务的P2SP节点进行通信中,需要确保与预建连的P2SP节点之间的链接始终处于可用状态。
故而,在与定位的P2SP节点建连后,需要监测与定位的所述P2SP节点之间的建连是否断开。
相应地,若断开,则获取定位的所述P2SP节点对应的所述节点序列号所属的所述哈希索引,并从所述Tracker调度服务器获取所述哈希索引对应的节点序列号集中重新选取需要下发的节点序列号,然后再次基于预设的所述建连方式,与重新获取的所述节点序列号对应的P2SP节点建连。
比如说,若通过监测,确定图2中的P2P节点与P2SP节点1之间的P2P链接断开了,由于P2SP节点1对应的节点序列号11所属的哈希索引为Index1,则P2P节点需要重新从Tracker调度服务器获取Index1对应的节点序列号集中选取至少一个节点序列号。
可理解的,重新获取的节点序列号,可以是新加入Index1对应的节点序列号集中的P2SP节点4的节点序列号,这样P2P节点便会与P2SP节点4预建连;当然,重新获取的节点序列号依旧可以是P2SP节点1对应的节点序列号,即重新进行的预建连,是与断开连接的P2SP节点1重新建连。
此外,可理解的是,在实际应用中,可能存在不断有新加入P2P网络的P2SP节点注册到Tracker调度服务器管理的哈希索引表中,以及原有的P2SP节点退出P2P网络。故而,为了保证每一哈希索引都一直有对应的P2SP节点与P2P节点建连,在整个资源调度过程中,P2P节点都可以接收Tracker调度服务器下发的哈希列表。
相应地,在每次接收到Tracker调度服务器下发的哈希列表之后,P2P节点都需要将当前时刻接收到的哈希列表与当前时刻之前接收到的哈希列表进行匹配。
所谓当前时刻之前的哈希列表,即P2P节点当前与P2SP节点建连时所依旧的哈希列表。
相应地,若通过匹配,确定二者不匹配,则根据当前时刻接收到的哈希列表中记录的节点序列号重新定位需要建连的P2SP节点,然后基于预设的建连方式,与重新定位的P2SP节点建连。
基于此,可以保证每一个哈希索引都一直有对应的P2SP节点与P2P节点预建连。从而在用户需要获取对应的待访问资源时,直接将待访问资源的URL进行哈希处理,进而根据得到的哈希序列号,从预建连的P2SP节点中选取匹配的目标P2SP节点进行资源请求即可,从而有效减少了现有在接收到待访问资源的资源请求时,才与P2SP节点进行建连所需的时间,大大加快了首包速度,提升了P2P分享率。
除此之外,通过对URL进行哈希处理,然后根据得到的哈希序列号选取目标P2SP节点,可以有效保证同样的URL去往同一批P2SP节点,从而增加了P2SP节点的缓存命中率。
进一步地,在完成上述操作后,若P2P节点接收到了用户对待访问资源的访问请求时,会对待访问资源的URL进行哈希处理,进而得到哈希序列号,然后按照上述步骤(1)和步骤(2)确定目标P2SP节点,并向确定的目标P2SP节点下发资源请求。
此外,需要说明的是,在本实施例中,P2P节点向目标P2SP节点下发的资源请求包括是否可延迟标签、资源对应的完整URL、资源请求范围和请求失效时间。
为了便于理解,以下给出资源请求的部分伪代码:
其中,“URL”后根据的“http://test.example.com/1.mp4”即待访问资源的完整URL;“delay”即是否可延迟标签,如果在实际应用中,其后携带的具体信息为“true”,则表示允许存在延迟,若携带的具体信息为“false”,则表示不允许延迟;“range”即资源请求范围,即用户想要获取的待访问资源的具体部分,如上所示的“0-100”表示从起始点0开始获取待访问资源至100的位置;“timeout”即请求失效时间,如上所示的“100”表示当前资源请求的请求失效时间为100ms。
可理解的,在资源调度的过程中,为了尽可能缩短用户等待时间,通常设置的请求失效时间时以毫秒(ms)为单位的,故而上述所示的“100”,在本实施例中是指100ms。
此外,本实施例中所说的资源请求范围的单位,类似于普通的超文本传输协议(Hypertext Transfer Protocol,http)range请求的格式,比如在待访问资源的大小为1024Byte时,上述所说的“0-100”具体是指待访问资源从0Byte开始到100Byte之间的内容。
此外,可理解的是,关于“delay”后跟的标识,在实际应用中,除了可以采用“true”或“false”标识,还可以用“0”或“1”标识,即只要预先约定好即可。
基于上述格式的资源请求,本实施例规定,在请求的待访问资源为视频资源的首包数据时,所述是否可延迟标签delay对应的标志信息为预设的不可延迟标识符,即上述所说的“false”或“1”。
此外,可理解的,在实际应用中,当请求的待访问资源为视频资源的首包数据时,为了避免首屏等待时间过长所造成用户界面一直黑屏,进而影响用户体验的问题发生,所述是否可延迟标签对应的标志信息为预设的不可延迟标志符,比如上述所说的“false”。
相应地,在所述标志信息为预设的不可延迟标志符,且所述目标P2SP节点的本地缓存中不存在所述资源请求范围对应的所述首包数据,即不存在需要请求的完整的首包数据时,供所述目标P2SP节点从内容分发网络CDN请求所述首包数据,并在从所述CDN下载所述首包数据的过程中,将获取到的所述首包数据分享至所述P2P节点。
在所述标志信息为预设的可延迟标志符,且所述目标P2SP节点的本地缓存中不存在所述资源请求范围对应的所述首包数据时,供所述目标P2SP节点将所述资源请求添加到预先构建的等待队列,等待从CDN获取到所述资源片段时,并将获取到的所述首包数据分享至所述P2P节点。
对于目标P2SP节点,在接收到P2P节点下发的资源请求时,首先,根据所述资源请求中携带的资源请求范围,确定当前需要访问的资源片段;然后,查找本地缓存中是否存在所述资源片段。
相应地,若存在,则从所述本地缓存读取所述资源片段,并向所述P2P节点分享所述资源片段。
若在本地缓存中未查找到所述资源片段,则根据所述资源请求中携带的URL确定所述资源片段所属的待访问资源,从内容分发网络CDN请求所述待访问资源,并在从所述CDN下载所述待访问资源的过程中,将获取到的所述资源片段分享至所述P2P节点,从而实现资源片段的边获取边分享。
应当理解的是,上述示例仅是为了更好地理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
通过上述描述不难发现,本实施例中提供的资源调度方法,P2P节点在接收到用户对待访问资源的访问请求时,通过对访问请求中携带的URL进行哈希处理,进而从预先建连的P2SP节点中选取与哈希处理后得到的哈希序列号匹配的P2SP节点作为目标P2SP节点,最终只需向目标P2SP节点下发资源请求,供目标P2SP节点获取并向P2P节点分享待访问资源即可。即,将现有由Tracker调度服务器提前向多个P2SP节点派发待访问资源改为仅由确定的目标P2SP节点获取待访问资源,从而减少了预测误差造成的资源浪费和内耗。
同时,在目标P2SP节点获取待访问资源的过程中,目标P2SP节点还向下发资源请求的P2P节点分享获取到的待访问资源,实现了待访问资源的边获取边分享,从而缩短了等待时长,即加快了资源可服务时长,有效提高了P2P分享率。
除此之外,P2P节点与接入P2P网络的P2SP节点预先建立P2P链接,从而使得本发明实施例提供的P2SP内容调度方案能够进一步提升资源可服务时长。
同时,通过将P2P节点与P2SP节点预先建立P2P链接,能够大大减少首包过程,使得本发明实施例提供的P2SP节点的调度方案能够更好地适用于极短视频场景中。
本发明的第二实施例涉及一种资源调度方法,应用于Tracker调度服务器。
需要说明的,所谓Tracker,是指运行于服务器上的一个程序,这个程序能够追踪到底有多少人同时在下载同一个资源。故而,Tracker调度服务器,即部署了Tracker程序的服务器。
下面对本实施例的资源调度方法的实现细节进行说明,以下内容仅为方便理解而提供的实现细节,并非实施本方案的必须。
本实施例的具体流程如图4所示,具体包括以下步骤:
步骤401,在接收P2P节点下发的哈希列表获取请求时,统计管理的哈希索引表中记录的哈希索引的索引个数。
通过第一实施例的描述可知,索引个数是与HASH BUCKET的大小相同的,即在本实施例中HASH BUCKET有多大,索引个数就为几个,比如HASH BUCKET为3,则统计出的索引个数也为3。
故而,在实际应用中,在接收到P2P节点下发的哈希列表获取请求时,可以直接获取当前配置的HASH BUCKET的大小,进而得到管理的哈希索引表中记录的哈希索引的索引个数。
步骤402,从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号。
为了更好地理解步骤402中所说的从每一哈希索引对应的节点序列号集中选取需要下发的节点序列号,本实施例给出一种具体的选取方式,具体如下:
首先,确定所述节点序列号集中每一节点序列号对应的所述P2SP节点支持链接的P2P节点的节点格式,以及预设选取指标对应的指标值。
具体的说,在实际应用中,所述预设选取指标包括,但不限于:当前带宽、一般下载中的成功率、完成率、完成不同大小资源的P2P分享率、下载速度等。
故而,确定的指标值,即为上述各种预设选取指标对应的实际参数信息。
然后,根据所述节点格式和所述指标值,确定所述节点序列号集中满足要求的所述P2SP节点。
具体的说,为了确保最终与P2P节点预建连的P2SP节点能够为P2P节点更好地提供资源分享服务,进而保证P2P分享率。在实际应用中,根据确定的格式和指标值,确定的节点序列号集中满足要求的P2SP节点,具体为负载最优的P2SP节点。
即,上述所说的满足要求,是满足负载最优。
最后,获取满足要求的所述P2SP节点对应的所述节点序列号,得到需要下发的所述节点序列号。
此外,可理解的,本实施例中所说的所述节点序列号具体是用于标识P2SP节点,在实际应用中,每一P2SP节点的节点序列号可以是基于其提供资源分享时,可以分析的待访问资源的URL确定的,即对于能够提供相同URL对应的待访问资源的P2SP节点,节点序列号可以是相同的。
此外,为了确保能够P2P节点能够根据索引个数和哈希序列号确定的目标哈希索引,快速定位目标P2SP节点所在的哈希索引,进而从中选取中与哈希序列号匹配的节点序列号对应的P2SP节点,每一所述哈希索引对应的节点序列号集中记录的节点序列号为互不相同的。
步骤403,根据所述索引个数、选取的所述节点序列号及所述节点序列号所属的所述哈希索引生成所述哈希列表,并将所述哈希列表下发给所述P2P节点。
由此可知,生成的哈希列表中记录了每一哈希索引对应的至少一个P2SP节点的节点序列号,从而使得P2P节点根据Tracker调度服务器下发的上述哈希列表与P2SP节点预建连后,能够保证每一个哈希索引都一直有对应的P2SP节点与P2P节点预建连。
此外,需要说明的是,关于Tracker调度服务器管理的所说哈希索引表,具体是通过与加入到P2P网络的P2SP节点的如下交互更新和维护的。
(1)接收加入到P2P网络中的所述P2SP节点的注册请求,从所述注册请求中提取携带的所述P2SP节点对应的历史节点序列号。
(2)统计每一所述哈希索引对应的节点序列号集中记录的所述节点序列号的序列号个数。
(3)根据所述历史节点序列号和所述序列号个数,为所述P2SP节点分配节点序列号,并添加到对应的所述哈希索引对应的所述节点序列号集中。
为了将新注册到Tracker调度服务器的P2SP节点分配到合适的哈希索引所对应的节点序列号集中进行管理,本实施例基于负载均衡的原则进行分配,即每一哈希索引对应的节点序列号集中管理的节点序列号的数量满足负载均衡。
基于这一原则,在根据所述历史节点序列号和所述序列号个数,为所述P2SP节点分配节点序列号时,具体为:
首先,计算每一所述哈希索引对应的所述序列号个数之间的差值百分比。
然后,将差值百分比与预设阈值进行比较,进而根据比较结果来为新注册的P2SP节点分配节点序列号。
具体的,若通过比较,确定所述差值百分比大于预设阈值,比如10%,则将所述序列号个数最少的所述哈希索引对应的所述节点序列号集中的所述节点序列号分配给所述P2SP节点。
仍以第一实施例中给出的表1为例,若L、M和N满足L<M<N,则在计算出的差值百分比大于10%时,会将Index1对应的节点序列号集中的节点序列号分配给新注册的P2SP节点。
否则,将所述历史节点序列号分配给所述P2SP节点,即复用已有的历史节点序列号,从而保证哈希索引表中管理的P2SP节点还是按照原来的节点序列号进行映射,从而保证缓存命中率。
此外,可理解的是,对哈希索引表的维护更新,是贯穿整个资源调度的,即Tracker调度服务器一旦启动,在工作状态下,只要接收到P2SP节点的注册请求,就会一直进行该操作。
应当理解的是,上述示例仅是为了更好地理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
由此,本实施例中提供的资源调度方法,Tracker调度服务器仅用于为接入P2P网络的P2SP节点分配节点序列号以及哈希索引,以及向P2P节点下发哈希列表,整个资源调度过程中,无需预估哪些P2SP节点将会成为目标P2SP节点,因此无需提前向多个P2SP节点派发待访问资源。通过这种将现有由Tracker调度服务器提前向多个P2SP节点派发待访问资源改为仅由确定的目标P2SP节点获取待访问资源,从而减少了预测误差造成的资源浪费和内耗。
除此之外,从每一哈希索引对应的节点序列号集中选取的节点序列号是满足负载均衡要求的,从而保证了最终与P2P节点预建连的P2SP节点能够更好地为P2P节点提供资源分享,进而提高P2P分享率。
本发明的第三实施例涉及一种资源调度方法,应用于P2SP节点。
下面对本实施例的资源调度方法的实现细节进行说明,以下内容仅为方便理解而提供的实现细节,并非实施本方案的必须。
本实施例的具体流程如图5所示,具体包括以下步骤:
步骤501,在接收到P2P节点下发的资源请求时,根据所述资源请求中携带的资源请求范围,确定当前需要访问的资源片段。
需要说明的是,在本实施例中P2P节点下发的资源请求具体包括是否可延迟标签、资源对应的完整URL、资源请求范围和请求失效时间。
为了便于理解,以下给出资源请求的部分伪代码:
其中,“URL”后根据的“http://test.example.com/1.mp4”即待访问资源的完整URL;“delay”即是否可延迟标签,如果在实际应用中,其后携带的具体信息为“true”,则表示允许存在延迟,若携带的具体信息为“false”,则表示不允许延迟;“range”即资源请求范围,即用户想要获取的待访问资源的具体部分,如上所示的“0-100”表示从起始点0开始获取待访问资源至100的位置;“timeout”即请求失效时间,如上所示的“100”表示当前资源请求的请求失效时间为100ms。
可理解的,在资源调度的过程中,为了尽可能缩短用户等待时间,通常设置的请求失效时间时以毫秒(ms)为单位的,故而上述所示的“100”,在本实施例中是指100ms。
此外,本实施例中所说的资源请求范围的单位,类似于普通的超文本传输协议(Hypertext Transfer Protocol,http)range请求的格式,比如在待访问资源的大小为1024Byte时,上述所说的“0-100”具体是指待访问资源从0Byte开始到100Byte之间的内容。
此外,可理解的是,关于“delay”后跟的标识,在实际应用中,除了可以采用“true”或“false”标识,还可以用“0”或“1”标识,即只要预先约定好即可。
基于上述格式的资源请求,本实施例规定,在请求的待访问资源为视频资源的首包数据时,所述是否可延迟标签delay对应的标志信息为预设的不可延迟标识符,即上述所说的“false”或“1”。
步骤502,查找本地缓存中是否存在所述资源片段。
具体的说,若在本地缓存中查找到资源片段,则执行步骤503;否则,执行步骤504。
步骤503,从所述本地缓存读取所述资源片段,并向所述P2P节点分享所述资源片段。
此外,值得一提的是,在实际应用中可能存在本地缓存中存在部分资源片段的情况,即本地缓存中存在资源片段,但是缓存的资源片段并不完整,比如需要请求的资源片段为“400-600”,而当前时刻本地缓存只存储了0-500的资源片段,故而为了能够根据用户需求进行合理的资源调度,在实际应用中,在从CDN请求完整的待访问资源之前,可以先判断所述本地缓存中是否存在完整的所述资源片段,如上述资源请求范围“400-600”对应的资源片段。
相应地,若存在,则直接执行步骤503的操作;否则,执行以下操作:
首先,获取所述资源请求中是否可延迟标签对应的标志信息。
然后,判断获取的标志信息是预设的不可延迟标志符,如“false”,还是预设的可延迟标志符,如“true”。
相应地,在所述标志信息为预设的不可延迟标志符时,从所述CDN请求所述资源片段,并在从所述CDN下载所述资源片段的过程中,将获取到的所述资源片段分享至所述P2P节点;在所述标志信息为预设的可延迟标志符时,将所述资源请求添加到预先构建的等待队列,等待从CDN获取到所述资源片段时,执行所述将获取到的所述资源片段分享至所述P2P节点的操作即可。
由此,使得P2SP节点能够针对P2P节点需要优先获取的数据,比如影响视频内容播放的首屏数据,能够在本地缓存没有完整的首屏数据时,及时进行CDN回源,进而快速将首屏数据分享给P2P节点,避免长时间等待,而对于优先级相对低的数据,通过将资源请求挂到等待队列,在数据到达后才进行分享,从而尽可能降低了同一时刻对资源的占用。
步骤504,根据所述资源请求中携带的URL确定所述资源片段所属的待访问资源,从内容分发网络CDN请求所述待访问资源,并在从所述CDN下载所述待访问资源的过程中,将获取到的所述资源片段分享至所述P2P节点。
具体的,所述从内容分发网络CDN请求完整的所述待访问资源,具体为:
(1)从所述资源请求中获取所述资源请求范围的起始点。
(2)判断所述起始点是否为0。
相应地,若是,则从所述CDN请求完整的所述待访问资源;否则,分别从所述CDN请求从0开始到所述起始点对应的所述待访问资源的片段,以及从所述起始点开始到所述待访问资源的终止点对应的所述待访问资源的资源片段。
即,假如资源请求中“range”后跟的资源请求范围是“0-100”,而完整的待请求资源的大小为1024Byte,则P2SP节点从CDN请求的是从0Byte开始到1024Byte的所有内容,即完整的待访问资源。
假如资源请求中“range”后跟的资源请求范围是“200-300”,而完整的待请求资源的大小为1024Byte,则P2SP节点会向CDN发起两个资源请求,一个为从0Byte开始到200Byte之间的片段请求,一个是从200Byte开销到1024Byte为止的片段请求。
此外,关于步骤504中所说的在从所述CDN下载所述待访问资源的过程中,将获取到的所述资源片段分享至所述P2P节点,具体是指当对应请求返回的数据到达P2SP节点时,P2SP节点在将返回的数据写入本地缓存或磁盘的同时,可以将请求的所述资源片段分享至所述P2P节点,从而实现资源片段的边获取边分享,进而有效缩短用户等待时间,提升P2P分享率。
比如说,如果当前下载到100Byte,用户请求的为待访问资源50Byte-200Byte之间的部分,则从本地缓存或磁盘读取50Byte-100Byte的数据发送给P2P节点,并把请求挂载到相应等待队列,等待新数据到达以后发送给P2P节点。
应当理解的是,上述示例仅是为了更好地理解本实施例的技术方案而列举的示例,不作为对本实施例的唯一限制。
此外,值得一提的是,在实际应用中,
如果资源请求的“range”的起始点已经超过了本地缓存,比如本地缓存为1024Byte,而资源请求的“range”的起始点为1100Byte,则判断“delay”后跟的内容是否为“false”,即不允许延迟,如果是,则确定当前资源请求为首屏请求,则P2SP节点直接以当前资源请求的“range”发起一个新的HTTP的资源请求,并转发给P2P节点,从而保证P2P节点视频的首屏时间。
此外,值得一提的是,为了避免P2P节点长时间等待能够提供资源分享的P2SP节点,进而影响用户体验,资源请求中通常会设置一个合理的请求失效时间,即当等待时间大于设置的请求失效时间时,P2SP节点便会通知P2P节点待访问资源还未准备好,以使P2P节点选择直接从CDN获取待访问资源,从而保证P2P节点能够尽快为用户提供需要访问的待访问资源。
关于这一操作,可以是基于从CDN中获取到的待访问资源的头部信息预估出的超时时间触发的。
即,在实际应用中,当从所述CDN中获取到所述待访问资源的头部信息后,先根据预设的公式(1)根据所述头部信息预估获取所述资源请求范围对应的所述待访问资源的超时时间,即公式(1)中的T预估时间;然后,判断所述超时时间是否大于资源请求中携带的所述请求失效时间,即“timeout”后携带的数据。
相应地,若大于,则通知所述P2P节点所述待访问资源还未准备好,以使所述P2P节点直接从所述CDN获取所述待访问资源;否则,将所述资源请求添加到预先构建的等待队列,等待所述待访问资源从所述CDN落盘或写入所述本地缓存时,执行所述将已经落盘或写入所述本地缓存的所述待访问资源的内容分享至所述P2P节点的操作。
关于上述所说的公式(1),具体如下:
其中,T预估时间为预估出的获取所述资源请求范围对应的所述待访问资源的超时时间;Sbuf为当前已经从CDN下载到本次缓存或磁盘的数据;Tnow为当前时刻;Tbegin为开始下载时刻;Rend为资源请求中“range”中的结束位置;Rtt为P2SP节点和对应的P2P节点之间的往返时延(Round-Trip Time,RTT)。
由此,本实施例中提供的资源调度方法,通过设置P2SP节点获取待访问资源的过程中,向下发资源请求的P2P节点分享获取到的待访问资源,实现了待访问资源的边获取边分享,从而缩短了等待时长,即加快了资源可服务时长,有效提高了P2P分享率。
此外,通过根据待访问资源的头部信息预估获取所述资源请求范围对应的所述待访问资源的超时时间,进而根据预估的超时时间与资源请求中携带的请求失效时间确定P2P节点究竟是等待P2SP节点下发待访问资源,还是直接从CDN获取待访问资源,使得用户能够实时获知当前进度,避免长时间的等待,从而更好地提升了用户体验。
应当理解的是,上面各种方法的步骤划分,只是为了描述清楚,实现时可以合并为一个步骤或者对某些步骤进行拆分,分解为多个步骤,只要包括相同的逻辑关系,都在本专利的保护范围内;对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计,但不改变其算法和流程的核心设计都在该专利的保护范围内。
本发明的第四实施例涉及一种资源调度装置,应用于P2P节点,如图6所示,包括:URL确定模块601、哈希处理模块602、P2SP节点匹配模块603和资源请求发送模块604。
其中,URL确定模块601,用于在接收到用户对待访问资源的访问请求时,确定所述待访问资源的统一资源定位符URL;哈希处理模块602,用于对所述URL进行哈希处理,得到所述URL对应的哈希序列号;P2SP节点匹配模块603,用于从预先建连的P2SP节点中选取与所述哈希序列号匹配的目标P2SP节点;资源请求发送模块604,用于向所述目标P2SP节点下发资源请求,供所述目标P2SP节点获取并向所述P2P节点分享所述资源片段。
此外,在另一个例子中,资源调度装置还包括预建连模块。
具体的,预建连模块,用于在接收到用户对待访问资源的访问请求之前,向Tracker调度服务器下发哈希列表获取请求;接收所述Tracker调度服务器下发的所述哈希列表,并根据所述哈希列表中记录的所述节点序列号定位需要建连的所述P2SP节点;基于预设的建连方式,与定位的所述P2SP节点建连。
此外,值得一提的是,所述哈希列表,具体是由所述Tracker调度服务器确定管理的哈希索引表中记录的哈希索引的索引个数,并从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号,并根据所述索引个数、选取的所述节点序列号及所述节点序列号所属的所述哈希索引生成所述哈希列表。
其中,所述节点序列号用于标识所述P2SP节点,每一所述哈希索引对应的节点序列号集中记录的节点序列号互不相同。
此外,在另一个例子中,P2SP节点匹配模块603从预先建连的P2SP节点中选取与所述哈希序列号匹配的目标P2SP节点,具体为:
根据所述哈希列表中记录的所述索引个数和所述哈希序列号,确定目标哈希索引;
根据所述目标哈希索引,从预先建连的P2SP节点中定位与所述目标哈希索引匹配的所述哈希索引,并从定位的所述哈希索引对应所述节点序列号中,选取与所述哈希序列号匹配的所述节点序列号对应的所述P2SP节点,得到所述目标P2SP节点。
此外,在另一例子中,资源调度装置还包括链接监测模块。
具体的,链接监测模块,用于在所述基于预设的建连方式,与定位的所述P2SP节点建连之后,监测与定位的所述P2SP节点之间的建连是否断开。
相应地,若断开,则通知预建连模块获取定位的所述P2SP节点对应的所述节点序列号所属的所述哈希索引,并从所述Tracker调度服务器获取所述哈希索引对应的节点序列号集中重新选取需要下发的节点序列号;基于预设的所述建连方式,与重新获取的所述节点序列号对应的P2SP节点建连。
此外,在另一个例子中,预建连模块,还用于执行以下操作:
接收所述Tracker调度服务器下发的所述哈希列表;
将当前时刻接收到的所述哈希列表与所述当前时刻之前接收到的所述哈希列表进行匹配;
若不匹配,则根据所述当前时刻接收的所述哈希列表中记录的所述节点序列号重新定位需要建连的所述P2SP节点;
基于预设的所述建连方式,与重新定位的所述P2SP节点建连。
此外,在另一个例子中,所述资源请求包括是否可延迟标签、资源对应的完整URL、资源请求范围和请求失效时间。
相应地,在请求的所述待访问资源为视频资源的首包数据时,所述是否可延迟标签对应的标志信息为预设的不可延迟标志符。
此外,关于所述是否可延迟标签对应的标志信息,在实际应用中的用途具体为:
在所述标志信息为预设的不可延迟标志符,且所述目标P2SP节点的本地缓存中不存在所述资源请求范围对应的所述首包数据时,供所述目标P2SP节点从内容分发网络CDN请求所述首包数据,并在从所述CDN下载所述首包数据的过程中,将获取到的所述首包数据分享至所述P2P节点;在所述标志信息为预设的可延迟标志符,且所述目标P2SP节点的本地缓存中不存在所述资源请求范围对应的所述首包数据时,供所述目标P2SP节点将所述资源请求添加到预先构建的等待队列,等待从CDN获取到所述资源片段时,并将获取到的所述首包数据分享至所述P2P节点。
不难发现,本实施例为与第一实施例相对应的装置实施例,本实施例可与第一实施例互相配合实施。第一实施例中提到的相关技术细节在本实施例中依然有效,为了减少重复,这里不再赘述。相应地,本实施例中提到的相关技术细节也可应用在第一实施例中。
本发明的第五实施例涉及一种资源调度装置,应用于Tracker调度服务器,如图7所示,包括:索引个数统计模块701、节点序列号选取模块702、哈希列表生成模块703和哈希列表发送模块704。
其中,索引个数统计模块701,用于在接收P2P节点下发的哈希列表获取请求时,统计管理的哈希索引表中记录的哈希索引的索引个数;节点序列号选取模块702,用于从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号,所述节点序列号用于标识P2SP节点,每一所述哈希索引对应的节点序列号集中记录的节点序列号互不相同;哈希列表生成模块703,用于根据所述索引个数、选取的所述节点序列号及所述节点序列号所属的所述哈希索引生成所述哈希列表;哈希列表发送模块704,用于将所述哈希列表下发给所述P2P节点。
此外,在另一个例子中,节点序列号选取模块702,具体用于确定所述节点序列号集中每一节点序列号对应的所述P2SP节点支持链接的P2P节点的节点格式,以及预设选取指标对应的指标值;根据所述节点格式和所述指标值,确定所述节点序列号集中满足要求的所述P2SP节点;获取满足要求的所述P2SP节点对应的所述节点序列号,得到需要下发的所述节点序列号。
此外,在另一个例子中,资源调度装置还包括注册模块。
具体的,注册模块,用于接收加入到P2P网络中的所述P2SP节点的注册请求,从所述注册请求中提取携带的所述P2SP节点对应的历史节点序列号;统计每一所述哈希索引对应的节点序列号集中记录的所述节点序列号的序列号个数;根据所述历史节点序列号和所述序列号个数,为所述P2SP节点分配节点序列号,并添加到对应的所述哈希索引对应的所述节点序列号集中。
此外,在另一个例子中,注册模块,具体用于计算每一所述哈希索引对应的所述序列号个数之间的差值百分比;若所述差值百分比大于预设阈值,则将所述序列号个数最少的所述哈希索引对应的所述节点序列号集中的所述节点序列号分配给所述P2SP节点;否则,将所述历史节点序列号分配给所述P2SP节点。
不难发现,本实施例为与第二实施例相对应的装置实施例,本实施例可与第二实施例互相配合实施。第二实施例中提到的相关技术细节在本实施例中依然有效,为了减少重复,这里不再赘述。相应地,本实施例中提到的相关技术细节也可应用在第二实施例中。
本发明的第六实施例涉及一种资源调度装置,应用于P2SP节点,如图8所示,包括:资源片段确定模块801、资源片段查找模块802、资源片段分享模块803和CDN回源模块。
其中,资源片段确定模块801,用于在接收到P2P节点下发的资源请求时,根据所述资源请求中携带的资源请求范围,确定当前需要访问的资源片段;资源片段查找模块802,用于查找本地缓存中是否存在所述资源片段;若存在,则由资源片段分享模块803从所述本地缓存读取所述资源片段,并向所述P2P节点分享所述资源片段;否则,由CDN回源模块804根据所述资源请求中携带的URL确定所述资源片段所属的待访问资源,从内容分发网络CDN请求所述待访问资源,并在从所述CDN下载所述待访问资源的过程中,将获取到的所述资源片段分享至所述P2P节点。
此外,在另一个例子中,资源调度装置还包括资源片段完整性判断模块。
具体的,资源片段完整性判断模块,用于判断所述本地缓存中是否存在完整的所述资源片段。
相应地,若存在,则通知资源片段分享模块803执行所述从本地缓存读取所述待访问资源的操作;否则,获取所述资源请求中是否可延迟标签对应的标志信息,并在所述标志信息为预设的不可延迟标志符时,通知CDN回源模块804从所述CDN请求所述资源片段,并在从所述CDN下载所述资源片段的过程中,通知资源片段分享模块803将获取到的所述资源片段分享至所述P2P节点;在所述标志信息为预设的可延迟标志符时,将所述资源请求添加到预先构建的等待队列,等待从CDN获取到所述资源片段时,通知资源片段分享模块803执行所述将获取到的所述资源片段分享至所述P2P节点的操作。
此外,在另一个例子中,CDN回源模块从内容分发网络CDN请求完整的所述待访问资源,具体为:
从所述资源请求中获取所述资源请求范围的起始点;
判断所述起始点是否为0;
若是,则从所述CDN请求完整的所述待访问资源;
否则,分别从所述CDN请求从0开始到所述起始点对应的所述待访问资源的片段,以及从所述起始点开始到所述待访问资源的终止点对应的所述待访问资源的资源片段。
此外,在另一个例子中,CDN回源模块从内容分发网络CDN请求完整的所述待访问资源,具体为:
在从所述CDN中获取到所述待访问资源的头部信息后,根据所述头部信息预估获取所述资源请求范围对应的所述待访问资源的超时时间;
判断所述超时时间是否大于所述资源访问请求中携带的请求失效时间;
若大于,则通知所述P2P节点所述待访问资源还未准备好,以使所述P2P节点直接从所述CDN获取所述待访问资源;
否则,将所述资源请求添加到预先构建的等待队列,等待从CDN获取到所述资源片段时,执行所述将获取到的所述资源片段分享至所述P2P节点的操作。
不难发现,本实施例为与第三实施例相对应的装置实施例,本实施例可与第三实施例互相配合实施。第三实施例中提到的相关技术细节在本实施例中依然有效,为了减少重复,这里不再赘述。相应地,本实施例中提到的相关技术细节也可应用在第三实施例中。
值得一提的是,本实施例中所涉及到的各模块均为逻辑模块,在实际应用中,一个逻辑单元可以是一个物理单元,也可以是一个物理单元的一部分,还可以以多个物理单元的组合实现。此外,为了突出本发明的创新部分,本实施例中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入,但这并不表明本实施例中不存在其它的单元。
本发明的第七实施例涉及一种资源调度设备,如图9所示,包括至少一个处理器901;以及,与所述至少一个处理器901通信连接的存储器902;其中,所述存储器902存储有可被所述至少一个处理器901执行的指令,所述指令被所述至少一个处理器901执行,以使所述至少一个处理器901能够执行上述方法实施例所描述的资源调度方法。
需要说明的是,在实际应用中,本实施例中所说的资源调度设备,可能是P2P节点、Tracker调度服务器和P2SP节点中的任意一种。
故而,上述所说的资源调度设备中的处理器901能够执行上述方法实施例所描述的资源调度方法,具体为:
在所述资源调度设备为P2P节点时,内部的处理器901执行的为应用于P2P节点的资源调度方法,即上述第一实施例所描述的资源调度方法。
相应地,在所述资源调度设备为Tracker调度服务器时,内部的处理器901执行的为应用于Tracker调度服务器的资源调度方法,即上述第二实施例所描述的资源调度方法。
相应地,在所述资源调度设备为P2SP节点时,内部的处理器901执行的为应用于P2SP节点的资源调度方法,即上述第三实施例所描述的资源调度方法。
此外,可理解的,在实际应用中存储器902和处理器901采用总线方式连接,总线可以包括任意数量的互联的总线和桥,总线将一个或多个处理器901和存储器902的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件,也可以是多个元件,比如多个接收器和发送器,提供用于在传输介质上与各种其他装置通信的单元。经处理器901处理的数据通过天线在无线介质上进行传输,进一步,天线还接收数据并将数据传输给处理器901。
处理器901负责管理总线和通常的处理,还可以提供各种功能,包括定时,外围接口,电压调节、电源管理以及其他控制功能。而存储器902可以被用于存储处理器901在执行操作时所使用的数据。
本发明的第八实施例涉及一种计算机可读存储介质,存储有计算机程序。计算机程序被处理器执行时实现上述资源调度方法实施例。
同理,由于在实际应用中,本实施例中所说的资源调度设备,可能是P2P节点、Tracker调度服务器和P2SP节点中的任意一种。
故而,在实际应用中,本实施例中所说的计算机存储介质涉及适应于上述三种资源调度设备的计算机可读存储介质。
相应地,上述所说的计算机程序被处理器执行时实现上述方法实施例所描述的资源调度方法,具体为:
在所述资源调度设备为P2P节点时,部署于P2P节点内的计算机程序被内部的处理器执行时,具体实现的是应用于P2P节点的资源调度方法,即上述第一实施例所描述的资源调度方法。
相应地,在所述资源调度设备为Tracker调度服务器时,部署于Tracker调度服务器内的计算机程序被内部的处理器执行时,具体实现的是应用于Tracker调度服务器的资源调度方法,即上述第二实施例所描述的资源调度方法。
相应地,在所述资源调度设备为P2SP节点时,部署于P2SP节点内的计算机程序被内部的处理器执行时,具体实现的是应用于P2SP节点的资源调度方法,即上述第三实施例所描述的资源调度方法。
即,本领域技术人员可以理解,实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序存储在一个存储介质中,包括若干指令用以使得一个设备(可以是单片机,芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-OnlyMemory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域的普通技术人员可以理解,上述各实施例是实现本发明的具体实施例,而在实际应用中,可以在形式上和细节上对其作各种改变,而不偏离本发明的精神和范围。
Claims (15)
1.一种资源调度方法,其特征在于,应用于P2P节点,所述资源调度方法包括:
在接收到用户对待访问资源的访问请求时,确定所述待访问资源的统一资源定位符URL;
对所述URL进行哈希处理,得到所述URL对应的哈希序列号;
从预先建连的P2SP节点中选取与所述哈希序列号匹配的目标P2SP节点,并向所述目标P2SP节点下发资源请求,供所述目标P2SP节点获取并向所述P2P节点分享所述资源请求所请求的当前需要访问的资源片段;
其中,在所述接收到用户对待访问资源的访问请求之前,所述方法还包括:
向Tracker调度服务器下发哈希列表获取请求,供所述Tracker调度服务器确定管理的哈希索引表中记录的哈希索引的索引个数,并从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号,并根据所述索引个数、选取的所述节点序列号及所述节点序列号所属的所述哈希索引生成所述哈希列表,所述节点序列号用于标识所述P2SP节点,每一所述哈希索引对应的节点序列号集中记录的节点序列号互不相同;
接收所述Tracker调度服务器下发的所述哈希列表,并根据所述哈希列表中记录的所述节点序列号定位需要建连的所述P2SP节点;
基于预设的建连方式,与定位的所述P2SP节点建连。
2.根据权利要求1所述的资源调度方法,其特征在于,所述从预先建连的P2SP节点中选取与所述哈希序列号匹配的目标P2SP节点,包括:
根据所述哈希列表中记录的所述索引个数和所述哈希序列号,确定目标哈希索引;
根据所述目标哈希索引,从预先建连的P2SP节点中定位与所述目标哈希索引匹配的所述哈希索引,并从定位的所述哈希索引对应所述节点序列号中,选取与所述哈希序列号匹配的所述节点序列号对应的所述P2SP节点,得到所述目标P2SP节点。
3.根据权利要求1所述的资源调度方法,其特征在于,在所述基于预设的建连方式,与定位的所述P2SP节点建连之后,所述方法还包括:
监测与定位的所述P2SP节点之间的建连是否断开;
若断开,则获取定位的所述P2SP节点对应的所述节点序列号所属的所述哈希索引,并从所述Tracker调度服务器获取所述哈希索引对应的节点序列号集中重新选取需要下发的节点序列号;
基于预设的所述建连方式,与重新获取的所述节点序列号对应的P2SP节点建连。
4.根据权利要求1所述的资源调度方法,其特征在于,在所述基于预设的建连方式,与定位的所述P2SP节点建连之后,所述方法还包括:
接收所述Tracker调度服务器下发的所述哈希列表;
将当前时刻接收到的所述哈希列表与所述当前时刻之前接收到的所述哈希列表进行匹配;
若不匹配,则根据所述当前时刻接收的所述哈希列表中记录的所述节点序列号重新定位需要建连的所述P2SP节点;
基于预设的所述建连方式,与重新定位的所述P2SP节点建连。
5.根据权利要求1所述的资源调度方法,其特征在于,所述资源请求包括是否可延迟标签、资源对应的完整URL、资源请求范围和请求失效时间;
在请求的所述待访问资源为视频资源的首包数据时,所述是否可延迟标签对应的标志信息为预设的不可延迟标志符;
其中,在所述标志信息为预设的不可延迟标志符,且所述目标P2SP节点的本地缓存中不存在所述资源请求范围对应的所述首包数据时,供所述目标P2SP节点从内容分发网络CDN请求所述首包数据,并在从所述CDN下载所述首包数据的过程中,将获取到的所述首包数据分享至所述P2P节点;
在所述标志信息为预设的可延迟标志符,且所述目标P2SP节点的本地缓存中不存在所述资源请求范围对应的所述首包数据时,供所述目标P2SP节点将所述资源请求添加到预先构建的等待队列,等待从CDN获取到所述资源片段时,并将获取到的所述首包数据分享至所述P2P节点。
6.一种资源调度方法,其特征在于,应用于Tracker调度服务器,所述资源调度方法包括:
在接收P2P节点下发的哈希列表获取请求时,统计管理的哈希索引表中记录的哈希索引的索引个数;
从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号,所述节点序列号用于标识P2SP节点,每一所述哈希索引对应的节点序列号集中记录的节点序列号互不相同;
根据所述索引个数、选取的所述节点序列号及所述节点序列号所属的所述哈希索引生成所述哈希列表,并将所述哈希列表下发给所述P2P节点,以供所述P2P节点根据所述哈希列表与需要建连的P2SP节点建连,并在接收到用户对待访问资源的访问请求时,确定所述待访问资源的统一资源定位符URL,对所述URL进行哈希处理,得到所述URL对应的哈希序列号,并从所述建连的P2SP节点中选取与所述哈希序列号匹配的目标P2SP节点,向所述目标P2SP节点下发资源请求;其中,所述资源请求用于供所述目标P2SP节点获取并向所述P2P节点分享所述资源片段。
7.根据权利要求6所述的资源调度方法,其特征在于,所述从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号,包括:
确定所述节点序列号集中每一节点序列号对应的所述P2SP节点支持链接的P2P节点的节点格式,以及预设选取指标对应的指标值;
根据所述节点格式和所述指标值,确定所述节点序列号集中满足要求的所述P2SP节点;
获取满足要求的所述P2SP节点对应的所述节点序列号,得到需要下发的所述节点序列号。
8.根据权利要求7所述的资源调度方法,其特征在于,所述方法还包括:
接收加入到P2P网络中的所述P2SP节点的注册请求,从所述注册请求中提取携带的所述P2SP节点对应的历史节点序列号;
统计每一所述哈希索引对应的节点序列号集中记录的所述节点序列号的序列号个数;
根据所述历史节点序列号和所述序列号个数,为所述P2SP节点分配节点序列号,并添加到对应的所述哈希索引对应的所述节点序列号集中。
9.根据权利要求8所述的资源调度方法,其特征在于,所述根据所述历史节点序列号和所述序列号个数,为所述P2SP节点分配节点序列号,包括:
计算每一所述哈希索引对应的所述序列号个数之间的差值百分比;
若所述差值百分比大于预设阈值,则将所述序列号个数最少的所述哈希索引对应的所述节点序列号集中的所述节点序列号分配给所述P2SP节点;
否则,将所述历史节点序列号分配给所述P2SP节点。
10.一种资源调度方法,其特征在于,应用于P2SP节点,所述资源调度方法包括:
在接收到P2P节点下发的资源请求时,根据所述资源请求中携带的资源请求范围,确定当前需要访问的资源片段;
查找本地缓存中是否存在所述资源片段;
若存在,则从所述本地缓存读取所述资源片段,并向所述P2P节点分享所述资源片段;
否则,根据所述资源请求中携带的URL确定所述资源片段所属的待访问资源,从内容分发网络CDN请求所述待访问资源,并在从所述CDN下载所述待访问资源的过程中,将获取到的所述资源片段分享至所述P2P节点;其中,所述P2SP节点为所述P2P节点从预先建连的P2SP节点中选取的与所述URL的哈希序列号匹配的目标P2SP节点,所述哈希序列号通过对所述URL进行哈希处理得到;
其中,所述P2SP节点与所述P2P节点预先建连是由所述P2P节点在所述接收到用户对待访问资源的访问请求之前,向Tracker调度服务器下发哈希列表获取请求,供所述Tracker调度服务器确定管理的哈希索引表中记录的哈希索引的索引个数,并从每一所述哈希索引对应的节点序列号集中选取需要下发的节点序列号,并根据所述索引个数、选取的所述节点序列号及所述节点序列号所属的所述哈希索引生成所述哈希列表,所述节点序列号用于标识所述P2SP节点,每一所述哈希索引对应的节点序列号集中记录的节点序列号互不相同;接收所述Tracker调度服务器下发的所述哈希列表,并根据所述哈希列表中记录的所述节点序列号定位需要建连的所述P2SP节点;基于预设的建连方式,与定位的所述P2SP节点建连实现。
11.根据权利要求10所述的资源调度方法,其特征在于,在所述从所述本地缓存读取所述资源片段之前,所述方法还包括:
判断所述本地缓存中是否存在完整的所述资源片段;
若存在,则执行所述从本地缓存读取所述待访问资源的步骤;
否则,获取所述资源请求中是否可延迟标签对应的标志信息,并在所述标志信息为预设的不可延迟标志符时,从所述CDN请求所述资源片段,并在从所述CDN下载所述资源片段的过程中,将获取到的所述资源片段分享至所述P2P节点;在所述标志信息为预设的可延迟标志符时,将所述资源请求添加到预先构建的等待队列,等待从CDN获取到所述资源片段时,执行所述将获取到的所述资源片段分享至所述P2P节点的步骤。
12.根据权利要求10所述的资源调度方法,其特征在于,所述从内容分发网络CDN请求完整的所述待访问资源,包括:
从所述资源请求中获取所述资源请求范围的起始点;
判断所述起始点是否为0;
若是,则从所述CDN请求完整的所述待访问资源;
否则,分别从所述CDN请求从0开始到所述起始点对应的所述待访问资源的片段,以及从所述起始点开始到所述待访问资源的终止点对应的所述待访问资源的资源片段。
13.根据权利要求12所述的资源调度方法,其特征在于,所述从内容分发网络CDN请求完整的所述待访问资源,包括:
在从所述CDN中获取到所述待访问资源的头部信息后,根据所述头部信息预估获取所述资源请求范围对应的所述待访问资源的超时时间;
判断所述超时时间是否大于所述资源请求中携带的请求失效时间;
若大于,则通知所述P2P节点所述待访问资源还未准备好,以使所述P2P节点直接从所述CDN获取所述待访问资源;
否则,将所述资源请求添加到预先构建的等待队列,等待从CDN获取到所述资源片段时,执行所述将获取到的所述资源片段分享至所述P2P节点的步骤。
14.一种资源调度设备,其特征在于,包括:
至少一个处理器;以及,
与所述至少一个处理器通信连接的存储器;其中,
所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行如权利要求1至5中任一项所述的资源调度方法,或者执行如权利要求6至9中任一项所述的资源调度方法,或者执行如权利要求10至13中任一项所述的资源调度方法。
15.一种计算机可读存储介质,存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至5中任一项所述的资源调度方法,或者执行如权利要求6至9中任一项所述的资源调度方法,或者执行如权利要求10至13中任一项所述的资源调度方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110008115.5A CN112788135B (zh) | 2021-01-05 | 2021-01-05 | 资源调度方法、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110008115.5A CN112788135B (zh) | 2021-01-05 | 2021-01-05 | 资源调度方法、设备及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112788135A CN112788135A (zh) | 2021-05-11 |
CN112788135B true CN112788135B (zh) | 2023-08-08 |
Family
ID=75755401
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110008115.5A Active CN112788135B (zh) | 2021-01-05 | 2021-01-05 | 资源调度方法、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112788135B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114422511A (zh) * | 2021-12-23 | 2022-04-29 | 北京八分量信息科技有限公司 | 异构网络中数据节点的管理方法、装置及相关产品 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102833293A (zh) * | 2011-06-17 | 2012-12-19 | 腾讯科技(深圳)有限公司 | P2sp网络中资源下载的方法及客户端 |
WO2013143363A1 (en) * | 2012-03-29 | 2013-10-03 | Tencent Technology (Shenzhen) Company Limited | A method and apparatus for data storage and downloading |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101729273A (zh) * | 2008-10-27 | 2010-06-09 | 中国移动通信集团公司 | 一种流媒体分发系统、方法及装置 |
CN102685160B (zh) * | 2011-03-11 | 2016-04-13 | 腾讯科技(深圳)有限公司 | P2sp中资源下载方法、服务器、感知服务器、客户端及系统 |
CN103078881B (zh) * | 2011-10-26 | 2016-05-11 | 腾讯科技(深圳)有限公司 | 网络资源下载信息的分享控制系统和方法 |
CN102624884B (zh) * | 2012-02-29 | 2016-02-17 | 上海聚力传媒技术有限公司 | 一种用于接收p2p资源的方法、装置和设备 |
CN103023928A (zh) * | 2013-01-11 | 2013-04-03 | 乐视网信息技术(北京)股份有限公司 | 一种p2p节点匹配系统及方法 |
CN103095727B (zh) * | 2013-02-07 | 2015-10-21 | 北京邮电大学 | P2p资源定位方法 |
CN111212114B (zh) * | 2019-12-19 | 2021-08-27 | 网宿科技股份有限公司 | 一种下载资源文件的方法和装置 |
-
2021
- 2021-01-05 CN CN202110008115.5A patent/CN112788135B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102833293A (zh) * | 2011-06-17 | 2012-12-19 | 腾讯科技(深圳)有限公司 | P2sp网络中资源下载的方法及客户端 |
WO2013143363A1 (en) * | 2012-03-29 | 2013-10-03 | Tencent Technology (Shenzhen) Company Limited | A method and apparatus for data storage and downloading |
Also Published As
Publication number | Publication date |
---|---|
CN112788135A (zh) | 2021-05-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3595268B1 (en) | Streaming media resource distribution method, system, edge node and central dispatching system | |
US9621620B2 (en) | Apparatus and method for providing content with a distributed architecture, and system for providing content with the said apparatus | |
US10708350B2 (en) | Method and system for content delivery of mobile terminal applications | |
CN101141459B (zh) | 使用http与p2p相结合实现数据传输或流媒体传输的方法 | |
KR101595527B1 (ko) | 넷스토어 기반의 서비스 네트워크 동적 구성 시스템 및 서비스 네트워크 동적 구성 방법 | |
CN106941507B (zh) | 请求消息的调度方法及装置 | |
KR20130088774A (ko) | 분할 콘텐트 전달 시스템 및 방법 | |
CN101540775A (zh) | 内容分发方法、装置与内容分发网络系统 | |
CN114760482B (zh) | 直播回源方法及装置 | |
US8812718B2 (en) | System and method of streaming data over a distributed infrastructure | |
WO2012075970A1 (zh) | 一种获取媒体内容的方法、设备及系统 | |
JP2015528666A (ja) | ヘテロジーニアスネットワークにおけるサービスコンテンツ配布方法、およびサービス管理プラットフォーム | |
CN115208955B (zh) | 一种资源请求处理的方法、装置、计算机设备及介质 | |
CN115002497B (zh) | 直播回源的调度方法及系统、回源服务器 | |
CN110445723A (zh) | 一种网络数据调度方法及边缘节点 | |
KR20150021437A (ko) | 무선 네트워크를 위한 콘텐츠 캐싱 관리 방법 | |
CN104320347B (zh) | 一种主动更新lldp的方法及设备 | |
CN101854287B (zh) | 一种p2p流量优化方法及装置 | |
CN110856007A (zh) | 内容分发网络及其存储优化方法、电子设备及存储介质 | |
CN112788135B (zh) | 资源调度方法、设备及存储介质 | |
CN107959704B (zh) | 一种数据处理方法及家庭网关 | |
KR20140024553A (ko) | 라이브 스트리밍 컨텐츠를 위한 컨텐츠 전송 서비스 방법, 및 이를 위한 장치 | |
CN112491951A (zh) | 对等网络中的请求处理方法、服务器及存储介质 | |
WO2018090315A1 (zh) | 数据请求的处理方法及缓存系统 | |
CN105100147A (zh) | 一种基于内容提供商与服务提供商分离的控制方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |