CN105871750A - 一种资源调度方法及服务器 - Google Patents

Abstract

本公开的实施例提供一种资源调度方法及服务器，包括：获取客户端发送的资源获取请求；获取所述客户端的资源节点分配历史记录；根据所述客户端的资源节点分配历史记录判断所述客户端参与资源节点分配的次数是否达到预设的次数阈值M；若达到，从客户端最近N次分配到的资源节点中选择可用的资源节点分配给所述客户端；若未达到，从全部资源节点中选择可用的资源节点分配给所述客户端；M和N为正整数。本发明提供的一种资源调度方法及服务器在对客户端进行资源分配时，根据客户端的资源节点分配的历史记录向客户端分配资源节点，提高了资源节点分配速度；根据客户端IP地址归属地选取距离较近的可用资源节点，增强了网络连通性和数据传输速度。

Description

一种资源调度方法及服务器

技术领域

本公开涉及网络通信技术领域，特别是指一种资源调度方法及服务器。

背景技术

网络资源调度，是指在接收到客户端的资源请求后，根据客户端的IP地址及运营商信息，为该客户端分配适宜的网络服务器作为资源节点，使客户端成功建立网络链接。在网络资源调度的过程中，需要尽可能提高响应速度，即资源节点分配的速度；同时，还需要尽可能提高客户端与其分配到的资源节点间的网络通信速度。

现有技术中网络资源节点的分配方式十分单一，仅考虑向客户端按照地理位置分配至最近行政区域中的节点，使得部分节点长期处于高负荷状态，甚至产生任务排队，而临近节点则有大量资源空闲，导致整个系统资源利用不充分，网络吞吐量降低。有部分资源节点分配策略考虑到任务排队的问题，但是在调度排队客户端时，并没有提出合理的调度策略，无法保证客户端与其分配到的资源节点间的网络通信速度。

发明内容

有鉴于此，本公开实施例的目的之一在于提出一种资源调度方法及服务器，以降低客户端在接入资源节点时的延迟，提高接入资源节点后的网络吞吐量。

基于上述目的本公开实施例提供的一种资源调度方法，包括：

获取客户端发送的资源获取请求；

获取所述客户端的资源节点分配历史记录；

根据所述客户端的资源节点分配历史记录判断所述客户端参与资源节点分配的次数是否达到预设的次数阈值M；若达到，从客户端最近N次分配到的资源节点中选择可用的资源节点分配给所述客户端；若未达到，从全部资源节点中选择可用的资源节点分配给所述客户端；M和N为正整数。

可选的，所述从客户端最近N次分配到的资源节点中选择可用的资源节点分配给所述客户端，包括：

获取所述客户端最近N次分配到的资源节点的资源使用状态，选择可用的资源节点；

统计每个可用资源节点的分配次数；

按照分配次数由高到低的顺序，对所述可用资源节点进行排序；

按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端。

可选的，所述资源获取请求包括客户端IP地址；所述从全部资源节点中选择可用的资源节点分配给所述客户端，包括：

解析所述客户端IP地址，得到IP地址归属地；

获取全部资源节点的资源使用状态，选择可用的资源节点；

按照与所述IP地址归属地距离由近到远的顺序，对所述可用资源节点进行排序；

按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端。

可选的，所述资源获取请求还包括客户端的网络运营商信息；所述按照与所述IP地址归属地距离由近到远的顺序，对所述可用资源节点进行排序，包括：

判断所述客户端与所述资源节点是否使用相同的网络运行商；若不是，将客户端与资源节点之间的实际距离加上预设的调整值，作为用于排序的距离。

可选的，所述获取全部资源节点的资源使用状态，包括：

定时接收由资源节点发送的资源使用状态，将最新接收到该节点的资源使用状态保存为资源使用表；

需要获取节点的使用状态时，将所述资源使用表中记录的节点的资源使用状态作为该节点当前的资源使用状态。

可选的，所述获取客户端发送的资源获取请求后，包括：

判断登陆所述客户端的用户是否为定制用户；若是，从预设的定制列表中获取多个备选资源节点；

获取所述备选资源节点的资源使用状态，选择可用的资源节点；

从所述可用资源节点中选取有资源剩余的资源节点分配给所述客户端。

