CN108881051A - P2p流媒体点播系统中基于请求队列的节点负载均衡方法 - Google Patents

Abstract

本发明公开了P2P流媒体点播系统中基于请求队列的节点负载均衡方法，该方法实现了P2P流媒体系统中各节点间高效的负载均衡。首先，通过请求的紧迫性、稀缺性以及平滑播放阈值，综合定义了请求的优先级，按照优先级由高到低排序，把不能及时处理的请求转移到其他的节点。最后，综合邻居节点的上行带宽，以及计算得到的稳定性和负载度，设计了节点利用函数，对转移的请求选择合适的目标节点进行处理，提出了基于请求队列的节点负载均衡策略。实施结果表明，本发明所设计的方法可以有效地解决P2P流媒体点播系统中的节点负载不均衡的问题，优化了P2P网络中的资源配置，有利于提升用户对于流媒体点播的体验。

Description

P2P流媒体点播系统中基于请求队列的节点负载均衡方法

技术领域

本发明涉及一种P2P流媒体点播系统中基于请求队列的节点负载均衡方法，属于多媒体通信技术领域。

背景技术

随着宽带带宽的升级和互联网的飞速发展、软硬件的不断升级、流媒体的技术快速发展，流媒体服务凭借其良好的娱乐性和社交性受到越来越多的网民欢迎。流媒体技术的进步与发展使得网民在观看视频前，只需要经过短暂的等待之后，即可以一边下载一边观看欣赏所点播的视频节目，从而无须再等到整个视频节目全部下载完毕。显然，流媒体技术给人们欣赏视频节目带来了更好的观看体验。由于对等网络(Peer to Peer，简称P2P)流媒体点播系统具有较好的可扩展性，学术界和工业界的研究人员以及工程师对其进行了深入的研究和研发。目前，基于P2P的流媒体点播系统已经在技术上实现了一定的突破，在国内外取得了丰硕的成果。在P2P网络中，每个节点是对等的，每一个节点可作为客户端(Client)向服务器或者向其他的节点获取视频资源，同时也可作为服务端(Server)给其他对等的节点提供自身节点含有的视频资源。在网络中，每个节点贡献出自己的上行带宽和内存中存储的视频资源，从而使得网络中节点对服务器视频流的需求大大降低，减轻了服务器的负担。

P2P流媒体点播系统中，每个节点都有机会服务系统中其它节点，如果不采取有效的措施，容易造成一些节点收到太多请求，会使有些请求被延迟或无法处理。另一方面，一些节点可能会收到太少的请求，从而导致节点上行带宽利用率低。在这种情况下，负载不均衡的问题将会发生，部分请求不能被及时处理，容易导致视频播放卡顿的问题。同时，由于网络结构可能是异构的，每个节点的吞吐量或上行带宽是不同的，这就使得每个节点的请求压力不一样，致使一些节点发生超载。因此，如何保持节点之间的负载均衡，以避免某些节点超载；如何确保来自其他节点的请求得到更稳定和更快速地响应，这些都是需要解决的问题。目前，众多学者和工程师针对P2P流媒体点播系统中的节点负载均衡问题做了很多努力，并且许多策略已经用来改善系统的服务质量。较早提出的基于得分函数的请求分配策略，该策略在一定程度上提高了节点的负载平衡性。然而，它没有考虑请求的差异性，容易造成视频点播时观看不流畅的问题。此外，在基于局部网络信息的负载均衡方法，用以提高系统均衡速度，但该算法基于每个节点的容量和能力一致的假设，与实际情况存在着差异。因此，需要设计更为有效的节点负载均衡方法，提高P2P流媒体点播系统的效率。

发明内容

本发明目的在于提出一种P2P流媒体点播系统中基于请求队列的节点负载均衡方法，解决节点负载均衡的问题。

本发明实现上述目的的技术解决方案是：P2P流媒体点播系统中基于请求队列的节点负载均衡方法，其特征在于，所述节点负载均衡方法包括：

