资源分配方法、资源管理器、资源服务器及系统

摘要

本申请涉及一种资源分配方法、资源管理器、资源服务器及系统，所述方法包括：管理器接收资源组中的资源发送的注册信息，所述注册信息中携带有资源的版本号和资源标识；根据所述注册信息，判断所述资源组中是否有资源变更；如果所述资源组中有资源变更，则生成新版本号，并发送所述新版本号到所述资源组中的资源，用以所述资源将版本号更新为所述新版本号；判断接收到的所述注册信息中是否存在与所述新版本号不相同的版本号，如果否，则将该与所述新版本号相同的资源作为可用资源。本申请能够将任务在资源组内的进行合理的动态分配，不需要依赖数据库，避免出现任务处理延迟的情况。

说明书

技术领域

本申请涉及计算机技术领域，尤其涉及一种资源分配方法、资源管理器、 资源服务器及系统。

背景技术

本申请中的资源是指能够提供某种特定业务处理能力的设备或程序，例 如一台应用服务器或者一个线程等。在处理大数据量的业务场景中，单个线 程甚至单台服务器的处理能力都是有限的，无法满足数据处理速度的要求， 因此在这种场景中，往往需要引入多台服务器，共同处理同一个任务。

资源组是具备同一个业务处理功能的一组资源集合，同一资源集合内的 资源具有相同或不同的业务处理能力，并可以分布式的部署方式构成分布式 系统。分布式系统以全局方式管理系统资源，可以为用户任意调度系统内的 资源。当用户提交一个作业时，分布式系统能够根据需要选择合适的执行资 源数及用于执行任务的资源，将用户的作业提交到该些资源，在处理器完成 作业后，将结果传给用户。资源版本是用于分布式系统协调资源组内各个资 源之间就绪状态的标志位，只有资源组内所有的资源版本一致时，资源组变 更才结束，此时才能重新分配任务，否则仍需按资源组变化前的分配情况进 行执行。

现有的分布式资源分配方法是通过将任务按一定维度切割成更细粒度的 子任务，并存储于数据库的任务配置表中，然后由资源组中每个资源服务器 通过对数据库中子任务记录进行抢占式读取，若读取成功则该子任务属于本 资源处理，否则为其它资源处理，并每隔一定时常更新自己负责的子任务的 记录的状态，确保该子任务不被其它资源读取，若超过一定时长记录未被更 新，则认为原先负责处理该子任务的资源出现异常或者已经推出资源组，该 子任务可以被其它资源组内的资源处理。

由于现有的分布式资源分配方法是基于数据库存储的进行的，出于性能 的考虑，需要引入一个子任务持有时间超时的概念，以减少对数据库的访 问频率，但也因此带来了任务调度延迟的问题，尤其是在新增资源或出现 下线资源时，不能动态调整任务的分配，导致处理延时。例如原有资源组 内由三个资源共同负责处理一个任务，每个资源负责其中的三分之一，在 某个时刻，其中一个资源异常退出资源组，在这种情况下，该资源原先持 有的子任务将不在资源组的处理范围内，直到其持有时间超时而被其它两 个资源重新分配为止，因此会导致任务调度延迟的情况。

发明内容

本申请的目的是，提供一种资源分配方法、资源管理器、资源服务器及 系统，将实际可用资源组信息推送至每个资源，确保每个资源均可获得整 个资源组的信息，将任务在资源组内的进行合理的动态分配，不需要依赖 数据库，避免出现任务处理延迟的情况。

为实现上述目的，本申请提供了一种资源分配方法，所述方法包括：

管理器接收资源组中的资源发送的注册信息，所述注册信息中携带有资 源的版本号和资源标识；

根据所述注册信息，判断所述资源组中是否有资源变更；

如果所述资源组中有资源变更，则生成新版本号，并发送所述新版本号 到所述资源组中的资源，用以所述资源将版本号更新为所述新版本号；

判断接收到的所述注册信息中是否存在与所述新版本号不相同的版本 号，如果否，则将该与所述新版本号相同的资源作为可用资源。

又一方面，本申请还提供了一种资源分配方法，所述方法包括：

当前资源接收资源组的管理器发送的新版本号；

判断所述当前资源的版本号是否与所述新版本号相同，如果是，则将所 述当前资源作为可用资源，否则，将所述当前资源的版本号更新为所述新版 本号；

发送注册信息至所述管理器，所述注册信息中携带有所述当前资源的版 本号和资源标识。

再一方面，本申请还提供了一种资源分配方法，所述方法包括：

接收资源组中的资源发送的注册信息，所述注册信息中携带有资源的版 本号和资源标识；

根据所述注册信息，判断所述资源组中是否有资源变更，如果有，则更 新所述资源组的资源列表，并将更新后的资源列表发送给所述资源组中各个 资源，用以所述资源组中各个资源更新版本号；

判断所述资源组中各个资源的版本号是否一致，如果一致，则将所述资 源组中的资源作为可用资源。

再一方面，本申请还提供了一种资源分配方法，所述方法包括：

发送注册信息至管理器，所述注册信息中携带有资源的版本号和资源标 识，用以所述管理器更新所述资源组的资源列表；

接收所述管理器发送的资源列表；

判断所接收到的资源列表与上一次接收到的资源列表是否相同，如果不 相同，则更新自身的版本号；

发送新的注册信息至所述管理器，所述新的注册信息中携带有更新后的 版本号，用以所述管理器在判断到所述资源组中各个资源的版本号一致时， 将所述资源组中的资源作为可用资源。

再一方面，本申请还提供了一种资源分配方法，所述方法包括：

管理器接收资源组中的资源发送的注册信息，所述注册信息中携带有资 源的版本号和资源标识；

所述管理器根据所述注册信息，判断所述资源组中是否有资源变更，如 果有，则更新所述资源组的资源列表，并将更新后的资源列表发送给所述资 源组中各个资源；