本公开实施例还提供一种资源调度服务器，包括：

网络单元，用于获取客户端发送的资源获取请求；

历史记录单元，用于获取所述客户端的资源节点分配历史记录；

资源分配单元，用于根据所述客户端的资源节点分配历史记录判断所述客户端参与资源节点分配的次数是否达到预设的次数阈值M；若达到，从客户端最近N次分配到的资源节点中选择可用的资源节点分配给所述客户端；若未达到，从全部资源节点中选择可用的资源节点分配给所述客户端；M和N为正整数。

可选的，所述资源分配单元包括：

第一分配模块，用于获取所述客户端最近N次分配到的资源节点的资源使用状态，选择可用的资源节点；统计每个可用资源节点的分配次数；按照分配次数由高到低的顺序，对所述可用资源节点进行排序；所述第一分配模块还用于按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端。

可选的，所述资源获取请求包括客户端IP地址；所述资源分配单元包括：

第二分配模块，用于解析所述客户端IP地址，得到IP地址归属地；获取全部资源节点的资源使用状态，选择可用的资源节点；按照与所述IP地址归属地距离由近到远的顺序，对所述可用资源节点进行排序；所述第二分配模块还用于按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端。

可选的，所述资源获取请求还包括客户端的网络运营商信息；所述第二分配模块还用于判断所述客户端与所述资源节点是否使用相同的网络运行商；若不是，将客户端与资源节点之间的实际距离加上预设的调整值，作为用于排序的距离。

可选的，所述历史记录单元用于定时接收由资源节点发送的资源使用状态，将最新接收到该节点的资源使用状态保存为资源使用表；需要获取节点的使用状态时，所述历史记录单元用于将所述资源使用表中记录的节点的资源使用状态作为该节点当前的资源使用状态。

可选的，所述资源分配单元还包括：

定制模块，响应于登陆所述客户端的用户是定制用户，所述定制模块从预设的定制列表中获取多个备选资源节点；所述定制模块还用于获取所述备选资源节点的资源使用状态，选择可用的资源节点；从所述可用资源节点中选取有资源剩余的资源节点分配给所述客户端。

从上面所述可以看出，本公开实施例提供的一种资源调度方法及服务器在对客户端进行资源分配时，根据客户端的资源节点分配的历史记录向客户端分配资源节点，提高了资源节点分配速度；根据客户端IP地址归属地选取距离较近的可用资源节点，有效提高了客户端的网络接入速度，增强了网络连通性和数据传输速度。

附图说明

图1为本公开提供的一种资源调度方法的实施例的流程示意图；

图2为本公开提供的一种资源调度方法的可选实施例的流程示意图；

图3为本公开提供的一种资源调度方法的可选实施例的流程示意图；

图4为本公开提供的一种资源调度方法及服务器的实施例的模块示意图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。

图1为本公开提供的一种资源调度方法的实施例的流程示意图。如图所示，在本发明提供的一种资源调度方法的实施例中，包括：

S10，获取客户端发送的资源获取请求。

S11，获取所述客户端的资源节点分配历史记录。用于判定客户端身份的依据，是所述资源获取请求中包括的客户端名、客户端IP地址等能够确定客户端身份的信息；在确定客户端身份之后，即可在任务日志等记录中查找该客户端历次参与过的节点分配过程，并列出每次分配到的资源节点。

S12，根据所述客户端的资源节点分配历史记录判断所述客户端参与资源节点分配的次数是否达到预设的次数阈值M，M为正整数；若达到，执行步骤S13，若未达到，执行步骤S14。

这里的“参与资源节点分配的次数”是指，客户端从发送资源获取请求到分配到合适节点这一过程，其他情况例如客户端发送资源获取请求但资源节点分配失败、或客户端在短时间内多次请求资源分配(网络不稳定导致重连)等，均不算做参与资源节点分配的次数；其中后者仅第一次成功分配资源节点的过程会记入上述参与资源节点分配的次数。即，这里的“参与资源节点分配的次数”是指，客户端从发出申请，到分配到一个可以稳定使用的资源节点的次数。

S13，从客户端最近N次分配到的资源节点中选择可用的资源节点分配给所述客户端，N为正整数。若客户端参与资源节点分配的次数足够多，则可以在这些节点中优先选择节点分配给客户端，从而节省下对全部资源节点进行对比筛选的时间，缩短客户端的接入延迟。

