CN107493485B - 一种资源控制方法、装置和iptv服务器 - Google Patents

Abstract

本发明实施例提供一种资源控制方法、装置和IPTV服务器，通过采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小，根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源的大小，接收资源调整请求，根据资源调整请求调整剩余资源。采用上述方案，利用节点间资源数据同步机制，及时将各节点占用的资源大小进行同步，通过这样高效的资源数据同步机制，每个节点均可以直接响应资源调整请求，由此实现多节点分布式资源控制，当有多个用户同时请求资源的分配时，由多个节点协同进行资源分配的处理，使得能及时响应用户的请求，提高了处理效率，提升了用户体验。

Description

一种资源控制方法、装置和IPTV服务器

技术领域

本发明涉及交互式网络电视(IPTV，Internet Protocol Television)领域，尤其涉及一种资源控制方法、装置和IPTV服务器。

背景技术

在目前的IPTV业务领域中，在为用户分配资源时，现有解决方案中均是采用集中式的资源分配方法，利用部署一台负载均衡服务器(Load Service Blance，简称LSB)来进行并发资源控制。首先LSB规划配置各个节点能够使用的资源大小，各个节点会定时上报自身能够使用的资源大小以及已使用资源大小给LSB。当有用户请求时，用户请求会直接向该LSB发起服务定位请求，LSB根据各个节点上报的资源情况，为该用户分配服务节点。用户在节点接受服务后，该节点收集本节点的已使用资源大小变化情况，并在下一次定时上报过程中，将该节点的自身能够使用的资源大小以及已使用资源大小变化情况上报给LSB。LSB收到上报数据后，更新该节点的资源情况，在下一次用户请求时，进行策略选择使用。

在上述方案中，由于所有的用户都要经过LSB进行服务定位，以及所有节点都要上报本节点已使用资源大小到LSB，由此会导致大量的消息集中在LSB处理，而LSB的处理能力是有限的，所以当有多个用户同时请求资源的分配时，LSB会处理不过来，使得不能及时处理某些用户的请求，造成用户体验差。

针对上述问题，提出一种分布式的资源控制方法，是本领域技术人员亟待解决的技术问题。

发明内容

本发明实施例主要解决的技术问题是，提供一种资源控制方法、装置和IPTV服务器，解决现有技术中，当有多个用户同时请求资源的分配时，采用集中式的资源分配方式，使得某些用户的请求处理不及时，造成用户体验差的问题。

为解决上述技术问题，本发明实施例提供一种资源控制方法，包括：

采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小；

根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源的大小；

接收资源调整请求，根据资源调整请求调整剩余资源。

为解决上述技术问题，本发明实施例提供一种资源控制装置，包括：

资源获取模块，用于采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小；

剩余资源确定模块，用于根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源的大小；

接收模块，用于接收资源调整请求；

调整模块，用于根据资源调整请求调整剩余资源。

为解决上述技术问题，本发明实施例还提供一种IPTV服务器，包括上述的资源控制装置。

为解决上述技术问题，本发明实施例还提供一种计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于执行前述的任一项的资源控制方法。

本发明的有益效果是：

根据本发明实施例提供的资源控制方法、装置和IPTV服务器，通过采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小，根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源的大小，接收资源调整请求，根据资源调整请求调整剩余资源。采用上述方案，利用节点间资源数据同步机制，及时将各节点占用的资源大小进行同步，通过这样高效的资源数据同步机制，每个节点均可以直接响应资源调整请求，由此实现多节点分布式资源控制，当有多个用户同时请求资源的分配时，由多个节点协同进行资源分配的处理，有效提升了节点并发能力控制水平，使得能及时响应用户的请求，提高了处理效率，极大的提高了节点能力控制的准确性，提升了用户体验，避免了利用集中式资源控制所带来的性能瓶颈问题。

附图说明

图1为本发明实施例一提供的一种资源控制方法的流程图；

图2为本发明实施例一提供的拓扑关系图；

图3为本发明实施例二提供的一种资源控制装置的结构示意图。

具体实施方式

下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。

实施例一

为了避免集中式资源控制所带来的性能瓶颈问题，本实施例提供一种资源控制方法，请参见图1，包括以下步骤：

S101：采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小。