所述资源组中各个资源判断所接收到的资源列表与上一次接收到的资源 列表是否相同，如果不相同，则更新自身的版本号，并发送新的注册信息至 所述管理器，所述新的注册信息中携带有更新后的版本号；

所述管理器判断所述资源组中各个资源的版本号是否一致，如果一致， 则将所述资源组中的资源作为可用资源。

再一方面，本申请还提供了一种资源管理器，所述管理器包括：

第一接收单元，用于接收资源组中的资源发送的注册信息，所述注册信 息中携带有资源的版本号和资源标识；

第一判断单元，用于根据所述注册信息，判断所述资源组中是否有资源 变更，如果所述资源组中有资源变更，则触发第一更新单元；

第一更新单元，用于在受到所述第一判断单元的触发时，生成新版本号， 并发送所述新版本号到所述资源组中的资源；

第二判断单元，用于判断所述第一接收单元接收到的所述注册信息中是 否存在与所述新版本号不相同的版本号，如果否，则触发第一处理单元；

第一处理单元，用于在受到所述第二判断单元的触发时，将所述注册信 息中与所述新版本号相同的资源作为可用资源。

再一方面，本申请还提供了一种资源服务器，所述服务器包括：

第一获取单元，用于接收资源组的管理器发送的新版本号；

版本控制单元，用于判断所述当前资源的版本号是否与所述新版本号相 同，如果是，则标识为可用资源，否则，将所述当前资源的版本号更新为所 述新版本号；

注册单元，用于发送注册信息至所述管理器，所述注册信息中携带有所 述当前资源的版本号和资源标识。

再一方面，本申请还提供了一种资源管理器，所述管理器包括：

第二接收单元，用于接收资源组中的资源发送的注册信息，所述注册信 息中携带有资源的版本号和资源标识；

第三判断单元，用于根据所述注册信息，判断所述资源组中是否有资源 变更，如果有，则更新所述资源组的资源列表，并将更新后的资源列表发送 给所述资源组中各个资源，用以所述资源组中各个资源更新版本号；

第四判断单元，用于判断所述资源组中各个资源的版本号是否一致，如 果一致，则将所述资源组中的资源作为可用资源。

再一方面，本申请还提供了一种资源服务器，所述服务器包括：

注册单元，用于发送注册信息至管理器，所述注册信息中携带有资源的 版本号和资源标识，用以所述管理器更新所述资源组的资源列表；

第二获取单元，用于接收所述管理器发送的资源列表；

版本变更单元，用于判断所述第二获取单元接收到的资源列表与上一次 接收到的资源列表是否相同，如果不相同，则更新自身的版本号，并触发所 述注册单元发送新的注册信息至所述管理器，所述新的注册信息中携带有更 新后的版本号。

再一方面，本申请还提供了一种资源系统，所述系统包括：

本申请实施例提供的分布式资源管理器；

至少一个本申请实施例提供的分布式资源服务器；

所述各个服务器与所述管理器相连接。

本申请提供的资源分配方法、资源管理器、资源服务器及系统，通过分 布式协调系统管理资源组内实际可用资源的信息，确保每个资源均可获得 整个资源组的信息，同时依据任务分配策略计算得出各个资源实际处理的 任务范围，可以将任务在资源组内的进行合理的动态分配，不需要依赖数 据库，避免出现任务处理延迟的情况。

附图说明

图1为本申请实施例一提供的资源分配方法流程图；

图2为本申请实施例一提供的将待执行任务分配给可用资源的流程图；

图3为本申请实施例二提供的资源分配方法流程图；

图4为本申请实施例三提供的资源分配方法流程图；

图5为本申请实施例四提供的分布式资源系统的示意图；

图6为本申请实施例四提供的资源管理器的示意图；

图7为本申请实施例四提供的资源服务器的示意图；

图8为本申请实施例五提供的资源管理器的示意图；

图9为本申请实施例五提供的资源服务器的示意图。

具体实施方式

下面通过附图和实施例，对本申请的技术方案做进一步的详细描述。

分布式资源系统是一组具备业务处理能力的资源集合。一个分布式资源 系统包括一个管理器和多个资源，通常以其中一个装有分布式协调系统软件 （如Zookeeper等）的资源作为管理器，用以协调和管理整个资源组。 Zookeeper是一种常用的分布式应用程序协调系统，是开源的分布式计算平台 Hadoop中的一个子项目，是一个针对大型分布式系统的可靠的协调系统，应 用于提供一致性服务的软件。本申请以基于Zookeeper为协调系统的资源作 为管理器实现分布式资源分配为例进行说明。

本申请提供的资源分配方法、资源管理器、资源服务器及系统，可用于 分布式异步调度处理的应用场景。例如，在B2C（Business to Consumer，商 家对消费者）、C2C（Consumer to Consumer，消费者对消费者）等类型的电 子商务网站中，每天都会有大量的订单产生。系统在处理订单交易时主要是 对生成订单的主流程进行处理，包括每个订单的执行事件，如客户下单或支 付款项等操作。对于订单产生后的非核心的业务流程，如监控订单的数据、 日志统计、订单打标等，系统并不会在进行主流程处理时进行一并处理。然 而，通过对订单的分类统计，系统可以分析到一些有用的信息。因此，系统 通常需要在后台通过异步调度的方式进行处理这部分的业务任务。这种异步 调度的处理方式，可以灵活地选择业务处理的时间，避免占用主流程同步的 处理资源，导致系统处理主流程时负担较大，可以有效地减轻系统压力。

本申请以上述订单业务的异步调度处理的应用场景为例进行说明，所属 领域技术人员应当理解，本申请的具体应用场景还可以包括其他分布式异步 处理的场景，并不以此限制本申请。

实施例一

图1是本实施例提供的资源分配方法流程图，如图1所示，本申请的资 源分配方法包括：

步骤S101、管理器接收资源组中的资源发送的注册信息。