步骤1：当前节点检查自身请求队列中是否有新的请求加入；

步骤2：如果有新的请求加入，则更新计算请求队列中每个请求的优先级；并按照每个请求的优先级排序，确定队列中的每个请求是否能够及时处理；

步骤3：当前节点计算所有邻居节点的利用函数，并进行从大到小排序，选出利用函数最大的节点作为接收节点，把不能及时响应的请求转移到接收节点进行处理。

进一步地，所述步骤2中计算请求的优先级的过程包括：

步骤2-1：计算当前节点请求队列中每个请求的稀缺性，由公式得到，其中，R_j表示请求j的稀缺性，N表示当前节点的邻居节点数目，BM[i][j]表示邻居节点i是否拥有请求j；如果邻居节点i中没有缓存请求j的数据块，则BM[i][j]＝0，反之邻居节点i缓存有请求j的数据块，则BM[i][j]＝1；

步骤2-2：计算当前节点队列中每个请求的紧迫性，由公式得到，其中，U_j表示请求j的紧迫性，t_r表示请求j的播放位置，t_p表示节点当前播放时刻，T_v代表视频的总时长；

步骤2-3：计算当前节点请求队列中每个请求的优先级，计算公式为：

其中，P_j表示请求j的优先级；平滑播放阈值δ＝8，α为10～15范围内的随机整数；

步骤2-4：节点将请求优先级从高到低进行排序并合计当前请求队列中的请求数目设为C，节点判断请求数目C相对自身预设最大处理请求数量M的大小，如果C≤M，则节点处理当前请求队列中的C个请求，如果C＞M，则节点只处理当前请求队列中优先级排名前M个请求，余下C-M个请求做转移处理。

进一步地，所述步骤3中计算利用函数，并选择处理当前节点不能及时响应的请求的接收节点的过程包括：

步骤3-1：计算当前节点的每个邻居节点的稳定性，由公式得到，其中，S_i表示该邻居节点i的稳定性，t_ave表示该节点平均每一天的上线时间，单位是分钟，n_ave表示该节点平均一天的上下线次数；

步骤3-2：计算当前节点的每个邻居节点的负载度，由公式得到，

其中，request_queue(t)为在t时刻，邻居节点i的任务队里的待处理请求的长度，MRQS为任务队列长度的最大值，并且负载度的取值为load_degree(t)∈[0,1]；

步骤3-3：综合邻居节点的上行带宽B_u以及计算得到的稳定性和负载度，计算当前节点的每个邻居节点的利用函数值，计算公式为：

得t时刻邻居节点i的利用函数的取值范围w_i(t)∈[0,B_u]；

步骤3-4：将各邻居节点利用函数值从高到低进行排序，并把步骤2中不能及时响应的请求转移到利用函数值最高的邻居节点进行处理。

应用本发明创新提出的节点负载均衡方法，较之于传统技术，具有突出的实质性特点和显著的进步性：能够有效使现有P2P流媒体点播系统中负载达到均衡，提高整个网络的效率；以确保紧急的请求可以尽快被响应处理保证了节点视频播放的平滑性，从而保证了用户观看体验；在计算节点的利用函数时，综合考虑了节点的上行带宽、稳定性、负载度因素，可以把不能及时处理的请求分配到低利用率的接收节点，优化了网络的资源配置。

附图说明

图1为本发明涉及的基于请求队列的节点负载均衡方法的流程图。

图2为视频被点播的概率分布。

图3为本发明所涉及的方法和其他方法的节点上行带宽利用率的累计分布变化曲线。

图4为本发明所涉及的方法和其他方法的播放流畅度的变化曲线。

图5为本发明所涉及的方法和其他方法的节点超载比例的变化曲线。

具体实施方式

下面结合说明书附图对本发明创造作进一步的详细说明。

如图1所示，本发明提供了P2P流媒体点播系统中基于请求队列的节点负载均衡方法，该方法包括如下步骤：

步骤1：当前节点检查其请求队列中是否有新的请求(视频数据块)加入；