应当理解的是，节点指的是IPTV服务器，采集本节点占用的资源大小是指由IPTV服务器采集自身所占用的资源大小。其中，由管理平台管理本节点和所有协同处理节点，本实施例的方案，每个节点不是预先分配固定大小的允许占用的资源大小，而是由管理平台分配固定大小的总资源大小给所有节点，每个节点允许占用的资源大小之和为管理平台分配的总资源大小，在进行资源分配时，只用考虑总的剩余资源够不够请求的资源大小即可。相对于现有技术中预先给每个节点分配固定大小的允许占用的资源大小，采用本实施例的方案在进行资源分配时更加灵活。例如管理平台管理了节点1、节点2这两个节点，分配的总资源大小为5G，节点1、节点2分别占用了1G，此时在节点1处请求3G的资源，则节点1在确定出总的剩余资源的大小为3G后，节点1直接分配总的剩余资源3G给请求方。

应当理解的是，协同处理节点指的是，两两节点之间有进行资源数据的同步、共享同一个管理平台分配的资源大小的节点，比如管理平台管理了三个节点，管理平台分配给三个节点一共12G的资源大小，这三个节点能使用的最大的资源大小为12G，且每个节点均会将本节点占用的资源大小同步到另两个节点，这种情况下，三个节点互为协同处理节点。

因为是由管理平台管理本节点和所有协同处理节点，由管理平台分配本节点和所有协同处理节点一共允许占用的资源大小，为了准确的确定出剩余资源的大小，在本节点处进行资源分配时，有必要获取所有协同处理节点占用的资源大小。

采集本节点占用的资源大小、获取所有协同处理节点占用的资源大小、获取管理平台分配的总资源大小这三个步骤执行的顺序可以是任意的，也可以是同时进行。

其中，本节点占用的资源大小可以通过定时采集本节点业务相关的性能数据得到，采集的性能数据包括但不限于：本节点的cpu使用率、内存使用率、网口流量、节点读写IO能力。在采集到了本节点占用的资源大小之后，将采集到的本节点占用的资源大小更新并存储在本节点上，在更新完本节点占用的资源大小时，同时触发资源数据同步，将本节点占用的资源大小同步到与本节点协同处理的协同处理节点上，协同处理节点在接收到资源数据更新同步后，对应更新该节点上的资源占用情况，便于后续资源判断使用。为了实现多个节点协同控制资源并发，需要采用节点间资源数据同步机制，及时将各节点占用的资源大小进行同步，通过这样高效的资源数据同步机制，在进行业务服务时，各个节点都能快速了解到协同处理节点占用的资源大小，提高了处理效率，极大的提高了节点能力控制的准确性。

获取所有协同处理节点占用的资源大小包括：获取所有协同处理节点定时发送的占用的资源大小；和/或，对于有占用的资源大小更新的协同处理节点，接收该协同处理节点发送的占用资源大小更新信息。对于有资源大小更新的任何一个协同处理节点，该节点立即将更新后的资源大小同步到其他协同处理节点，使得其他协同处理节点能及时地了解到所有节点已占用的资源大小，在后续处理资源调整请求时，能对剩余资源的分配更加准确，有效的解决了多节点并发处理过程时，对资源能力控制延迟的问题，提高了处理效率。

在获取到所有协同处理节点占用的资源大小之后，及时将获取到的协同处理节点占用的资源大小更新并存储在本节点上，以便在进行业务服务时，各个节点都能快速了解到协同处理节点占用的资源大小，有效的解决了多节点并发处理过程时，对资源能力控制延迟的问题，提高处理效率。

管理平台下发允许所有节点一共使用的资源大小给每个节点，每个节点接收到后进行存储，作为后续资源判断的依据。

S102：根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源的大小。

所有节点的剩余资源的大小可以通过以下计算方法得到：计算本节点的占用的资源大小与协同处理节点占用的资源大小之和，得到所有节点占用的资源大小，再计算所有节点允许使用的资源大小与上述得到的所有节点占用的资源大小之差，得到所有节点剩余资源的大小。所有节点的剩余资源的多少可以反映出所有节点还能提供给用户多少的资源。

S103：接收资源调整请求，根据资源调整请求调整剩余资源。

在本节点处接收到资源调整请求后，对请求的业务和所需资源大小进行解析，确认该业务需要哪些资源项目，比如用户所请求的业务为点播业务，该用户需要占用0.1％的cpu使用率、2Mb的内存占用、2Mb的网口出向流量、2Mb的网口入向流量、4Mb的节点读写IO能力。