当资源组中有资源向管理器发送注册信息时，管理器接收所述注册信息。

其中，所述注册信息中携带有资源的版本号和资源的资源标识。所述资 源的资源标识可以是IP地址、帐号等。

资源组中各个资源以当前版本号向管理器注册自己。如果是新增资源， 则可以在初始化后，以0为当前版本号向管理器注册自己，管理器收到0版 本号的注册信息。如果某一资源下线，则无法再发送版本号，管理器不能收 到该资源的注册信息。

步骤S102、管理器根据所述注册信息，判断所述资源组中是否有资源变 更，如果是，则进入步骤S103，否则进入步骤S107。

具体地，管理器通过各个资源的注册信息的资源标识，即可判断资源组 中是否有新增资源或下线资源，一旦资源组中存在新增或下线的资源标识时， 则判断为所述资源组中有资源变更。

步骤S103、管理器生成新版本号，并发送所述新版本号到所述资源组中 的资源。

当有资源变更时，管理器根据资源组中各个资源的注册信息，生成新版 本号。对于版本号递增的资源组，通常将资源组中最大的资源版本号加1作 为新版本号。此时整个资源组中的资源都需要进行版本号更新，管理器将新 版本号发送到资源组中的资源。

资源组中的资源在接收到新版本号时，判断资源的当前版本号是否与所 述新版本号相同，如果不相同，则将该资源的当前版本号更新为所述新版本 号。变更后，资源将携带有新版本号的注册信息发送给管理器，管理器则接 收各资源发送的更新后的注册信息。

步骤S104、判断接收到的所述注册信息中是否存在与所述新版本号不相 同的资源的版本号，如果是，则进入步骤S105，发送所述新版本号至所述与 新版本号不相同的资源，如果否，则进入步骤S106，将该些与所述新版本号 相同的资源作为可用资源。

具体地，注册信息包括资源组中资源在接收到所述新版本号，并将版本 号更新为所述新版本号后发送的注册信息。

需要说明的是，由于管理器与资源组中的资源之间保持实时的交互状态， 当资源更新完版本号后，即发送新的注册信息给管理器进行注册，新的注册 信息中携带有新版本号，此时管理器则可接收到该资源发送的新的注册信息。

步骤S107、判断所述资源组中各资源的版本号是否一致，如果一致，则 进入步骤S108，将所述资源组的待执行任务分配给所述可用资源。如果不一 致，则进入步骤S109。

对于大数据量的实时处理的业务场景，基本上都采用分批次循环处理的 方式，将所需要处理的业务分成多个批次进行任务处理，并利用资源的版本 号表示任务处理的批次。由于任务处理需要消耗时间，所以每次资源组发生 变更后，需要等待当前批次任务尚未执行完毕的资源全部执行完毕后，才能 重新分配任务，否则可能会导致部分数据被重复处理。因而，在当前批次任 务处理完成后，不会直接开始下一个批次的任务处理，而是等待其它资源完 成处理，在完成重新分配任务后，再开始下一个批次的任务处理。

因此，在进行分配任务前，先判断资源组中各个资源的版本号是否一致， 如果不一致，则需要等待资源组中各资源统一版本号，进行步骤S109。当资 源组中各个资源的版本号一致时，将待执行任务分配给各个可用资源。

步骤S109、将所述资源组中资源的最新的版本号确定为新版本号，并将 所述新版本号发送至所述资源组中的资源，返回步骤S104。

其中，最新的版本号通常为资源组中完成了前一批次任务的资源的版本 号，例如对于版本号递增的资源组，通常为最大的资源版本号。管理器可以 将新版本号发送给整个资源组中的资源，也可以将新版本号发送给注册信息 中与新版本号不同的资源。

资源组中的资源在接收到新版本号时，判断资源的当前版本号是否与所 述新版本号相同，如果相同，则等待所述资源组中与所述新版本号不相同的 资源将版本号更新为所述新版本号。如果不相同，则将该资源的当前版本号 更新为所述新版本号。变更后，资源将携带有新版本号的注册信息发送给管 理器，管理器则接收各资源发送的更新后的注册信息。

图2是本实施例提供的将待执行任务分配给可用资源的流程图，如图2 所示，具体包括：

步骤S201、管理器获得所述资源组的待执行任务，确定需要的执行资源 数A。

所述执行资源数A可以根据以往经验或实际应用情况，设定一个执行资 源数A。例如，根据以往经验可以评估出待执行任务所需要的资源数，或者， 当实际情况监测到资源使用的性能不能满足待执行任务时，可适当增加执行 资源数。

管理器可以先根据预定义规则划分所述待执行任务，用以细分待执行任 务，以便均衡地将待执行任务分配给对应的资源。所述预定义规则可以但不 限于采用取模运算的方式。

以订单的日志统计的这一业务任务来说，具体是要从多个维度对订单数 据进行分类统计，包括对订单数量按照付款类型（如货到付款、普通付款） 等分类进行数量统计。在进行任务细分时，具体为：以订单号为准，将订单 统计任务分成256组（通常为2的n次方），所采用的取模运算方法具体为： 将订单号除以256后取余数作为该订单号的所述分类号码，这样可以将待执 行任务细分为256组子任务。由于订单号通常为连续的编号，所得到的256 组中包含的子任务数的个数也较为平均，使得被分配到任务的资源进行任务 处理所需的时间也较为平均，有利于减少整个资源组的协调时间。

由于管理器设置的执行资源数A与资源组中总资源数S不一定相等，设 置的执行资源数A有可能超出总资源数S，也有可能不需要所有资源都进行任 务处理，因此，在针对任务进行资源分配时，先进行步骤S202的判断处理。

步骤S202、判断所述执行资源数A是否大于或等于所述可用资源的总资 源数S，如果是，则进入步骤S203，否则，进入步骤S204。

步骤S203、利用整个所述资源组，将所述待执行任务分配到整个所述资 源组。