步骤2：如果有新的请求加入，则更新计算请求队列中每个请求的优先级；并按照每个请求的优先级排序，确定队列中的每个请求是否能够及时处理；

(2-1)计算当前节点的队列中每个请求的稀缺性；

稀缺性定义为当前节点的邻居节点缓存中也拥有该请求的比率，其计算公式如下：

其中，R_j表示请求j的稀缺性，N表示当前节点的邻居节点数目(在P2P流媒体通信系统中通常定义为与当前节点处在某个设定距离范围内的节点为邻居节点)。BM[i][j]表示邻居节点i是否拥有请求j。如果邻居节点i中没有缓存该数据块，则BM[i][j]＝0，反之邻居节点i缓存了该数据块，则BM[i][j]＝1。根据定义可知，R_j的值越大，表明P2P网络中拥有该请求j的节点越多。所以，当一个请求的R_j越大时，应该越早处理它，以减少数据的稀缺性并提高资源的分享效率。

(2-2)计算当前节点队列中每个请求的紧迫性；

请求的紧迫性的计算公式如下：

其中，U_j表示请求j的紧迫性，t_r表示该请求的播放位置，t_p表示节点当前播放时刻，T_v代表视频的总时长。从上式中可以得知，t_r越接近t_p，请求j对于当前节点而言紧迫性越高。

(2-3)计算当前节点队列中每个请求的优先级；

综合请求的稀缺性和紧急性，请求j的优先级计算公式如下：

其中，P_j表示请求j的优先级。需要说明的是，为了尽可能的保证紧急请求尽快完成，在这里定义请求优先级时，综合考虑了平滑播放阈值δ。为了尽可能保证节点播放的平滑性，设当前节点播放视频的时刻为t_p，那么t_p到t_p+δ这一段时间区间的数据块应该缓存到该节点的缓存中，否者会很容易产生视频播放卡顿现象。所以，在t_r<t_p+δ时，对于请求紧迫性和请求稀缺性二者而言，应该优先考虑请求的紧迫性，因此，给予请求紧迫性U_j以α(α为10～15范围内的随机整数)的权重，这就保证了平滑播放区的数据块优先下载。对于请求优先级的数值在t_r≥t_p+δ时，紧迫性和稀缺性对于节点播放视频的影响几乎相近，所以只需要综合请求数据块的稀缺性和紧急性来确定优先级，二者的权重相同。

(2-4)将请求优先级从高到低进行排序，节点判断其当前最大处理请求的数量(设为M)，如果该节点当前队列中的请求数目(设为C)超过了M，则只处理优先级排名前M个的请求，而将C-M个不能及时响应的请求转移到其他可靠节点。如果C≤M，则当前节点自己可以处理当前队列中的所有请求。

步骤3：把不能及时响应的请求进行转移到其他可靠节点，即，当前节点计算所有邻居节点的利用函数，并进行从大到小排序，选出利用函数最大的那个节点作为接收节点；

(3-1)计算当前节点的每个邻居节点的稳定性；

在阐述稳定性之前先明确一下节点在线以及节点上下线频率的概念。这里的节点在线，是指节点可以被P2P网络其他节点发现并且互相分享资源。与之相对应的，下线是指节点不能被P2P网络其他节点发现并利用。上下线频率，是指单位时间内节点的上线次数或者下线次数。

在P2P网络中，节点的自由加入和离开使得该网络有较强的不稳定性，即使上行带宽比较大的节点也不能很好的为其它节点进行提供服务。基于此，考虑通过节点的在线时间来衡量节点的稳定性。但是，仅仅用在线时间对于评估节点的稳定性不够准确。一个总在线时间比较长，但是上下线频率非常大的节点，仍然无法提供好的服务。针对这个问题，本发明把节点的上线次数引入到节点稳定性的计算中，计算如下：

其中，S_i表示该邻居节点i的稳定性，t_ave表示该节点平均每一天的上线时间，单位是分钟，n_ave表示该节点平均一天的上下线次数。由该式可知，S_i的值越大，表示节点i的稳定性越强。