为了实现业务功能的多样化、可以提供给用户多种业务功能方式，其中，资源调整请求可以包括接入请求、退出请求、资源调大请求、资源调小请求。

对于接入请求或资源调大请求，根据请求中需要调整的资源大小从剩余资源中进行分配，若分配不成功则反馈资源不足信息给请求方，告知请求方进行请求的重定向。

具体的，资源调整请求为接入请求或资源调大请求时，在本节点处可以判断剩余资源大小是否大于所需资源大小；若是，则从剩余资源中分配当前所需资源大小给请求方，使得剩余资源减少；若否，则结束本次业务资源申请流程，并返回给请求方资源不足的应答，让请求方走重定向流程。

通过上述的资源分配方式，在剩余资源充足的情况下，在本节点处允许请求方使用该剩余资源，在剩余资源不足以满足请求方所需资源大小的情况下，及时反馈资源不足信息给请求方，告知请求方进行请求的重定向，该节点可以直接响应资源调整请求，有效提升了节点并发能力控制水平，提高了处理效率。

对于退出请求或资源调小请求，从本节点占用的资源中收回请求中需要调整的资源大小，并将其划入剩余资源中。

具体的，资源调整请求为退出请求时，在本节点处将初始分配给请求方的资源大小收回，使得剩余资源增加；资源调整请求为资源调小请求时，从初始分配给请求方的资源中收回当前请求调整的资源大小，使得剩余资源增加。

通过上述的资源回收方式，在本节点处收回请求中需要调整的资源大小，并将其划入剩余资源中，该节点可以直接响应资源调整请求，有效提升了节点并发能力控制水平，提高了处理效率。

在另一实施例中，当同时接收到多个接入请求和/或资源调大请求时，对多个接入请求和/或资源调大请求进行排序，并依次从剩余资源中分配资源，若分配不成功则反馈资源不足信息给对应的请求方。当同时接收到多个退出请求和/或资源调小请求时，对多个退出请求和/或资源调小请求进行排序，并依次从本节点占用的资源中收回退出请求和/或资源调小请求中需要调整的资源大小，并将其划入剩余资源中。当同时接收到接入请求和退出请求时，优先处理退出请求；再从剩余资源中分配资源，若分配不成功则反馈资源不足信息给对应的请求方。

具体的，当同时接收到多个接入请求和/或资源调大请求时，对多个接入请求和/或资源调大请求排列顺序，并按照排列的顺序，依次判断剩余资源是否大于当前所需资源大小；若是，则从剩余资源中分配当前所需资源大小给请求方，使得剩余资源减少；若否，则结束本次业务资源申请流程，并返回给请求方资源不足的应答，让请求方走重定向流程。

当同时接收到多个退出请求和/或资源调小请求时，对多个退出请求和/或资源调小请求排列顺序，并按照排列的顺序，依次从本节点占用的资源中收回退出请求和/或资源调小请求中需要调整的资源大小，并将其划入剩余资源中。

当同时接收到接入请求和退出请求时，为了保证剩余资源的准确性，优先处理退出请求，从本节点占用的资源中收回退出请求中需要调整的资源大小，并将其划入剩余资源中；然后再处理接入请求，判断剩余资源是否大于当前所需资源大小；若是，则从剩余资源中分配当前所需资源大小给请求方，使得剩余资源减少；若否，则结束本次业务资源申请流程，并返回给请求方资源不足的应答，让请求方走重定向流程。例如同时接收到接入请求和退出请求，而目前剩余资源为0，接入请求所需资源为2G，退出请求所需调整资源为2G，则优先处理退出请求，从本节点占用的资源中收回退出请求中需要调整的资源大小2G，并将其划入剩余资源中，此时剩余资源的大小为2G，然后再处理接入请求，则将剩余资源分配给当前所需资源大小2G给请求方，当同时接收到接入请求和退出请求时，优先处理退出请求，保证了在处理接入请求时，剩余资源的大小是准确的。

通过上述的资源分配方式，在剩余资源能够满足N个用户同时使用的情况下，在本节点处允许这N个用户使用该剩余资源，在剩余资源不足以满足第N+1个用户所需资源大小的情况下，及时告知用户进行请求的重定向，该节点可以直接响应资源调整请求，有效提升了节点并发能力控制水平，有效的解决了多节点并发处理过程时，对资源能力控制延迟的问题，提高了处理效率。