S14，从全部资源节点中选择可用的资源节点分配给所述客户端。这里具体的筛选过程在之后的实施例中给出。

在可选的实施方式中，所述步骤S13前，还包括：S15，判断客户端最近N次分配到的资源节点的分配时间与当前时间的差值是否小于预设的时间阈值；若是，则执行步骤S13，若不是，则执行步骤S14。本实施方式的意义为：若判定最近N次分配到的资源节点中，有部分资源节点的分配时间十分久远，说明客户端在最近并没有充分参与资源节点分配，此时所述最近N次分配到的资源节点并没有参考价值，因为较长时间之前分配到的资源节点可能已经失效，或因一些原因而增加了延迟。此时应当将该客户端视为参与资源节点分配次数不足N次的新客户端，重新执行资源节点分配，直至其最近N次参与的节点分配过程均在预设的时间阈值之内。

在可选的实施方式中，所述步骤S13后，还包括：S16，若客户端最近N次分配到的资源节点中无可用的资源节点，执行步骤S14。

本实施例中的M和N没有必然的关联。M这一数值用于评判客户端参与资源节点分配的次数，超过M次则判断该客户端之前参与连接的资源节点具备一定参考价值，可以从中选取合适的节点直接尝试连接；N则是在选取合适的节点时，用于确定选取最近的哪些节点进行连接。只要满足N≤M，即可完成上述资源节点分配过程。

本实施例在向客户端分配资源节点的过程中，优先考虑该客户端是否在最近参与过足够次数的资源节点分配过程，即是否为“常用客户”；如果是，则直接从最近客户端分配过的资源节点中选取可用节点分配给该客户端，节约了检测资源节点的时间；若果不是，则进一步从全部的资源节点中选取适宜的节点参与分配，而不是简单地随机选择有空余资源的资源节点。并且由于最近客户端分配过的资源节点一定是通过步骤S13或者S14得到的可用资源节点，因此这是一个良性的循环过程，即使客户端常用的某一节点因意外无法使用，还可以继续连接最近N次连接过的其他节点，即使最近N次的全部节点都无法连接，还可以从全部的资源节点中选取合适的节点，并且在连接后，更新了最近N次的资源节点分配状态，在进行下一次分配时又可以选取可用节点执行分配。

图2为本公开提供的一种资源调度方法的可选实施例的流程示意图。如图所示，在可选的实施例中，S13，从客户端最近N次分配到的资源节点中选择可用的资源节点分配给所述客户端，包括：

S20，获取所述客户端最近N次分配到的资源节点的资源使用状态，选择可用的资源节点。其中可用的资源节点的判定标准，包括：该节点当前处于活动状态，正在执行资源分发工作；具体该节点是否有资源剩余在之后的步骤中继续判断。

S21，统计每个可用资源节点的分配次数。

S22，按照分配次数由高到低的顺序，对所述可用资源节点进行排序。

S23，按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端，若不是，继续判断下一资源节点。

上述步骤S20-S23实现了如下过程：在向客户端分配资源节点时，首先判断最近N次分配到的资源节点中，哪些节点处于可用的活跃状态；然后进一步将这些可用节点按照它们被分配给该客户端的次数由多到少进行排序，按顺序依次判断资源节点是否有资源剩余，并将第一个有资源剩余的资源节点分配给该客户端。

本实施例是S20，获取所述客户端最近N次分配到的资源节点的资源使用状态，选择可用的资源节点的一个可选的方式。在执行分配前，首先判断资源节点是否可用，选取可用节点执行排序，从而节省了对不可用节点排序的时间。

继续参考图2，如图所示，在可选的实施例中，所述资源获取请求包括客户端IP地址；S14，从全部资源节点中选择可用的资源节点分配给所述客户端，包括：

S30，解析所述客户端IP地址，得到IP地址归属地。

S31，获取全部资源节点的资源使用状态，选择可用的资源节点。

S32，按照与所述IP地址归属地距离由近到远的顺序，对所述可用资源节点进行排序。

S33，按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端，若不是，继续判断下一资源节点。