(3-2)计算当前节点的每个邻居节点的负载度；

在P2P流媒体点播系统中，每个节点都可能作为服务者，向系统中的其它节点传输视频数据块，提供视频服务。对于来自不同节点的视频下载请求，作为服务者的当前节点不能一次性全部服务完毕，必然会按照一定的优先级进行排队进行处理。由于节点在P2P流媒体点播系统中具有不稳定性，不可能让过多的请求进行排队处理。基于此，这里根据邻居节点的队列的利用情况来定义负载度，计算公式如下：

其中，request_queue(t)为在t时刻，邻居节点i的任务队里的待处理请求的长度，MRQS为队列长度的最大值；由该公式可知，负载度的取值为load_degree(t)∈[0,1]，该值越大表示节点未来的负载压力越大，可利用率越低。

(3-3)定义计算当前节点的每个邻居节点的利用函数；

在P2P点播系统中，带宽的大小是影响视频播放流畅度最重要的原因之一，特别是对于那些高码率的视频影响更大。用户对于带宽的追求是永无止境的，这也是各大运营商比较关心的问题。所以上行带宽B_u也为节点选择的最重要因素之一。

综合节点的上行带宽B_u(由节点的控制模块直接获得)，以及计算得到的稳定性和负载度，定义在t时刻邻居节点i的利用函数为w_i(t)，其计算公式如下：

综合这三方面的因素知，t时刻邻居节点i的利用函数的取值范围w_i(t)∈[0,B_u]；

(3-4)将各邻居节点利用函数值从高到低进行排序，把不能及时响应的请求转移到利用函数值最高的邻居节点，让该节点进行处理。

本发明的性能评价如下：

为了验证本发明方法的性能，所模拟的网络中有一个PTS，一个PSN还有众多节点。其中，PTS负责定期更新记录网络中所有节点的信息，同时它也负责为请求节点进行视频资源定位。PSN拥有网络中所有完整的视频，当网络中的请求节点在其他的节点中找不到视频资源，则请求节点会向PSN获取视频资源。

节点进入网络的模型	线性分布
		视频被点播的概率	Zipf分布
节点的上行带宽	均匀分布
		节点的在线时间	正太分布
邻居节点数目	20
		PSN的上行带宽	50Mbps
MRQS	5
		视频码率	512kbps
视频块大小	256KB

实验参数设置如上表所示，需要说明的是其中的四个分布：①每次实验首先预设好节点数目，节点进入网络遵循线性分布。具体而言，以每10秒增加25个节点的速度增加到预设的节点数目。②网络中有400个视频进行分享，实验中，设置节点观看视频服从Zipf分布,则视频k分点播的概率p(k)服从下面的公式。

其中，N表示是网络中视频数目，这里N＝400,β＝0.6。k表示视频热度的排名。视频号越小的视频热门度越高。从而得到视频被点播的概率分布，如图2。③设置节点的上行带宽服从256kb～1024kbps均匀分布；④设置节点每一天的在线时间服从一个正态分布，其中节点平均在线时间μ＝5h。

需要说明的是，在所设计的负载均衡策略中，δ值的大小会影响系统中节点播放视频的播放流畅度以及节点的上行带宽利用率。一方面，δ值过大，稀缺数据块的请求得到处理的概率将降低，从而使得更多的稀缺性数据块转向服务器去请求，增大了服务器的负载，降低了节点的平均上行带宽利用率。如果δ值设定过大，则对于每个请求都是紧急请求，也就失去了平滑播放区的意义。另一方面，δ值过小，会使得节点出现播放不流畅的可能性增加。所以，综合考虑，在本发明中，δ的取值为8秒。

(1)节点上行带宽利用率性能比较：

该组实验是在节点数为2000时，其他实验参数不变的环境下进行观察统计的三种策略的节点上行带宽利用率对比结果，如图3所示。