若本节点的资源占用大小有变动，为了便于后续资源判断使用，同时也为了提高节点能力控制的实时性和准确性，在S103之后，还包括：将更新后的本节点占用的资源大小同步到所有协同处理节点，使得其他协同处理节点也能及时了解到本节点的资源占用大小变动情况。

比如管理平台管理了第一节点、第二节点、第三节点这三个节点，这三个节点进行资源的协同处理，在第一节点上触发了一次资源大小更新的流程，第一节点同时将本次资源变动后的本地数据同步到第二节点、第三节点，第二节点、第三节点收到同步的资源更新消息后，更新本节点存储的第一节点的资源占用情况，用于后续的资源判断使用。

当第二节点上也触发了一次资源大小更新的流程时，第二节点更新完成本节点资源占用情况后，将本节点的资源占用数据，同步到第一节点、第三节点上，第一节点、第三节点收到第二节点发来的同步的资源更新消息后，更新本节点存储的第二节点的资源占用情况，便于后续节点资源判断使用。

应当理解的是，接收资源调整请求与S101-S102的顺序是可以颠倒、任何一个在前的，可以是按照S101-S102-S103的顺序执行，即先采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小；再根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源的大小；再接收资源调整请求，根据资源调整请求调整剩余资源。也可以是先接收资源调整请求，再采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小；再根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源的大小；再根据资源调整请求调整剩余资源。

上述S101、S102、S103的执行主体都是本节点，即都是由本节点所做的处理。

本实施例还例举一个具体的例子进行说明，参见图2，

IPTV管理平台负责管理IPTV服务器节点1和IPTV服务器节点2，IPTV管理平台是IPTV服务器节点1和IPTV服务器节点2的后台管理平台，节点1和节点2互为协同节点，使得节点1、节点2成为有机整体，协同控制节点资源能力。

节点1和节点2中，均包含有Agent接入，主要负责接收管理平台下发的各项管理指令，并对管理指令进行解析和执行。管理平台下发本管理平台的直播服务能力带宽配置给节点1和节点2，比如直播12G网口出向带宽能力，则视为节点1、节点2共同提供12G的网口出向带宽能力，节点1、节点2收到后，每个节点对应更新并存储节点1、节点2共同允许使用的直播服务能力。

节点1、节点2均利用定时器，定时收集本节点目前提供的直播带宽服务能力，并存储在本节点上，并同步到对方节点上，比如节点1目前提供6G直播带宽，节点2提供5G直播带宽能力，利用协同节点能力同步的手段，节点1上存储有节点1提供的6G直播带宽能力数据，以及节点2已提供5G直播能力的数据；节点2上同样存储有节点2提供5G直播带宽能力的数据，以及节点1已提供6G直播带宽能力。

IPTV用户网络接入是负责接入IPTV用户服务网络的入口，信令分转服务器是负责实时流传输协议(RTSP，Real Time Streaming Protocol)信令的分发处理，按照策略将信令分别分转到不同的IPTV服务器节点上。节点1、节点2中，还包含有RTSP接入，主要负责RTSP协议处理，以及业务分析。

当有1个直播用户通过信令分转服务器呼叫到节点1时，通过解析该用户的直播业务，以及该用户所需的带宽，可以得到其需要512M的网口带宽服务。节点1上通过计算节点1、节点2共同允许使用的12G的服务能力，与节点1、节点2已用带宽总和11G的差值，得到剩余带宽为1G的服务能力，而用户只需要512M网口带宽，节点能力能够满足用户业务需求，因此节点1按照512M的带宽资源进行资源预占，更新节点1的服务能力，并同时将变化后的节点1的已用带宽6.5G同步给节点2，节点2收到同步消息后，及时在节点2更新存储的节点1的直播带宽使用情况，便于后续节点直播带宽资源限制使用。此时，节点1上存储有节点1提供的6.5G直播带宽能力数据，以及节点2已提供5G直播能力的数据；节点2上同样存储有节点2提供5G直播带宽能力的数据，以及节点1已提供6.5G直播带宽能力。