本实施例中，对于全部资源节点内可用资源节点进行排序的步骤S32，其排序依据是资源节点与所述IP地址归属地的距离。其中一种实现方式如S32所述，直接计算距离，以数值作为判断标准，这一方式较为直接，并且在进行过一次计算后，只要定期对资源节点的地理位置信息进行更新，后续即可不用再次计算，较为省时。在其他可选的实施方式中，还包括：

S34，根据所述IP地址归属地获取客户端所在的区域，将资源节点按照与客户端所在区域由近到远的顺序进行排序。例如，这里的区域可以指行政区域，进一步以中国的行政区域为例，首先根据IP归属地确定客户端所在城市，在排序时按照“同一城市-同一省内不同城市-邻省-非邻省-同一运营商-同一国家”这一由小到大的顺序对资源节点执行排序。上述区域还可以指其他类型的区域，例如地理区域等。相对S32而言，S34的排序方式省去了第一次计算距离的过程，按照预先存储的区域列表可以很容易地执行排序，一定程度上降低了客户端第一次分配资源节点的延迟。

本实施例通过按照距离对可用资源节点进行排序，使客户端可以优先分配到距离较近的资源节点，从而在执行数据交互时享有更低的延迟。特别是与现有技术中随机分配资源节点的做法相比，本实施例的方法可以大幅度提高客户端使用网络业务时的网络稳定性，保证其每次的接入节点均具备低的延迟。

在可选的实施例中，所述资源获取请求还包括客户端的网络运营商信息；S32，按照与所述IP地址归属地距离由近到远的顺序，对所述可用资源节点进行排序，包括：

S40，判断所述客户端与所述资源节点是否使用相同的网络运行商；若不是，将客户端与资源节点之间的实际距离加上预设的调整值，作为用于排序的距离。

鉴于不同网络运行商之间的通信与同于网络运营商之间的通信相比，存在延迟高的问题，因此在向客户端分配资源节点时，应当优先考虑同一网络运营商提供的资源节点。

在一些可选方案中，可以另行设置专门的参数，用于标记客户端的网络运营商，以及资源节点的网络运营商，在对资源节点进行排序时，将不同网络运营商的资源节点排后。

本实施例则延续距离判定的想法，进一步将对网络运营商的判断加入了距离判断中，即将不同网络运营商提供的资源节点视为距离较远的、相同网络运营商提供的资源节点，使判定标准统一。上述调整值可以根据具体的参数进行确定，例如，相同网络运行商提供的资源节点A的延迟为100ms，距离为500km；不同网络运行商提供的资源节点B的延迟为100ms，距离为300km，则在判定时，可以将所述调整值设置为200km。当然这仅是一个例子，具体计算应当采用更加缜密的统计和计算进行确定。

在可选的实施例中，S31，获取全部资源节点的资源使用状态，包括：

S50，定时接收由资源节点发送的资源使用状态，将最新接收到该节点的资源使用状态保存为资源使用表。

S51，需要获取节点的使用状态时，将所述资源使用表中记录的节点的资源使用状态作为该节点当前的资源使用状态。

上述步骤S50-S51提供了一种进一步降低客户端选择资源节点时的延迟的方法。现有技术中检测某一节点延迟，通常采用向该节点发送一条消息并接收其回复，计算发送消息到接收到回复之间的时间差作为延迟。但是作为资源节点分配方法而言，资源节点的数量较多，若在接收到客户端请求后依次获取每个资源节点与客户端之间的网络延迟和资源剩余量，势必会耗费较多的时间，体现在客户端侧则是网络接入时间长，等待时间长。因此，本实施例定期获取资源节点的状态并保存为资源使用表，由于资源使用表内的记录是定时更新的，在客户端请求资源时资源使用表内的记录具备时效性，可以直接使用而无需再次向各个资源节点发送请求，可以大幅度降低客户端接入耗时。

图3为本公开提供的一种资源调度方法的可选实施例的流程示意图。如图所示，在可选的实施例中，S10，获取客户端发送的资源获取请求后，包括：

S60，判断登陆所述客户端的用户是否为定制用户；若是，执行步骤S61；若否，执行步骤S11。

S61，从预设的定制列表中获取多个备选资源节点。

S62，获取所述备选资源节点的资源使用状态，选择可用的资源节点。