理论分析表明，本发明提出的基于请求队列的节点负载均衡方法(Request QueueLoad Balacing，简称RQLB)，把一些高负载节点的负载转移到那些低利用率的节点进行处理。那么，系统中节点的上行带宽使用情况应该会得到一定程度的改善。

从图3中可以看到，本发明提出的RQLB方法，节点上行带宽利用率低于0.6的节点比例小于45％，然而对应于其他的两个策略，基于最短队列的负载均衡(Shortest QueueSize，简称SQS)的比例是63％，基于请求迁移的负载均衡策略(Load Balancing strategywhich uses a Request Migration algorithm，简称LBRM)的比例是98％。究其原因，SQS策略优先向低负载节点发送请求，因此网络中大多数节点的负载是处于相对较低的水平。LBRM会根据节点历史的负载情况进行调整节点选择，虽然历史数据不能及时反映节点负载情况，但是也是可以作为一定的参考，使得低负载的节点接收到更多的请求。但是RQLB在选择节点时，充分利用节点服务队列，及时得知节点的负载情况，把转移的负载更精确地发送到低利用率的节点上进行处理。所以，SQS和LBRM策略中，上行带宽低利用率的节点数目高于本章提出的策略RQLB。对于上行带宽利用率在0.6到0.8之间的节点数目，RQLB是远远大于其它两个策略的。综上，说明本发明提出的RQLB方法相对其他两个方法，能够更加准确地把负载转移到低利用率的节点上进行处理，降低了高负载节点出现的可能性，同时，充分使用低利用率的节点，从而使得网络中的节点的上行带宽得到充分利用，负载得到了平衡。

(2)节点的播放流畅度性能比较：

在该组实验中，改变预设的目标节点数，从500-3000进行变化，分别进行了实验。为了衡量播放流畅度，图4比较了三种不同方案下的播放连续性指数。播放连续性指数定义为节点实际获得的数据与总需求数据的比率。该值越高，视频播放就越流畅。在P2P流媒体点播系统中，过载的节点不能及时为他人服务，从而导致有些请求节点不能在规定的时间内获取数据块，这大大地影响服务质量。因此，一个好的负载平衡方法需要保证用户的播放流畅性。

从图4可以看出，三种方法的播放质量随着节点数的增加得到了改善，最后趋于稳定状态。其中本发明所设计的RQLB方法的CI值在网络大小为500-3000个节点的情况下，都是大于其它两个策略的，即RQLB>LBRM>SQS。主要原因为，RQLB方法可以更准确地选择到低负载的节点，有效地减少了系统中超载节点的数量。此外，RQLB方法在考虑请求的优先级时，充分考虑了播放流畅区域，使得即将播放的数据块请求能够得到优先的分配处理。对于LBRM，其把请求的紧急性和稀缺性的两个因素同等看待，虽然考虑到了请求的紧急性，但是，在一定程度上无法及时处理紧急的请求，和RQLB方法相比表现较差。对于SQS，其没有考虑请求的紧急性，使得紧急的请求不能够得到及时处理，因而性能最差。

(3)超载节点比例性能比较：

在P2P流媒体点播系统中，为了实现节点的负载均衡，需要及时调整节点的请求队列，将超载节点的负载转移出去。节点负载是指节点单位时间上传的数据块总量与节点在该单位时间内可以供给总数据的比值。在本论文中，我们通过下面的公式计算节点i的带宽负载。

其中，U_i(t)表示i节点在时间t内上传的视频总量，单位是MB。B_i表示i节点的上行带宽。本论文定义：当i节点的节点负载load(i)>95％为超载。

统计节点超载的实验与以上两组实验不同，该组实验设定初始化节点的数目为3000，当系统中节点超载比例达到12％左右时，开始使用三种负载均衡方法，然后观察统计三种方法的节点超载比例，如图5所示。