如果所述执行资源数A大于或等于所述总资源数S，即S≤A，说明待执 行任务所需要的执行资源数较多，则利用整个所述资源组，将所述待执行任 务分配到整个所述资源组。

如果所述执行资源数A小于所述总资源数S，即A<S，则说明资源组中可 用资源数较多，进行步骤S204。

步骤S204、从所述总资源数S中选择A个资源，将所述待执行任务分配 到所述A个资源。

其中，A个资源的选择可以但不限于采用以下方式进行选择，具体包括：

步骤S204_1、获取所述资源组中配置的偏移量L。

所述偏移量L表示执行任务的第一个资源在所述资源组中的序号，可以 是管理器预先定义好的。例如，管理器可以规定在每次重新分配任务时，都 先将偏移量L加1，以平衡整个资源组中的每个资源所需要处理的任务，使得 管理器的任务分配更合理。

步骤S204_2、判断所述执行资源数A与所述资源组中配置一个偏移量L 之和L+A是否小于所述总资源数S，如果是，则进入步骤S204_3，否则进入 步骤S204_4。

步骤S204_3、将所述总资源数S与执行资源数A之差作为实际的偏移量 R，即R=S-A。

也就是说，当总资源数S<L+A，则将所述总资源数S与执行资源数A之差 作为实际的偏移量R，即R=S-A，将任务分配给资源组中的后A个资源。

步骤S204_4、将所述偏移量L作为实际的偏移量R。

也就是说，如果所述总资源数S≥L+A，则将所述偏移量L作为实际的偏 移量R，将任务从预设的偏移量L开始分配。

步骤S204_5、将所述待执行任务分配到所述资源组中从第R个序号开始 的A个资源。

在确定了实际偏移量R之后，管理器则将任务依次分配给资源组中从第R 个序号开始的A个资源。

举个例子，资源组中包括资源K0～K10，当管理器获取当前批次的待执行 任务之后，设定所需要的执行资源数A=4，此时管理器预设的偏移量L=5，可 以判断出L+A=9<总资源数S=11，则此时实际偏移量R=L=5，管理器将任务分 配给资源组中的资源K5-K8这4个资源。当管理器预设的偏移量L=8时，可 以判断出L+A=12<总资源数S=11，则此时确定实际偏移量R=S-A=11-4=7，管 理器将任务分配给资源组中的资源K7～K10这4个资源。

实施例二

图3是本实施例提供的资源分配方法流程图，如图3所示，本申请的资 源分配方法包括：

步骤S301、资源接收资源组的管理器发送的新版本号。

管理器发送的新版本号包括：当所述管理器判断到所述资源组中有资源 变更时生成的新版本号；或者，当所述管理器判断到所述资源组中没有资源 变更时确定的新版本号，所述确定的新版本号为所述资源组中资源的最新的 版本号。

步骤S302、判断所述当前资源的版本号是否与所述新版本号相同，如果 是，则进入步骤S303，否则进入步骤S304。

步骤S303、将所述当前资源作为可用资源。

步骤S304、将所述当前资源的版本号更新为所述新版本号。

资源组中的资源在接收到新版本号时，判断资源的当前版本号是否与所 述新版本号相同，如果相同，则等待所述资源组中与所述新版本号不相同的 资源将版本号更新为所述新版本号。如果不相同，则将该资源的当前版本号 更新为所述新版本号。

步骤S305、发送注册信息至所述管理器，所述注册信息中携带有所述当 前资源的版本号和资源标识。

资源组中的资源在变更版本号后，将携带有新版本号的注册信息发送给 管理器，管理器则接收各资源发送的更新后的注册信息。

管理器根据注册信息，判断所述资源组中是否有资源变更。当所述资源 组中存在新增或下线的资源标识时，判断为所述资源组中有资源变更。如果 有变更，则生成新版本号，用以所述资源更新版本号。如果没有变更，则判 断所述资源组中的资源的版本号是否一致，如果是，则执行将所述资源组的 待执行任务分配给所述可用资源，否则，等待所述资源组中与所述新版本号 不相同的资源将版本号更新为所述新版本号。

步骤S306、接收所述管理器分配的待执行任务，当接收到所述待执行任 务时，进行对应的待执行任务的处理。

由于任务处理需要消耗时间，在每次资源组发生变更后，需要等待当前 批次任务尚未执行完毕的其他资源全部执行完毕后，才能重新分配任务，以 免导致部分数据被重复处理。

当管理器判断到资源组中资源的版本号一致时，则将待执行任务分配给 各个资源。此时，各个资源才能接收到管理器分配的任务。当接收到所述待 执行任务时，进行对应的待执行任务的处理。

实施例三

管理器可以但不限于采用资源列表的形式，对资源组中的资源进行管理， 资源列表为各个资源的资源标识列表。在管理器中管理的资源信息包括：各 个资源的资源标识列表及版本号等信息。

图4是本实施例提供的资源分配方法流程图，如图4所示，本申请的资 源分配方法包括：

步骤S401、管理器接收资源组中的资源发送的注册信息。

当资源组中资源的版本号出现变更或进行初始化时，发送注册信息至资 源组的管理器进行注册。所述注册信息中携带有资源的版本号和资源标识。

资源以当前版本号向管理器注册自己，如果资源是新增资源，则以0为 当前版本号向管理器注册自己，管理器将收到0版本号的注册信息。如果资 源下线，则无法再发送版本号，管理器不能收到该资源的注册信息。

步骤S402、管理器根据所述注册信息，判断所述资源组中是否有资源变 更，如果有，则进入步骤S403，否则，进入步骤S406。

步骤S403、管理器更新所述资源组的资源列表，并将更新后的资源列表 发送给所述资源组中各个资源。

当管理器接收到各个资源的注册信息时，则根据该些注册信息，判断资 源组中是否有新增或下线的资源标识。当管理器判断到资源列表中有新增或 减少的资源标识时，表明资源组有资源变更，则更新所述资源组的资源列表。