S63，从所述可用资源节点中选取有资源剩余的资源节点分配给所述客户端。

在本实施例中，对登陆客户端的用户类型进一步进行区分：普通用户和定制用户。对于定制用户而言，已经预先在服务商处确定了接入状况较为优良的一些节点。在执行资源节点分配时，优选从这些节点中选取可用节点执行接入。

在可选的实施方式中，所述备选资源节点中任一资源节点不可用时，按照步骤S14的方法，选择另一节点作为备选资源节点加入选择范围。

相对于上述实施例，本实施例更具有针对性。对于普通用户而言，其接入网络的IP、运营商、和地理位置都是可能发生改变的，因此在每次接入时执行判断是相对合理的方式；而对于接入IP和网络状态稳定的用户，例如企业用户等，选择相对固定的几个节点进行连接无疑具备较好的稳定性和连接速度。本实施例的方法延续这个思路，将用户进行划分，使用定制业务的用户可以获取相对稳定和高速的节点接入服务。

图4为本公开提供的一种资源调度方法及服务器的实施例的模块示意图。如图所示，本公开提供的一种资源调度服务器的实施例，包括：

网络单元70，用于获取客户端发送的资源获取请求；

历史记录单元71，用于获取所述客户端的资源节点分配历史记录；

资源分配单元72，用于根据所述客户端的资源节点分配历史记录判断所述客户端参与资源节点分配的次数是否达到预设的次数阈值M；若达到，从客户端最近N次分配到的资源节点中选择可用的资源节点分配给所述客户端；若未达到，从全部资源节点中选择可用的资源节点分配给所述客户端；M，N为正整数。

在可选的实施例中，所述资源分配单元包括：

第一分配模块73，用于获取所述客户端最近N次分配到的资源节点的资源使用状态，选择可用的资源节点；统计每个可用资源节点的分配次数；按照分配次数由高到低的顺序，对所述可用资源节点进行排序；所述第一分配模块73还用于按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端。

在可选的实施例中，所述资源获取请求包括客户端IP地址；所述资源分配单元包括：

第二分配模块74，用于解析所述客户端IP地址，得到IP地址归属地；获取全部资源节点的资源使用状态，选择可用的资源节点；按照与所述IP地址归属地距离由近到远的顺序，对所述可用资源节点进行排序；所述第二分配模块74还用于按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端。

在可选的实施例中，所述资源获取请求还包括客户端的网络运营商信息；所述第二分配模块73还用于判断所述客户端与所述资源节点是否使用相同的网络运行商；若不是，将客户端与资源节点之间的实际距离加上预设的调整值，作为用于排序的距离。

在可选的实施例中，所述历史记录单元71用于定时接收由资源节点发送的资源使用状态，将最新接收到该节点的资源使用状态保存为资源使用表；需要获取节点的使用状态时，所述历史记录单元71用于将所述资源使用表中记录的节点的资源使用状态作为该节点当前的资源使用状态。

在可选的实施例中，所述资源分配单元72还包括：

定制模块75，响应于登陆所述客户端的用户是定制用户，所述定制模块75从预设的定制列表中获取多个备选资源节点；所述定制模块75还用于获取所述备选资源节点的资源使用状态，选择可用的资源节点；从所述可用资源节点中选取有资源剩余的资源节点分配给所述客户端。

从上面所述可以看出，本公开实施例提供的一种资源调度方法及服务器在对客户端进行资源分配时，根据客户端的资源节点分配的历史记录向客户端分配资源节点，提高了资源节点分配速度；根据客户端IP地址归属地选取距离较近的可用资源节点，增强了网络连通性和数据传输速度。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本发明的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本发明的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本发明难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本发明难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本发明的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本发明的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本发明。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本发明的具体实施例对本发明进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本发明的实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本发明的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种资源调度方法，包括：

获取客户端发送的资源获取请求；

获取所述客户端的资源节点分配历史记录；

根据所述客户端的资源节点分配历史记录判断所述客户端参与资源节点分配的次数是否达到预设的次数阈值M；若达到，从客户端最近N次分配到的资源节点中选择可用的资源节点分配给所述客户端；若未达到，从全部资源节点中选择可用的资源节点分配给所述客户端；M和N为正整数。