在此之后，当有1个直播用户通过信令分转服务器呼叫到节点2时，通过解析该用户的直播业务，以及该用户所需的带宽，可以得到该用户所需要的是600M网口带宽服务，节点2通过计算节点1、节点2共同允许使用的12G的服务能力，与节点1、节点2已用带宽总和11.5G的差值，得到剩余带宽为0.5G的服务能力，剩余带宽不足以提供用户600M的网口带宽服务，则返回给用户资源不足的信息，触发用户重新定位节点服务。

根据本发明实施例提供的资源控制方法，通过采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小，根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源大小，接收资源调整请求，根据资源调整请求调整剩余资源。采用上述方案，利用节点间资源数据同步机制，及时将各节点占用的资源大小进行同步，通过这样高效的资源数据同步机制，每个节点均可以直接响应资源调整请求，由此实现多节点分布式资源控制，当有多个用户同时请求资源的分配时，由多个节点协同进行资源分配的处理，有效提升了节点并发能力控制水平，使得能及时响应用户的请求，提高了处理效率，极大的提高了节点能力控制的准确性，提升了用户体验，避免了利用集中式资源控制所带来的性能瓶颈问题。

实施例二

为了避免集中式资源控制所带来的性能瓶颈问题，本实施例提供一种资源控制装置，请参见图3，应当理解的是，该资源控制装置30可以包括处理器，处理器用于执行存储在存储器中的以下模块：资源获取模块301，用于采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小。

剩余资源确定模块302，用于根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源的大小。

接收模块303，用于接收资源调整请求。

调整模块304，用于根据资源调整请求调整剩余资源。

应当理解的是，节点指的是IPTV服务器，采集本节点占用的资源大小是指由IPTV服务器采集自身所占用的资源大小。其中，由管理平台管理本节点和所有协同处理节点，本实施例的方案，每个节点不是预先分配固定大小的允许占用的资源大小，而是由管理平台分配固定大小的总资源大小给所有节点，每个节点允许占用的资源大小之和为管理平台分配的总资源大小，在进行资源分配时，只用考虑总的剩余资源够不够请求的资源大小即可。相对于现有技术中预先给每个节点分配固定大小的允许占用的资源大小，采用本实施例的方案在进行资源分配时更加灵活。例如管理平台管理了节点1、节点2这两个节点，分配的总资源大小为5G，节点1、节点2分别占用了1G，此时在节点1处请求3G的资源，则节点1在确定出总的剩余资源的大小为3G后，节点1直接分配总的剩余资源3G给请求方。

应当理解的是，协同处理节点指的是，两两节点之间有进行资源数据的同步、共享同一个管理平台分配的资源大小的节点，比如管理平台管理了三个节点，管理平台分配给三个节点一共12G的资源大小，这三个节点能使用的最大的资源大小为12G，且每个节点均会将本节点占用的资源大小同步到另两个节点，这种情况下，三个节点互为协同处理节点。

因为是由管理平台管理本节点和所有协同处理节点，由管理平台分配本节点和所有协同处理节点一共允许占用的资源大小，为了准确的确定出剩余资源的大小，在本节点处进行资源分配时，有必要获取所有协同处理节点占用的资源大小。

若本节点的资源占用大小有变动，为了便于后续资源判断使用，同时也为了提高节点能力控制的实时性和准确性，还包括同步模块305，用于在调整模块304根据资源调整请求调整剩余资源之后，将更新后的本节点占用的资源大小同步到所有协同处理节点，使得其他协同处理节点也能及时了解到本节点的资源占用大小变动情况。

其中，本节点占用的资源大小可以通过定时采集本节点业务相关的性能数据得到，资源获取模块301采集的性能数据包括但不限于：本节点的cpu使用率、内存使用率、网口流量、节点读写IO能力。在采集到了本节点占用的资源大小之后，将采集到的本节点的资源占用大小更新并存储在本节点上，更新完本节点的资源占用大小时，同时触发同步模块305进行资源数据的同步，将本节点占用的资源大小同步到与本节点协同处理的协同处理节点上，协同处理节点在接收到资源数据更新同步后，对应更新该节点上的资源占用情况，便于后续资源判断使用。为了实现多个节点协同控制资源并发，需要采用节点间资源数据同步机制，及时将各节点的资源占用大小进行同步，通过这样高效的资源数据同步机制，在进行业务服务时，各个节点都能快速了解到协同处理节点占用的资源大小，提高了处理效率，极大的提高了节点能力控制的准确性。