当判断到资源组中没有资源变更时，则不更新资源列表。此时，可选地， 可将原有的资源列表仍发送至各个资源。

步骤S404、资源组中各个资源判断所接收到的资源列表与上一次接收到 的资源列表是否相同，如果不相同，则进入步骤S405，如果相同，则进入步 骤S406。

步骤S405、资源更新自身的版本号，并发送新的注册信息至所述管理器， 所述新的注册信息中携带有更新后的版本号。

如果有资源发生变更，资源列表中的各个资源接收到新的资源列表，判 断到与上一次接收的资源列表不同，表明资源组中有新增或下线的资源，则 将版本号更新为新版本号，并将更新后的版本号发送至管理器进行重新注册， 返回步骤S401。

资源在更新自身的版本号之前，还包括：判断所述资源是否执行完当前 批次的任务，如果是，则进行更新自身的版本号，否则继续执行当前批次的 任务，暂时不会更新版本号待到完成任务后，再将版本号更新为新版本号。

如果没有资源发生变更，资源列表中的各个资源接收的资源列表未发生 变更，各个资源的版本号不进行统一变更。

步骤S406、管理器判断所述资源组中各个资源的版本号是否一致，如果 一致，则进入步骤S407，将所述资源组中的资源作为可用资源，否则进入步 骤S408，将与所述资源组中最新的版本号不同的资源作为待同步资源，形成 待同步资源列表发送给所述资源组中各个资源。

管理器根据各资源重新注册的注册信息，形成新的资源列表，并判断资 源列表中各个资源的版本号是否一致。当判断到资源列表中版本号一致时， 则将该些版本号相同的资源作为可用资源，形成可用资源列表。如果不一致， 则进入步骤S408，具体地，可以先找出所述各个资源的版本号中最新的版本 号，如最大版本号，再将资源列表中版本号与最大版本号不一致的资源确定 为待同步资源，形成待同步资源列表，发送至资源组中的各个资源，以使得 待同步资源列表中的资源更新版本号至与最大版本号一致。

步骤S409、所述资源组中各个资源判断自身是否在所述待同步资源列表 中，如果是，则进入步骤S410。

步骤S410、资源将自身的版本号更新为所述资源组中最新的版本号，并 发送新的注册信息至所述管理器，新的注册信息中携带有更新后的版本号。

资源组中各个资源在将自身的版本号更新为所述资源组中最新的版本号 之前，还包括：判断所述资源是否执行完当前批次的任务，如果是，则进行 更新自身的版本号，否则继续执行当前批次的任务，暂时不会更新版本号待 到完成任务后，再将版本号更新为新版本号。

步骤S411、管理器将所述资源组的待执行任务分配给所述可用资源。

将待执行任务分配给资源组中的资源的具体步骤与实施例一中的相同， 于此不再赘述。

步骤S412、资源中的资源接收所述管理器分配的待执行任务，当接收到 所述待执行任务时，进行对应的待执行任务的处理。

由于任务处理需要消耗时间，在每次资源组发生变更后，需要等待当前 批次任务尚未执行完毕的其他资源全部执行完毕后，才能重新分配任务，以 免导致部分数据被重复处理。当管理器判断到资源列表中资源的版本号一致 时，则将待执行任务分配给各个资源。此时，各个资源才能接收到管理器分 配的任务。具体地，包括以下步骤：

步骤S412_1、获取所述管理器发送的执行资源列表。

管理器根据预定义规则划分所述待执行任务，设置执行资源数A，并确定 资源组中的A个资源，形成执行资源列表发送给资源组中各个资源。

步骤S412_2、判断当前资源是否在所述执行资源列表中，如果是，则进 入步骤S412_3，否则，等待获取管理器发送的资源列表。

步骤S412_3、获取所述当前资源在所述执行资源列表中的序号。

步骤S412_4、根据所述序号从所述管理器中获取对应的待执行任务，进 行本批次的待执行任务的处理。

具体地，先利用所述管理器预先定义的子任务组数N，计算所述执行资源 列表的A个资源中平均每个资源应负责的子任务数AN，将所述待执行任务的 N组子任务划分成A个区间。再根据所述当前资源的序号I N，获取对应第IN 个区间的所述子任务。

举个例子，对于资源组中各个资源K0～K10均可获取到管理器发送的执 行资源列表，具体为K5～K8，对应序号1,2,3,4。如果当前资源为K0，可以 判断到自身并不在所述待同步资源列表中，则表明该资源K0没有被分配到任 务，无需处理任何实际任务，则等待下一批次任务的分配。如果当前资源为 K5，则可以判断到自身在所述待同步资源列表中，则表明该资源K5被分配到 任务，需要执行实际任务。获取得到资源K5在执行资源列表中的序号为1， 则表明获取第一区间的子任务。假设待执行任务的子任务组数N=17，计算得 到4个资源平均每个资源应负责的子任务组数AN=4.25，分成4个区间，每个 区间的子任务组数分别为4,4,4,5。针对于资源K5的序号为1，则获取第1 个区间的4组子任务。

本申请的分布式资源组可同时用于多个业务任务的执行，每一个业务任 务也可分派给由不同资源组成的资源组。针对不同批次的业务任务，通过不 同的版本号加以区分，每一个业务任务可以有自己的编码方式，例如可以任 务的名称或代号+序号的版本号形式。一个资源可以同时执行多个任务，即可 以有多个版本号。一个资源组可能有部分资源被分配到当前批次的任务，也 可能没有被分配到，因此，可能会造成资源列表中版本号不一致的情况。因 而，在进行资源分配之前，需要将资源组中的资源的版本号协调到一致。

当判断到资源列表中的版本号一致，则将所述资源列表作为可用资源列 表，并将所述资源组的待执行任务分配给所述可用资源列表中的资源。