2.根据权利要求1所述的方法，所述从客户端最近N次分配到的资源节点中选择可用的资源节点分配给所述客户端，包括：

获取所述客户端最近N次分配到的资源节点的资源使用状态，选择可用的资源节点；

统计每个可用资源节点的分配次数；

按照分配次数由高到低的顺序，对所述可用资源节点进行排序；

按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端。

3.根据权利要求1所述的方法，所述资源获取请求包括客户端IP地址；所述从全部资源节点中选择可用的资源节点分配给所述客户端，包括：

解析所述客户端IP地址，得到IP地址归属地；

获取全部资源节点的资源使用状态，选择可用的资源节点；

按照与所述IP地址归属地距离由近到远的顺序，对所述可用资源节点进行排序；

按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端。

4.根据权利要求3所述的方法，所述资源获取请求还包括客户端的网络运营商信息；所述按照与所述IP地址归属地距离由近到远的顺序，对所述可用资源节点进行排序，包括：

判断所述客户端与所述资源节点是否使用相同的网络运行商；若不是，将客户端与资源节点之间的实际距离加上预设的调整值，作为用于排序的距离。

5.根据权利要求3所述的方法，所述获取全部资源节点的资源使用状态，包括：

定时接收由资源节点发送的资源使用状态，将最新接收到该节点的资源使用状态保存为资源使用表；

需要获取节点的使用状态时，将所述资源使用表中记录的节点的资源使用状态作为该节点当前的资源使用状态。

6.根据权利要求1所述的方法，所述获取客户端发送的资源获取请求后，包括：

判断所述登陆所述客户端的用户是否为定制用户；若是，从预设的定制列表中获取多个备选资源节点；

获取所述备选资源节点的资源使用状态，选择可用的资源节点；

从所述可用资源节点中选取有资源剩余的资源节点分配给所述客户端。

7.一种资源调度服务器，包括：

网络单元，用于获取客户端发送的资源获取请求；

历史记录单元，用于获取所述客户端的资源节点分配历史记录；

资源分配单元，用于根据所述客户端的资源节点分配历史记录判断所述客户端参与资源节点分配的次数是否达到预设的次数阈值M；若达到，从客户端最近N次分配到的资源节点中选择可用的资源节点分配给所述客户端；若未达到，从全部资源节点中选择可用的资源节点分配给所述客户端；M和N为正整数。

8.根据权利要求7所述的服务器，所述资源分配单元包括：

第一分配模块，用于获取所述客户端最近N次分配到的资源节点的资源使用状态，选择可用的资源节点；统计每个可用资源节点的分配次数；按照分配次数由高到低的顺序，对所述可用资源节点进行排序；所述第一分配模块还用于按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端。

9.根据权利要求7所述的服务器，所述资源获取请求包括客户端IP地址；所述资源分配单元包括：

第二分配模块，用于解析所述客户端IP地址，得到IP地址归属地；获取全部资源节点的资源使用状态，选择可用的资源节点；按照与所述IP地址归属地距离由近到远的顺序，对所述可用资源节点进行排序；所述第二分配模块还用于按照排序结果依次判断所述可用资源节点是否有资源剩余；若是，将该资源节点分配给所述客户端。

10.根据权利要求9所述的服务器，所述资源获取请求还包括客户端的网络运营商信息；所述第二分配模块还用于判断所述客户端与所述资源节点是否使用相同的网络运行商；若不是，将客户端与资源节点之间的实际距离加上预设的调整值，作为用于排序的距离。

11.根据权利要求9所述的服务器，所述历史记录单元用于定时接收由资源节点发送的资源使用状态，将最新接收到该节点的资源使用状态保存为资源使用表；需要获取节点的使用状态时，所述历史记录单元用于将所述资源使用表中记录的节点的资源使用状态作为该节点当前的资源使用状态。

12.根据权利要求7所述的服务器，所述资源分配单元包括：

定制模块，响应于登陆所述客户端的用户是定制用户，所述定制模块从预设的定制列表中获取多个备选资源节点；所述定制模块还用于获取所述备选资源节点的资源使用状态，选择可用的资源节点；从所述可用资源节点中选取有资源剩余的资源节点分配给所述客户端。