资源获取模块301用于：获取所有协同处理节点定时发送的占用的资源大小；和/或，对于有占用的资源大小更新的协同处理节点，接收该协同处理节点发送的占用资源大小更新信息。对于有资源大小更新的任何一个协同处理节点，该节点立即将更新后的资源大小同步到其他协同处理节点，使得其他协同处理节点能及时地了解到所有节点已占用的资源大小，在后续处理资源调整请求时，能对剩余资源的分配更加准确，有效的解决了多节点并发处理过程时，对资源能力控制延迟的问题，提高了处理效率。

在资源获取模块301获取到所有协同处理节点占用的资源大小之后，及时将获取到的协同处理节点占用的资源大小更新并存储在本节点上，以便在进行业务服务时，各个节点都能快速了解到协同处理节点占用的资源大小，有效的解决了多节点并发处理过程时，对资源能力控制延迟的问题，提高处理效率。

管理平台下发允许所有节点一共使用的资源大小给每个节点，每个节点接收到后进行存储，作为后续资源判断的依据。

剩余资源确定模块302可以通过以下计算方法得到所有节点的剩余资源：计算本节点的占用的资源大小与协同处理节点占用的资源大小之和，得到所有节点占用的资源大小，再计算所有节点允许使用的资源大小与上述得到的所有节点占用的资源大小之差，得到所有节点剩余资源的大小。所有节点的剩余资源的多少可以反映出所有节点还能提供给用户多少的资源。

在本节点的接收模块303接收到资源调整请求后，本节点会对请求的业务和所需资源大小进行解析，确认该业务需要哪些资源项目，比如用户所请求的业务为点播业务，该用户需要占用0.1％的cpu使用率、2Mb的内存占用、2Mb的网口出向流量、2Mb的网口入向流量、4Mb的节点读写IO能力。

为了实现业务功能的多样化、可以提供给用户多种业务功能方式，其中，资源调整请求可以包括接入请求、退出请求、资源调大请求、资源调小请求。

调整模块304用于：对于接入请求或资源调大请求，根据请求中需要调整的资源大小从剩余资源中进行分配，若分配不成功则反馈资源不足信息给请求方，告知请求方进行请求的重定向。

具体的，调整模块304用于：资源调整请求为接入请求或资源调大请求时，在本节点处可以判断剩余资源大小是否大于所需资源大小；若是，则从剩余资源中分配当前所需资源大小给请求方，使得剩余资源减少；若否，则结束本次业务资源申请流程，并返回给请求方资源不足的应答，让请求方走重定向流程。

通过上述的资源分配方式，在剩余资源充足的情况下，在本节点处允许请求方使用该剩余资源，在剩余资源不足以满足请求方所需资源大小的情况下，及时反馈资源不足信息给请求方，告知请求方进行请求的重定向，该节点可以直接响应资源调整请求，有效提升了节点并发能力控制水平，提高了处理效率。

调整模块304用于：对于退出请求或资源调小请求，从本节点占用的资源中收回请求中需要调整的资源大小，并将其划入剩余资源中。

具体的，调整模块304用于：资源调整请求为退出请求时，在本节点处将初始分配给用户的资源大小收回，使得剩余资源增加；用户请求为资源调小请求时，从初始分配给请求方的资源中收回当前请求调整的资源大小，使得剩余资源增加。

通过上述的资源回收方式，在本节点处收回请求中需要调整的资源大小，并将其划入剩余资源，该节点可以直接响应资源调整请求，有效提升了节点并发能力控制水平，提高了处理效率。

在另一实施例中，调整模块304用于当接收模块303同时接收到多个接入请求和/或资源调大请求时，对多个接入请求和/或资源调大请求进行排序；并依次从剩余资源中分配资源，若分配不成功则反馈资源不足信息给对应的请求方。调整模块304用于当同时接收到多个退出请求和/或资源调小请求时，对多个退出请求和/或资源调小请求进行排序，并依次从本节点占用的资源中收回退出请求和/或资源调小请求中需要调整的资源大小，并将其划入剩余资源中。调整模块304用于当同时接收到接入请求和退出请求时，优先处理退出请求；再从剩余资源中分配资源，若分配不成功则反馈资源不足信息给对应的请求方。