举个例子，假设某一分布式资源组中包括10个资源K0～K9，用以共同处 理第n批次的任务，资源K0～K9的版本号为N，此时,新增加了一个资源K10， 该资源K10以0版本向管理器注册自己，管理器收到资源K10的注册信息后， 更新资源列表，并将更新后的资源列表发送至资源K0～K10的每一个资源。 当资源K0～K10接收到更新后的资源列表后，将该资源列表与原来的资源列 表相比，可以判断出新接收到的资源列表发生了变更，则先将版本号变更为 N+1，并将更新后的版本号发送至管理器重新注册，管理器在没有新增资源或 下线资源的情况下，不更新资源列表，根据资源组中最大的资源版本号确定 为新版本号，将版本号与该新版本号不同的资源形成待同步资源列表，仅更 新待同步资源列表中资源的版本号。当资源组内的各个资源的版本号一致时， 管理器将待执行任务分配给资源组中的资源。

以上是对本申请所提供的资源分配方法进行的详细描述，下面对本申请 提供的资源分配装置和系统进行详细描述。

实施例四

图5是本实施例提供的分布式资源系统的结构示意图，如图5所示，本 申请的分布式资源系统包括管理器10及至少一个资源服务器20，各个资源服 务器20通过总线与管理器10相连接。

图6是本实施例提供的资源管理器的示意图，如图6所示，本申请的资 源管理器包括：第一接收单元11、第一判断单元12、第一更新单元13、第二 判断单元14、第一处理单元15、第一发送单元16、第二处理单元17和第二 发送单元18。

第一接收单元11用于接收资源组中的资源发送的注册信息。

当资源组中有资源向管理器发送注册信息时，管理器的第一接收单元11 接收所述注册信息。

其中，所述注册信息中携带有资源的版本号和资源的资源标识。所述资 源的资源标识可以是IP地址、帐号等。

第一判断单元12用于根据所述注册信息，判断所述资源组中是否有资源 变更，如果所述资源组中有资源变更，则触发第一更新单元13。

具体地，第一判断单元12通过各个资源的注册信息的资源标识，即可判 断资源组中是否有新增资源或下线资源，一旦资源组中存在新增或下线的资 源标识时，则判断为所述资源组中有资源变更。

第一更新单元13用于在受到第一判断单元12的触发时，生成新版本号， 并发送所述新版本号到所述资源组中的资源。

当第一判断单元12判断为有资源变更时，第一更新单元13根据资源组 中各个资源的注册信息，生成新版本号。对于版本号递增的资源组，通常将 资源组中最大的资源版本号加1作为新版本号。此时整个资源组中的资源都 需要进行版本号更新，第一更新单元13将新版本号发送到资源组中的资源。

资源组中的资源在接收到新版本号时，判断资源的当前版本号是否与所 述新版本号相同，如果不相同，则将该资源的当前版本号更新为所述新版本 号。变更后，资源将携带有新版本号的注册信息发送给管理器，管理器则接 收各资源发送的更新后的注册信息。

第二判断单元14用于判断第一接收单元11接收到的所述注册信息中是 否存在与所述新版本号不相同的版本号，如果否，则触发第一处理单元15， 如果是，则触发第二处理单元16。

第一处理单元15用于在受到第二判断单元14的触发时，将所述注册信 息中与所述新版本号相同的资源作为可用资源。

第一发送单元16用于在受到第二判断单元14的触发时，发送所述新版 本号至与所述新版本号不相同的资源。

具体地，第一接收单元11接收到的注册信息包括：资源组中资源在接收 到所述新版本号，并将版本号更新为所述新版本号后发送的注册信息。

需要说明的是，由于管理器与资源组中的资源之间保持实时的交互状态， 当资源更新完版本号后，即发送新的注册信息给管理器进行注册，新的注册 信息中携带有新版本号，此时第一接收单元11则可接收到该资源发送的新的 注册信息。

第二判断单元14还用于判断资源组中各资源的版本号是否一致，如果一 致，则触发第二处理单元17，如果不一致，则触发第二发送单元18。

第二处理单元17用于在受到第二判断单元14的触发时，将所述资源组 的待执行任务分配给所述可用资源。

第二发送单元18用于在受到第二判断单元14的触发时，将所述资源组 中资源的最新的版本号确定为新版本号，并将所述新版本号发送至所述资源 组中的资源。

其中，最新的版本号通常为资源组中完成了前一批次任务的资源的版本 号，例如对于版本号递增的资源组，通常为最大的资源版本号。第二发送单 元18可以将新版本号发送给整个资源组中的资源，也可以将新版本号发送给 注册信息中与新版本号不同的资源。

资源组中的资源在接收到新版本号时，判断资源的当前版本号是否与所 述新版本号相同，如果相同，则等待所述资源组中与所述新版本号不相同的 资源将版本号更新为所述新版本号。如果不相同，则将该资源的当前版本号 更新为所述新版本号。变更后，资源将携带有新版本号的注册信息发送给管 理器，第一接收单元11则接收各资源发送的更新后的注册信息。

第二处理单元17具体包括：任务确定子单元171、第一判断子单元172、 第一分配子单元173和第二分配子单元174。

任务确定子单元171用于获得所述资源组的待执行任务，确定需要的执 行资源数A。

所述执行资源数A可以根据以往经验或实际应用情况，设定一个执行资 源数A。例如，根据以往经验可以评估出待执行任务所需要的资源数，或者， 当实际情况监测到资源使用的性能不能满足待执行任务时，可适当增加执行 资源数。

任务确定子单元171可以先根据预定义规则划分所述待执行任务，用以 细分待执行任务，以便均衡地将待执行任务分配给对应的资源。

第一判断子单元172用于判断所述执行资源数A是否大于或等于所述可 用资源的总资源数S，如果是，则触发第一分配子单元173，否则触发第二分 配子单元174。

第一分配子单元173用于利用整个所述资源组，将所述待执行任务分配 到整个所述资源组。