从图5节点超载比例仿真结果可以看出，在第0～100观察周期，三种方法中节点超载的比例下降的速度为：RQLB>LBRM>SQS。三种方法都考虑到节点的负载情况，使得节点超载的比例都得到了下降。但是当第100～200周期时，三种方法中，节点超载比例都趋于稳定，本发明文提出的RQLB方法，节点超载的比例依然比其他两个方法低。主要原因是，SQS虽然考虑了节点服务队列的长度，但是该方法没有考虑节点的服务能力，导致选择的节点因不能及时处理请求而超载；LBRM虽然考虑了节点的处理能力，但是该方法主要利用了历史记录对节点的负载能力进行估计，由于估计的准确性不够，导致仍然有一些节点超载。在之后的周期中，本发明提出的RQLB方法中超载节点的比例也是最低的，说明RQLB在降低超载节点比例的效率和速度上，是优于其他两种方法的。

上面结合附图对本发明的实施方式作了详细说明，但是本发明并不限于上述实施方式，在本领域普通技术人员所具备的知识范围内，还可以在不脱离本发明宗旨的前提下做出各种变化。

Claims (3)

1.P2P流媒体点播系统中基于请求队列的节点负载均衡方法，其特征在于，所述节点负载均衡方法包括：

步骤1：当前节点检查自身请求队列中是否有新的请求加入；

步骤2：如果有新的请求加入，则更新计算请求队列中每个请求的优先级；并按照每个请求的优先级排序，确定队列中的每个请求是否能够及时处理；

步骤3：当前节点计算所有邻居节点的利用函数，并进行从大到小排序，选出利用函数最大的节点作为接收节点，把不能及时响应的请求转移到接收节点进行处理。

2.根据权利要求1所述的P2P流媒体点播系统中基于请求队列的节点负载均衡方法，其特征在于，所述步骤2中计算请求的优先级的过程包括：

步骤2-1：计算当前节点请求队列中每个请求的稀缺性，由公式得到，其中，R_j表示请求j的稀缺性，N表示当前节点的邻居节点数目，BM[i][j]表示邻居节点i是否拥有请求j；如果邻居节点i中没有缓存请求j的数据块，则BM[i][j]＝0，反之邻居节点i缓存有请求j的数据块，则BM[i][j]＝1；

步骤2-2：计算当前节点队列中每个请求的紧迫性，由公式得到，其中，U_j表示请求j的紧迫性，t_r表示请求j的播放位置，t_p表示节点当前播放时刻，T_v代表视频的总时长；

步骤2-3：计算当前节点请求队列中每个请求的优先级，计算公式为：

其中，P_j表示请求j的优先级；平滑播放阈值δ＝8，α为10～15范围内的随机整数；

步骤2-4：节点将请求优先级从高到低进行排序并合计当前请求队列中的请求数目设为C，节点判断请求数目C相对自身预设最大处理请求数量M的大小，如果C≤M，则节点处理当前请求队列中的C个请求，如果C＞M，则节点只处理当前请求队列中优先级排名前M个请求，余下C-M个请求做转移处理。

3.根据权利要求1所述的P2P流媒体点播系统中基于请求队列的节点负载均衡方法，其特征在于，所述步骤3中计算利用函数，并选择处理当前节点不能及时响应的请求的接收节点的过程包括：

步骤3-1：计算当前节点的每个邻居节点的稳定性，由公式得到，其中，S_i表示该邻居节点i的稳定性，t_ave表示该节点平均每一天的上线时间，单位是分钟，n_ave表示该节点平均一天的上下线次数；

步骤3-2：计算当前节点的每个邻居节点的负载度，由公式得到，

其中，request_queue(t)为在t时刻，邻居节点i的任务队里的待处理请求的长度，MRQS为任务队列长度的最大值，并且负载度的取值为load_degree(t)∈[0,1]；

步骤3-3：综合邻居节点的上行带宽B_u以及计算得到的稳定性和负载度，计算当前节点的每个邻居节点的利用函数值，计算公式为：

得t时刻邻居节点i的利用函数的取值范围w_i(t)∈[0,B_u]；

步骤3-4：将各邻居节点利用函数值从高到低进行排序，并把步骤2中不能及时响应的请求转移到利用函数值最高的邻居节点进行处理。