具体的，调整模块304用于当接收模块303同时接收到多个接入请求和/或资源调大请求时，对多个接入请求和/或资源调大请求排列顺序，并按照排列的顺序，依次判断剩余资源是否大于当前所需资源大小；若是，则从剩余资源中分配当前所需资源大小给请求方，使得剩余资源减少；若否，则结束本次业务资源申请流程，并返回给请求方资源不足的应答，让请求方走重定向流程。

调整模块304用于当同时接收到多个退出请求和/或资源调小请求时，对多个退出请求和/或资源调小请求排列顺序，并按照排列的顺序，依次从本节点占用的资源中收回退出请求和/或资源调小请求中需要调整的资源大小，并将其划入剩余资源中。

调整模块304用于当同时接收到接入请求和退出请求时，为了保证剩余资源的准确性，优先处理退出请求，从本节点占用的资源中收回退出请求中需要调整的资源大小，并将其划入剩余资源中；然后再处理接入请求，判断剩余资源是否大于当前所需资源大小；若是，则从剩余资源中分配当前所需资源大小给请求方，使得剩余资源减少；若否，则结束本次业务资源申请流程，并返回给请求方资源不足的应答，让请求方走重定向流程。例如同时接收到接入请求和退出请求，而目前剩余资源为0，接入请求所需资源为2G，退出请求所需调整资源为2G，则调整模块304优先处理退出请求，从本节点占用的资源中收回退出请求中需要调整的资源大小2G，并将其划入剩余资源中，此时剩余资源的大小为2G，然后再处理接入请求，则将剩余资源分配给当前所需资源大小2G给请求方，当同时接收到接入请求和退出请求时，优先处理退出请求，保证了在处理接入请求时，剩余资源的大小是准确的。

通过上述的资源分配方式，在剩余资源能够满足N个用户同时使用的情况下，在本节点处允许这N个用户使用该剩余资源，在剩余资源不足以满足第N+1个用户所需资源大小的情况下，及时告知用户进行请求的重定向，该节点可以直接响应资源调整请求，有效提升了节点并发能力控制水平，有效的解决了多节点并发处理过程时，对资源能力控制延迟的问题，提高了处理效率。

为了便于对同步模块305在对更新资源大小后进行同步的过程的理解，下面例举一个例子对更新后进行同步的过程进行说明，管理平台管理了第一节点、第二节点、第三节点这三个节点，这三个节点进行资源的协同处理，在第一节点上触发了一次资源占用大小更新的流程，第一节点同时将本次资源变动后的本地数据同步到第二节点、第三节点，第二节点、第三节点收到同步的资源更新消息后，更新本节点存储的第一节点的资源占用情况，用于后续的资源判断使用。

当第二节点上也触发了一次资源占用大小更新的流程时，第二节点更新完成本节点资源占用情况后，将本节点的资源占用数据，同步到第一节点、第三节点上，第一节点、第三节点收到第二节点发来的同步的资源更新消息后，更新本节点存储的第二节点的资源占用情况，便于后续节点资源判断使用。

根据本发明实施例提供的资源控制装置，通过资源获取模块301采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小，剩余资源确定模块302根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源大小，接收模块303接收资源调整请求，调整模块304根据资源调整请求调整剩余资源。采用上述方案，利用节点间资源数据同步机制，及时将各节点占用的资源大小进行同步，通过这样高效的资源数据同步机制，每个节点均可以直接响应资源调整请求，由此实现多节点分布式资源控制，当有多个用户同时请求资源的分配时，由多个节点协同进行资源分配的处理，有效提升了节点并发能力控制水平，使得能及时响应用户的请求，提高了处理效率，极大的提高了节点能力控制的准确性，提升了用户体验，避免了利用集中式资源控制所带来的性能瓶颈问题。

在另一实施例中还提供一种IPTV服务器，包括实施例二中的资源控制装置30，上述所有节点都可以为IPTV服务器。

在另一实施例中还提供一种计算机存储介质，计算机存储介质中存储有计算机可执行指令，计算机可执行指令用于执行实施例一种任一项的资源控制方法。

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

以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。

Claims (13)

1.一种资源控制方法，应用于IPTV服务器，包括：

采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小；所述所有协同处理节点占用的资源大小存储于本节点；所述所有协同处理节点占用的资源大小从各协同处理节点发送至所述本节点；

根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源的大小；

接收资源调整请求，根据所述资源调整请求调整所述剩余资源。

2.如权利要求1所述的资源控制方法，其特征在于，所述资源调整请求包括：接入请求、退出请求、资源调大请求和资源调小请求；所述根据所述资源调整请求调整所述剩余资源包括：