如果所述执行资源数A大于或等于所述总资源数S，即S≤A，说明待执 行任务所需要的执行资源数较多，第一分配子单元173则利用整个所述资源 组，将所述待执行任务分配到整个所述资源组。

如果所述执行资源数A小于所述总资源数S，即A<S，则说明资源组中可 用资源数较多，则触发第二分配子单元174。

第二分配子单元174用于从所述总资源数S中选择A个资源，将所述待 执行任务分配到所述A个资源。

具体地，第二分配子单元174包括：偏移量获取子单元、偏移量确定子 单元和任务分配子单元（图未示）。

偏移量获取子单元用于获取所述资源组中配置的偏移量L。所述偏移量L 表示执行任务的第一个资源在所述资源组中的序号。

偏移量确定子单元用于判断所述执行资源数A与所述资源组中配置一个 偏移量L之和L+A是否小于所述总资源数S，如果是，则将所述总资源数S与 执行资源数A之差作为实际的偏移量R，即R=S-A，否则，将所述偏移量L作 为实际的偏移量R。

任务分配子单元用于将所述待执行任务分配到所述资源组中从第R个序 号开始的A个资源。

举个例子，资源组中包括资源K0-K10，当任务确定子单元171获取当前 批次的待执行任务之后，设定所需要的执行资源数A=4，此时偏移量获取子单 元获取到预设的偏移量L=5，偏移量确定子单元可以判断出L+A=9<总资源数 S=11，因此，确定实际偏移量R=L=5，任务分配子单元将任务分配给资源组中 的资源K5-K8这4个资源。

图7是本实施例提供的资源服务器的示意图，如图7所示，本申请的资 源服务器包括：注册单元21、第一获取单元22、版本控制单元23、任务接收 单元24和任务处理单元25。

注册单元21用于发送注册信息至所述管理器。

当资源的版本号出现变更或进行初始化时，注册单元21发送注册信息至 资源组的管理器进行注册。

注册信息包括资源服务器的资源标识和版本号，如果是新增资源服务器， 则注册单元21以0为当前版本号向管理器注册自己。如果当前资源服务器下 线，则注册单元21无法再发送注册信息，管理器不能收到该资源服务器的注 册信息。

第一获取单元22用于接收资源组的管理器发送的新版本号。

管理器发送的新版本号包括：当所述管理器判断到所述资源组中有资源 变更时生成的新版本号；或者，当所述管理器判断到所述资源组中没有资源 变更时确定的新版本号，所述确定的新版本号为所述资源组中资源的最新的 版本号。

版本控制单元23用于判断所述当前资源的版本号是否与所述新版本号相 同，如果是，则标识为可用资源，否则，将所述当前资源的版本号更新为所 述新版本号。

在第一获取单元22接收到新版本号时，版本控制单元23判断资源的当 前版本号是否与所述新版本号相同，如果相同，则标识为可用资源，等待所 述资源组中与所述新版本号不相同的资源将版本号更新为所述新版本号。如 果不相同，则将该资源的当前版本号更新为所述新版本号。

在版本控制单元23变更版本号后，注册单元21将携带有新版本号的注 册信息发送给管理器，管理器则接收各资源发送的更新后的注册信息。

任务接收单元24用于接收所述管理器分配的待执行任务。

任务处理单元25用于当任务接收单元24接收到所述待执行任务时，进 行对应的待执行任务的处理。

由于任务处理需要消耗时间，在每次资源组发生变更后，需要等待当前 批次任务尚未执行完毕的其他资源全部执行完毕后，才能重新分配任务，以 免导致部分数据被重复处理。

当管理器判断到资源组中资源的版本号一致时，则将待执行任务分配给 各个资源。此时，各个资源的任务接收单元24才能接收到管理器分配的任务。 当接收到所述待执行任务时，任务处理单元25进行对应的待执行任务的处理。

实施例五

管理器可以但不限于采用资源列表的形式，对资源组中的资源进行管理， 资源列表为各个资源的资源标识列表。在管理器中管理的资源信息包括：各 个资源的资源标识列表及版本号等信息。

图8是本实施例提供的资源管理器的示意图，如图6所示，本申请的资 源管理器包括：第二接收单元31、第三判断单元32、第四判断单元33、第三 处理单元34和第四处理单元35。

第二接收单元31用于接收资源组中的资源发送的注册信息。

当资源组中资源的版本号出现变更或进行初始化时，发送注册信息至资 源组的管理器进行注册。所述注册信息中携带有资源的版本号和资源标识。

资源以当前版本号向管理器注册自己，如果资源是新增资源，则以0为 当前版本号向管理器注册自己，第二接收单元31将收到0版本号的注册信息。 如果资源下线，则无法再发送版本号，第二接收单元31不能收到该资源的注 册信息。

第三判断单元32用于根据所述注册信息，判断所述资源组中是否有资源 变更，如果有，则更新所述资源组的资源列表，并将更新后的资源列表发送 给所述资源组中各个资源，用以所述资源组中各个资源更新版本号。

当第二接收单元31接收到各个资源的注册信息时，则第三判断单元32 根据该些注册信息，判断资源组中是否有新增或下线的资源标识。当第三判 断单元32判断到资源列表中有新增或减少的资源标识时，表明资源组有资源 变更，则更新所述资源组的资源列表。

当第三判断单元32判断到资源组中没有资源变更时，则不更新资源列表。 此时，可选地，可将原有的资源列表仍发送至各个资源。

资源组中各个资源在接收到第三判断单元32发送的资源列表时，判断所 接收到的资源列表与上一次接收到的资源列表是否相同，如果不相同，则更 新自身的版本号，并发送新的注册信息至第二接收单元31。

第四判断单元33用于判断所述资源组中各个资源的版本号是否一致，如 果一致，则将所述资源组中的资源作为可用资源。