对于接入请求或资源调大请求，根据请求中需要调整的资源大小从所述剩余资源中进行分配，若分配不成功则反馈资源不足信息给请求方；

对于退出请求或资源调小请求，从本节点占用的资源中收回请求中需要调整的资源大小，并将其划入所述剩余资源中。

3.如权利要求2所述的资源控制方法，其特征在于，所述根据所述资源调整请求调整所述剩余资源包括：

当同时接收到多个所述接入请求和/或所述资源调大请求时，对多个所述接入请求和/或所述资源调大请求进行排序，并依次从所述剩余资源中分配资源，若分配不成功则反馈资源不足信息给对应的请求方。

4.如权利要求2所述的资源控制方法，其特征在于，所述根据所述资源调整请求调整所述剩余资源包括：

当同时接收到所述接入请求和所述退出请求时，优先处理所述退出请求；再从所述剩余资源中分配资源，若分配不成功则反馈资源不足信息给对应的请求方；

当同时接收到多个所述退出请求和/或所述资源调小请求时，对多个所述退出请求和/或所述资源调小请求进行排序，并依次从本节点占用的资源中收回请求中需要调整的资源大小，并将其划入所述剩余资源中。

5.如权利要求1-4任一项所述的资源控制方法，其特征在于，在所述根据所述资源调整请求调整所述剩余资源之后，还包括：将更新后的本节点占用的资源大小同步到所有协同处理节点。

6.如权利要求1-4任一项所述的资源控制方法，其特征在于，所述获取所有协同处理节点占用的资源大小包括：

获取所有协同处理节点定时发送的占用的资源大小；

和/或，对于有占用的资源大小更新的协同处理节点，接收该协同处理节点发送的占用资源大小更新信息。

7.一种资源控制装置，包括：

资源获取模块，用于采集本节点占用的资源大小，获取所有协同处理节点占用的资源大小，以及管理平台分配的总资源大小；所述所有协同处理节点占用的资源大小存储于本节点；所述所有协同处理节点占用的资源大小从各协同处理节点发送至所述本节点；

剩余资源确定模块，用于根据总资源大小、本节点占用的资源大小以及协同处理节点占用的资源大小，确定出剩余资源的大小；

接收模块，用于接收资源调整请求；

调整模块，用于根据所述资源调整请求调整所述剩余资源。

8.如权利要求7所述的资源控制装置，其特征在于，所述资源调整请求包括：接入请求、退出请求、资源调大请求和资源调小请求；

所述调整模块用于：对于接入请求或资源调大请求，根据请求中需要调整的资源大小从所述剩余资源中进行分配，若分配不成功则反馈资源不足信息给请求方；对于退出请求或资源调小请求，从本节点占用的资源中收回请求中需要调整的资源大小，并将其划入所述剩余资源中。

9.如权利要求8所述的资源控制装置，其特征在于，所述调整模块用于当所述接收模块同时接收到多个所述接入请求和/或所述资源调大请求时，对多个所述接入请求和/或所述资源调大请求进行排序，并依次从所述剩余资源中分配资源，若分配不成功则反馈资源不足信息给对应的请求方。

10.如权利要求8所述的资源控制装置，其特征在于，所述调整模块用于当同时接收到所述接入请求和所述退出请求时，优先处理所述退出请求；再从所述剩余资源中分配资源，若分配不成功则反馈资源不足信息给对应的请求方；

所述调整模块用于当同时接收到多个所述退出请求和/或所述资源调小请求时，对多个所述退出请求和/或所述资源调小请求进行排序，并依次从本节点占用的资源中收回请求中需要调整的资源大小，并将其划入所述剩余资源中。

11.如权利要求7-10任一项所述的资源控制装置，其特征在于，还包括同步模块，用于在所述调整模块根据所述资源调整请求调整所述剩余资源之后，将更新后的本节点占用的资源大小同步到所有协同处理节点。

12.如权利要求7-10任一项所述的资源控制装置，其特征在于，所述资源获取模块用于获取所有协同处理节点定时发送的占用的资源大小；

和/或，对于有占用的资源大小更新的协同处理节点，接收该协同处理节点发送的占用资源大小更新信息。

13.一种IPTV服务器，包括如权利要求7-12任一项所述的资源控制装置。

Images