当第四判断单元33判断到资源列表中版本号一致时，则将该些版本号相 同的资源作为可用资源，形成可用资源列表。如果不一致，则触发第三处理 单元34。

第三处理单元34用于将所述资源组中最新的版本号不同的资源作为待同 步资源，形成待同步资源列表发送给所述资源组中各个资源。

具体地，第三处理单元34可以先找出所述各个资源的版本号中最新的版 本号，如最大版本号，再将资源列表中版本号与最大版本号不一致的资源确 定为待同步资源，形成待同步资源列表，发送至资源组中的各个资源，以使 得待同步资源列表中的资源更新版本号至与最大版本号一致。

对于大数据量的实时处理的业务场景，基本上都采用分批次循环处理的 方式，将所需要处理的业务分成多个批次进行任务处理，并利用资源服务器 的版本号表示任务处理的批次。由于任务处理需要消耗时间，所以每次资源 组发生变更后，需要等待当前批次任务尚未执行完毕的资源全部执行完毕后， 才能重新分配任务，否则可能会导致部分数据被重复处理。因而，在当前批 次任务处理完成后，不会直接开始下一个批次的任务处理，而是等待其它资 源完成处理，在完成重新分配任务后，再开始下一个批次的任务处理。

因此，在进行分配任务前，需要先将资源组中的版本号协调至一致。第 四判断单元33判断资源列表中各个资源服务器的版本号是否一致，如果不一 致，则触发第三处理单元34，如果一致，则触发第四处理单元35。

第四处理单元35用于将所述资源组的待执行任务分配给所述可用资源。

本单元与实施例四中第二处理单元17的具体配置相同，于此不再赘述。

图9是本实施例提供的资源服务器的示意图，如图9所示，本申请的资 源服务器包括：注册单元41、第二获取单元42、版本变更单元43、任务接收 单元44和任务处理单元45。

注册单元41用于发送注册信息至管理器。

所述注册信息中携带有资源的版本号和资源标识，用以所述管理器更新 所述资源组的资源列表。

第二获取单元42用于接收所述管理器发送的资源列表。

当管理器接收到各个资源的注册信息时，则根据该些注册信息，判断资 源组中是否有新增或下线的资源服务器。如果资源组中有新增或下线的资源 服务器时，则更新所述资源组的资源列表，并将更新后的资源列表发送至各 个资源服务器，否则不更新资源列表，并将原有的资源列表发送至各个资源 服务器。因而，各个资源服务器先通过第二获取单元42获取这些资源列表。

版本变更单元43用于判断所述第二获取单元接收到的资源列表与上一次 接收到的资源列表是否相同，如果不相同，则更新自身的版本号，并触发所 述注册单元发送新的注册信息至所述管理器，所述新的注册信息中携带有更 新后的版本号。

如果有资源发生变更，资源列表中的各个资源的第二获取单元42接收到 新的资源列表，当版本变更单元43判断到与上一次接收的资源列表不同，表 明资源组中有新增或下线的资源，则将版本号更新为新版本号，并触发注册 单元41将更新后的版本号发送至管理器进行重新注册。

版本变更单元43在更新自身的版本号之前，还判断所述资源是否执行完 当前批次的任务，如果是，则进行更新自身的版本号，否则继续执行当前批 次的任务，暂时不会更新版本号待到完成任务后，再将版本号更新为新版本 号。

如果没有资源发生变更，资源列表中的各个资源的版本变更单元43判断 到第二获取单元42接收的资源列表未发生变更，则各个资源的版本号不进行 统一变更。

任务接收单元44用于接收所述管理器分配的待执行任务。

任务处理单元45用于当任务接收单元44接收到所述待执行任务时，进 行对应的待执行任务的处理。

当管理器判断到资源组中资源的版本号一致时，则将待执行任务分配给 各个资源。此时，各个资源的任务接收单元44才能接收到管理器分配的任务。 当接收到所述待执行任务时，任务处理单元45进行对应的待执行任务的处理。

具体地，任务处理单元45可以包括：第一获取子单元451、第二判断子 单元452、第二获取子单元453、第三获取子单元454和任务处理子单元455。

第一获取子单元451用于当接收到所述资源组更新的任务分配时，获取 所述管理器发送的执行资源列表。

管理器根据预定义规则划分所述待执行任务，设置执行资源数A，并确定 资源组中的A个资源，形成执行资源列表发送给资源组中各个资源服务器。 第一获取子单元451则获取管理器发送的执行资源列表。

第二判断子单元452用于判断所述分布式资源服务器是否在所述执行资 源列表中，如果是，则触发第二获取子单元453，否则，返回第二获取单元 42。

第二获取子单元453用于获取所述分布式资源服务器在所述执行资源列 表中的序号。

第三获取子单元454用于根据所述序号从所述管理器中获取对应的待执 行任务，以提供给任务处理子单元455。

具体地，第三获取子单元454先利用所述管理器预先定义的子任务组数 N，计算所述执行资源列表的A个资源中平均每个资源应负责的子任务数AN， 管理器已将所述待执行任务的N组子任务划分成A个区间，第三获取子单元 454则根据所述当前资源的序号IN，获取对应第IN个区间的所述子任务。

任务处理子单元455用于在接收到所述第三获取子单元454获取的待执 行任务后，进行本批次的待执行任务的处理。

本申请提供的分布式资源分配方法及装置，通过分布式资源管理器 （zookeeper等）管理资源组内实际可用资源的信息，并将资源组信息推送至 每一个资源，确保每一个资源均可获得整个资源组的信息，同时依据预先定 义好的任务分配规则，计算得出各个资源实际处理的任务范围，可以将任务 在资源组内的进行合理的动态分配，不需要依赖数据库，避免出现任务处 理延迟的情况。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的 各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来 实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能 一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来 执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每 个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为 超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理 器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器 （RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、 寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式 的存储介质中。

以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行 了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而 已，并不用于限定本申请的保护范围，凡在本申请的精神和原则之内，所做 的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。