CN107391252A - 一种资源处理方法及装置 - Google Patents

Abstract

本申请公开了一种资源处理方法及装置，获取各匹配请求，并确定获取到的各匹配请求所属的类别，确定每一类别的匹配请求对应的最低资源增量数据，从资源池中获取每一类别的资源，并在确定出任一类别的资源中最高增量标定数据高于同类别匹配请求的最低资源增量数据时，将该类资源与同类别的匹配请求进行匹配。在实际应用时，服务器在进行匹配操作之前，能够从总体上对匹配请求和相应的资源进行筛选，有效减少了多余的匹配操作，从而进一步降低了***性能的消耗。

Description

一种资源处理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种资源处理方法及装置。

背景技术

随着信息技术的发展，对于各类互联网信息资源(比如服务器处理资源、网络存储资源、数据库空间资源等，以下简称资源)的需求不断扩大，以满足各种实际应用的需要。

实际应用场景下，资源需求方(如：用户)可向资源平台(如：在线***)发出请求，以便获取到相应的资源进行使用，相应地，资源平台也会根据资源需求方的请求，为资源需求方匹配合适的资源提供方(如：服务器、数据库)，以使得资源提供方能够为资源需求方提供资源。例如：用户向某网站发出云计算请求，该网站将为用户分配由服务器提供的运算资源。该过程中，用户可看作是资源需求方；网站可看作是资源平台；而提供运算资源的服务器可看作是资源提供方。

在使用资源的过程中，往往会出现额外增加的资源用量，例如：在服务器处理请求的过程中，受到处理时间和关联进程的影响，使得原本所占用的运算资源增加(即，额外增加了资源用量)。

基于此，现有技术中，提供了一种资源的匹配方式，具体而言，资源需求方发出的请求中往往会包含资源增量数据(资源增量数据表征了在使用资源过程中，额外增加的资源用量)。相应地，资源提供方也会针对不同类型的请求，设置不同的增量标定数据(资源增量标定数据，表征了资源提供方在提供资源时，可允许的、额外的资源增量的标定值)。那么，资源平台就会根据请求中所包含的资源增量数据，以及资源提供方的增量标定数据，为资源需求方匹配合适的资源。

例如：假设某账户向某网站发出申请，以请求10GB的网盘空间，该请求中的资源增量数据为：请求空间的1％，即100MB(该数据表示，在进行频繁的上传、下载的过程中，会产生文件碎片，从而额外增加对网盘空间的占用，所占用的网盘空间的大小为100MB)，而提供网盘空间的某服务器针对10GB的网盘空间所设置的增量标定数据为：请求空间的1.5％(即，150MB)，显然，服务器的增量标定数据符合账户所提出的申请，所以，网站会将为该账户匹配该服务器所提供的网盘空间。

对于上述方式而言，资源平台在进行资源匹配时，会针对接收到的所有的请求均进行资源匹配的处理，在实际应用中，部分请求的资源增量数据与资源提供方所设置的增量标定数据并不相符，这必然会导致不能成功匹配，然而，针对这些不能成功匹配的请求和资源，资源平台仍会继续进行匹配处理，这无疑消耗了资源平台的***性能，进一步造成匹配效率较低。

发明内容

本申请实施例提供一种资源处理方法及装置，用以解决目前资源平台在进行资源匹配的过程中效率较低的问题。

本申请实施例提供的一种资源处理方法，包括：

获取各匹配请求，并确定获取到的各匹配请求所属的类别；

确定每一类别的匹配请求对应的最低资源增量数据；

从资源池中获取每一类别的资源，并在确定出任一类别的资源中最高增量标定数据高于同类别匹配请求的最低资源增量数据时，将该类资源与相应类别的匹配请求进行匹配。

本申请实施例还提供的一种针对金融产品的申购请求处理方法，包括：

获取针对金融产品的各申购请求，并确定所述各申购请求所属的类别；

确定每一类别的申购请求对应的最低利率；

从已发布的所有金融产品中获取每一类别的金融产品，并在确定出任一类别的金融产品所对应的最高利率高于同类别的申购请求的最低利率时，将该类别的金融产品与同类别的申购请求进行匹配。

本申请实施例提供的一种资源处理装置，包括：

类别确定模块，获取各匹配请求，并确定获取到的各匹配请求所属的类别；

资源增量模块，确定每一类别的匹配请求对应的最低资源增量数据；

处理模块，从资源池中获取每一类别的资源，并在确定出任一类别的资源中最高增量标定数据高于同类别匹配请求的最低资源增量数据时，将该类资源与同类别的匹配请求进行匹配。

本申请实施例提供的一种针对金融产品的申购请求处理装置，包括：

类别确定模块，获取针对金融产品的各申购请求，并确定所述各申购请求所属的类别；

利率确定模块，确定每一类别的申购请求对应的最低利率；

处理模块，从已发布的所有金融产品中获取每一类别的金融产品，并在确定出任一类别的金融产品所对应的最高利率高于同类别的申购请求的最低利率时，将该类别的金融产品与同类别的申购请求进行匹配。

本申请实施例提供一种资源处理方法及装置，服务器将针对获取到的各匹配请求进行分类，针对每一类别的匹配请求，服务器将确定出该类别的匹配请求所对应的最低资源增量数据，确定出的该最低资源增量数据，从总体上反映出该类别的匹配请求所需的额外的资源增量的最低值；相应地，服务器还会从资源池中获取属于该类别的各资源，并确定获取到的各资源的最高的增量标定数据，确定出的该最高增量标定数据，从总体上反映出该类别的资源所能够允许的额外的资源增量的最大值。之后，服务器便可以判断出该类匹配请求的最低资源增量数据是否不高于同类资源的最高增量标定数据。如果不高于，就表明在使用资源的过程中，资源的额外增量处于资源提供方所允许的额外增量的标定范围之内，那么，服务器也就可以针对这类匹配请求和同类资源进行匹配；反之，就表明在使用资源的过程中，资源的额外增量将超出资源提供方所允许的额外增量的标定，那么，服务器也就不会针对这类匹配请求和同类的资源进行匹配，而是将匹配请求和资源进行等待。可见，通过上述方式，在实际应用时，服务器在进行匹配操作之前，能够从总体上对匹配请求和相应的资源进行筛选，有效减少了多余的匹配操作，从而进一步降低了***性能的消耗。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的资源处理过程；

图2a为本申请实施例提供的服务器结构示意图；

图2b为本申请实施例提供的资源处理方法的实际执行过程；

图3为本申请实施例提供的在实际应用场景下的针对金融产品的申购请求处理过程；

图4为本申请实施例提供的资源处理装置结构示意图；

图5为本申请实施例提供的在实际应用场景下的针对金融产品的申购请求处理装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

正如前述，资源平台会针对其接收到的所有资源需求方所发出的请求、以及所有资源提供方所提供的请求进行匹配，在匹配的过程中，资源需求方所发出的一部分请求中所包含的资源增量数据与资源提供方所提供的增量标定数据并不相符，也就是说，这一部分请求和资源将无法进行匹配，然而，资源平台仍会进行匹配操作，从而浪费了资源平台的***性能。

基于此，就需要一种能够对请求和相应资源进行筛选的资源的匹配方式，因此，在本申请实施例中，提供一种资源处理方法，如图1所示。

需要说明的是，在本申请实施例中的下文中，将资源需求方所发出的用以匹配资源的请求称为：匹配请求。同时，如图1所示的方法将由资源平台进行相应的资源匹配操作，本申请实施例中的资源平台可以理解为资源平台服务器，为了便于描述，下文中简称为：服务器。

具体而言，图1为本申请实施例提供的资源处理过程，该过程具体包括以下步骤：

S101：获取各匹配请求，并确定获取到的各匹配请求所属的类别。

在实际应用中，服务器通常会面向大量的资源需求方(如：用户)，不同的用户均可以向服务器发出相应的匹配请求，以请求匹配到相应的资源。也就是说，服务器将不断地接收到来自不同用户所发出的匹配请求。服务器所接收到的匹配请求，可先存储于该服务器的数据库(或数据仓库)中，那么，服务器获取的各匹配请求，也就可以是服务器从自身的数据库(或数据仓库)中获取，这里并不构成对本申请的限定。

可以认为，服务器所获取到的这些匹配请求，均是未与相应的资源进行匹配的匹配请求。当然，作为本申请实施例在实际应用场景下的一种方式，服务器可以按照设定的时间周期从数据库(或数据仓库)中获取接收到的匹配请求，如：每30秒获取一次。如果实际应用中，匹配请求的数量较大，则可以动态的调整上述时间周期。

在另一种方式下，可以按照设定的数量获取接收到的匹配请求，如：每次获取1000个匹配请求。

从上述的内容可见，在实际应用时，服务器将会逐次的对接收到的各匹配请求进行资源的匹配处理。上述的两种方式并不构成对本申请的限定。

服务器所接收到的各匹配请求通常是不同类别的匹配请求，例如：某些匹配请求是为了请求网盘存储空间，而某些匹配请求是为了请求云计算资源等等。那么，服务器为了后续过程将不同的匹配请求与相应的资源进行匹配，故服务器会确定获取到的各匹配请求的类别。

S102：确定每一类别的匹配请求对应的最低资源增量数据。

服务器所面对的匹配请求的数量通常较多，进而，每一类别的匹配请求通常也会有多个。故对于本步骤而言，每一类别的匹配请求可理解为多个匹配请求属于同一类别。

在实际应用中，即使是同一类别的匹配请求，其中所请求的资源量、资源增量数据等也各不相同，例如：在同属于网盘存储空间的匹配请求中，某用户可能会请求10GB的网盘存储空间，同时，资源增量数据为：请求空间的1.5％；而另一用户可能会请求5GB的网盘存储空间，同时，资源增量数据为：请求空间的0.8％。

而考虑到在实际应用中，资源增量数据通常会影响在使用资源的过程中的使用状态(如果资源增量数据高于增量标定数据，就会导致在使用过程中出现问题)，那么，为了保证在后续过程中资源的正常使用，在上述步骤中将确定出每一类别的匹配请求所对应的最低资源增量数据。

S103：从资源池中获取每一类别的资源，并在确定出任一类别的资源中最高增量标定数据高于同类别匹配请求的最低资源增量数据时，将该类资源与相应类别的匹配请求进行匹配。

在本申请实施例中，服务器内通常会以资源池的方式存储不同的资源，可以认为，这些资源由该服务器自身提供，或者，由相应的资源提供方所提供，这里并不构成对本申请的限定。

当服务器为根据匹配请求匹配相应的资源时，所匹配的资源往往也是相应类别的资源。例如：若资源匹配请求的类别属于请求网盘存储空间，那么，服务器在为该类别的匹配请求匹配资源时，就会匹配网盘存储空间类的资源，而非其他类别的资源。

即使是同一类别的资源，也存在不同的资源用量标定、增量标定数据等，例如：不同的网盘服务器所提供的网盘存储空间的存储量不同，某些网盘服务器能够针对每一用户能够提供1GB的网盘存储空间，而某些网盘服务器能够针对每一用户提供10GB的网盘存储空间。又例如：某些网盘服务器所设置的增量标定数据为：存储量的1.8％；而某些网盘服务器所设置的增量标定数据为：存储量0.9％等等。

在实际应用中，对于任一类别的匹配请求而言，如果该类别的匹配请求的最低资源增量数据不高于同类别资源的最高增量标定数据，那么就表示在使用资源的过程中，资源的额外增量处于资源提供方所允许的额外增量的标定范围之内，显然，这样的情况下，可以进行匹配。

例如：假设某类别的匹配请求属于网盘存储空间的请求，其中的最低资源增量数据为：请求空间的1％；并假设与服务器相关联的网盘服务器所提供的网盘存储空间的最高增量标定数据为：请求空间的1.8％。显然，这就表明网盘服务器所提供的增量标定数据在总体上能够满足网盘存储空间请求的需求。所以，此时服务器将会针对上述请求匹配相应的网盘存储空间。

而如果该类别的匹配请求的最低资源增量数据高于了同类别资源的最高增量标定数据，那么就表示在使用资源的过程中，资源的额外增量将大于资源提供方所允许的额外增量的标定，从而导致在实际的资源使用过程中出现问题，那么，在这样的情况下，服务器将不会进行匹配。

例如：延续上例，若网盘存储空间的请求中的最低资源增量数据为：请求空间的2％(高于最高增量标定数据1.8％)，也就是说，网盘服务器所提供的增量标定数据在总体上不能满足网盘存储空间请求的需求，故此时，服务器将不会进行匹配。

故本步骤中，针对每一类别的匹配请求，在确定出任一类别的资源中最高增量标定数据高于同类别匹配请求的最低资源增量数据时，将该类资源与相应类别的匹配请求进行匹配。

需要说明的是，对于匹配的过程而言，可以按照“高配高”、“低配低”的方式进行匹配，具体来说，在同类别的匹配请求及资源中，将资源增量数据最高的匹配请求与标定增量数据最高的资源进行匹配，相应地，将资源增量数据次高的匹配请求与标定增量数据次高的资源进行匹配，以此类推。

又或者，将匹配请求对应的资源增量数据按照大小顺序划分为多个区间段，并按照区间段匹配不同标定增量数据的资源。

当然，匹配的过程并不构成对本申请的限定，这里不再过多赘述。

通过上述步骤，服务器将针对获取到的各匹配请求进行分类，针对每一类别的匹配请求，服务器将确定出该类别的匹配请求所对应的最低资源增量数据，确定出的该最低资源增量数据，从总体上反映出该类别的匹配请求所需的额外的资源增量的最低值；相应地，服务器还会从资源池中获取属于该类别的各资源，并确定获取到的各资源的最高的增量标定数据，确定出的该最高增量标定数据，从总体上反映出该类别的资源所能够允许的额外的资源增量的最大值。之后，服务器便可以判断出该类匹配请求的最低资源增量数据是否不高于同类资源的最高增量标定数据。如果不高于，就表明在使用资源的过程中，资源的额外增量处于资源提供方所允许的额外增量的标定范围之内，那么，服务器也就可以针对这类匹配请求和同类资源进行匹配；反之，就表明在使用资源的过程中，资源的额外增量将超出资源提供方所允许的额外增量的标定，那么，服务器也就不会针对这类匹配请求和同类的资源进行匹配，而是将匹配请求和资源进行等待。可见，通过上述方式，在实际应用时，服务器在进行匹配操作之前，能够从总体上对匹配请求和相应的资源进行筛选，有效减少了多余的匹配操作，从而进一步降低了***性能的消耗。

作为本申请实施例在实际应用中的一种方式，如图2a所示，示出了本申请实施例中的服务器内部的架构，从图2a中可见，服务器中包含数据处理引擎和匹配引擎。其中，

数据处理引擎主要用于从服务器的数据库(或数据仓库)中获取匹配请求，并针对匹配请求进行分类，确定出各类别的匹配请求的最低资源增量数据；相应地，数据处理引擎还会针对资源提供方所提供的各资源也进行分类，并确定出各类别的资源的最高增量标定数据。数据处理引擎完成了上述处理后，会将处理后的数据发送给匹配引擎。

匹配引擎则主要用于对上述数据处理引擎所处理后的匹配请求和资源进行判断、匹配、使匹配请求和资源进入等待状态等操作。

当然，上述的服务器中的架构并不构成对本申请的限定。

基于如图2a所示的服务器架构，上述如图1所示的方法在具体实施的过程中，可以采用更为详细的执行步骤，如图2b所示。

具体而言，S201：获取接收到的各匹配请求。

S202：针对获取到的各匹配请求，确定所述各匹配请求分别所属的类别。

S203：针对每一类别的匹配请求，确定属于该类别的所有匹配请求所对应的最低资源增量数据。

S204：从资源池中获取属于该类别的各资源，并确定获取到的各资源的最高增量标定数据。

S205：根据确定出的所述最低资源增量数据以及所述最高增量标定数据，判断所述最低资源增量数据，是否不高于所述最高增量标定数据，若是，执行步骤S206；否则，执行步骤S207。

S206：将属于该类别的匹配请求与同类别的资源进行匹配。

S207：将属于该类别的匹配请求与同类别的资源进行等待。

需要说明的是，由于在实际应用中，服务器不断接收匹配请求，不同类别的匹配请求所对应的资源增量数据就可能发生一定程度的变化，并且，资源提供方所提供的不同类别资源的增量标定数据也在动态变化，那么，对于未匹配成功的某一类别的匹配请求和资源而言(也即，处于等待状态的匹配请求和资源)，就可能随着资源增量数据和增量标定数据的变化，而重新进行匹配。

故针对上述过程中进行等待的匹配请求和资源而言，服务器将实时监测新的资源增量数据和增量标定数据的变化，以针对处于等待状态的匹配请求和资源进行匹配处理。这里并不构成对本申请的限定。

针对于前述方法中确定匹配请求的类别的过程而言，具体地，确定获取到的所述各匹配请求分别所属的类别，具体包括：确定各匹配请求中所包含的类别特征信息，根据预设的分类项以及各匹配请求所包含的所述类别特征信息，确定所述各匹配请求分别所属的类别。

类别特征信息，具体可以是匹配请求的各类属性，例如：对于某网盘存储空间的请求而言，假设所要请求的网盘存储空间的大小为10GB，所请求的使用时间为一周，那么，这些数据就是该请求的类别特征信息。在本申请实施例中的一种方式中，匹配请求所对应的资源增量数据也可以作为一种类别特征信息，在分类的过程中使用，这里并不构成对本申请的限定。

沿用该示例，预设的分类项，可以是网盘存储空间大小范围：1～5GB、6～10GB；使用时间范围：1～7天、8～14天等等。显然，根据预设的分类项，可将匹配请求分为不同的类别。

相类似地，采用相似的方式可以对不同资源提供方所提供的资源进行分类，这里并在具体赘述。

需要说明的是，采用上述如图2a所示的服务器架构，当数据处理资源在对当前时刻服务器所接收到的匹配请求、资源进行分类处理、确定最低资源增量数据、最高增量标定数据的过程中，服务器还会不断的接收到新增的匹配请求和资源，也就是说，不断会出现新增的资源增量数据和增量标定数据，即，资源增量数据和增量标定数据的具体值将不断处于波动状态。

基于此，在本申请实施例中，还设置了相应的增量波动值，在此情况下，确定每一类别的匹配请求所对应的最低资源增量数据，具体包括：针对每一类别的匹配请求，确定该类别的所有匹配请求的资源增量的最低值，根据预设的增量波动值，以及资源增量的最低值，确定该类别的最低资源增量数据与预设的增量波动值的和值，将该和值确定为该类别的匹配请求中的最低资源增量数据。

所述的增量波动值的取值既可能是正值、也可能是负值，现以一示例进行说明：假设网盘存储空间请求所对应的最低资源增量数据为：请求空间的1.5％，服务器在一段时间内所接收到的新增的网盘存储空间请求，其资源增量数据均高于1.5％，这些新增的网盘存储空间请求的资源增量数据平均在1.7％上下，那么，就可以认为，这段时间内资源增量数据的增量波动值为0.2％。

又例如：假设在一段时间内，服务器所接收到的新增的网盘存储空间请求，其资源增量数据均低于1.5％，这些新增的网盘存储空间请求的资源增量数据平均在1.1％上下，那么，就可以认为，这段时间内资源增量数据的增量波动值为-0.4％，

可见，增量波动值反映了资源增量数据在一段时间内总体上的变化趋势，当然，上述示例中确定增量波动值的方式并不构成对本申请的限定。

在实际应用中，资源增量数据的变化较为散乱，换言之，在一段时间内新增的各匹配请求所对应的各资源增量数据中，有的资源增量数据高于当前已确定出的最低资源增量数据，而有的资源增量数据低于当前已确定出的最低资源增量数据，这就需要动态地调整增量波动值，基于此，所述方法还包括：针对每一类别，统计设定时间段内，该类别的资源增量数据与所述增量波动值之间的各差值，根据所述各差值，确定各差值的平均值，根据所述平均值与所述增量波动值的和值，更新所述增量波动值。

例如：假设已经确定出的增量波动值为1.5％，并假设在某一时间段内，服务器接收到了三个新增的匹配请求，这三个新增的匹配请求所对应的资源增量数据分别为：1.7％、1.0％以及0.9％，从而，可以确定这三个资源增量数据与已确定出的增量波动值之间的差值分别为：0.2％、-0.5％、-0.6％，其均值为-0.3％，该均值表示新增的资源增量数据有逐渐减小的趋势，其减小的幅度量化为0.3％，所以，可将增量波动值更新为1.2％。当然，这样动态调整增量波动值的方式并不构成对本申请的限定。

通过上述方式，能够针对各类别的匹配请求和资源，从总体上较为准确地判断出能够进行匹配的匹配请求和资源，以及不能够进行匹配的匹配请求和资源。

此外，考虑到实际应用中，用户可以通过金融平台购买相应的金融产品。该场景下，用户发出的申购请求中会指定的用户所需的利率，相应地，金融产品也具有不同的利率，显然，如果金融产品的利率低于用户所需的利率，必然不会成功匹配，但现有技术中，金融平台的服务器仍会针对接收到的申购请求与金融产品进行匹配，这样便浪费了服务器的处理资源。为此，在本申请实施例中，针对用户购买金融产品的场景，也提供了一种针对金融产品的申购请求处理方法，如图3所示。在该场景下，用户可通过服务器(如：金融平台、网站等)发出购买金融产品的申购请求，相应地，金融产品的提供者会将相应的金融产品发布在服务器中，从而，服务器会针对用户的申购请求，来匹配相应的金融产品。

该方法包括：

步骤一：获取针对金融产品的各申购请求，并确定所述各申购请求所属的类别。

步骤二：确定每一类别的申购请求对应的最低利率。

步骤三：从已发布的所有金融产品中获取每一类别的金融产品，并在确定出任一类别的金融产品所对应的最高利率高于同类别的申购请求的最低利率时，将该类别的金融产品与同类别的申购请求进行匹配。

基于上述方法，在具体实施的过程中，可以采用更为详细的执行步骤，具体而言，如图3所示，该方法具体包括：

S301：获取接收到的针对金融产品的各申购请求。

S302：确定所述各申购请求分别所属的类别。

S303：针对每一类别的申购请求，确定属于该类别的各申购请求所对应的最低利率。

S304：从已发布的所有金融产品中，获取属于该类别的各金融产品，并确定获取到的各金融产品所对应的最高利率。

S305：根据确定出的所述最低利率以及所述最高利率，判断所述最低利率是否不高于所述最高利率，若是，则执行步骤S306；否则，则执行步骤S307。

S306：将属于该类别的申购请求与同类别的金融产品进行匹配。

S307：将属于该类别的申购请求与同类别的金融产品进行等待。

与现有技术中服务器针对任何申购请求均与金融商品进行匹配的方式不同，通过上述方法，可以有效且快速的判断出能够进行匹配的申购请求和相应的金融产品，以及不能进行匹配的申购请求和金融产品，从而，可以减少服务器的***性能消耗，也进一步增加了申购请求与金融产品进行匹配的效率。

当然，在实际应用场景下，在确定申购请求的最低利率时，通常也会考虑利率波动值(即，前述方法中的增量波动数据)，这是因为：在实际应用中，申购请求所对应的最低利率也存在动态波动的情况。

下面以一应用实例进行说明：假设用户所发出的申购请求的分类如下表1所示。

申购类别	类目	购买期限	是否支持取现	最低利率
					I	借款类目	30～60天	是	3.2％
II	借款类目	30～90天	否	4.5％

表1

从表1中可见，申购请求分为两类(具体的分类方式与前述方法相同，在此不再过多赘述)，在此假设利率波动值为-1％，且类别I的金融产品的最高利率为2.6％，类别II的金融产品的最高利率为3.0％。那么，基于利率看波动值，可以确定出I类申购请求的最低利率阈值为3.2％+(-1％)＝2.2％，II类申购请求的最低利率阈值为4.5％+(-1％)＝3.5％。所以，最终的匹配结果如表2所示。

申购类别	申购最低利率阈值	产品最高利率	是否匹配
				I	2.2％	2.6％	匹配
II	3.5％	3.0％	不匹配

表2

可见，申购类别II的金融产品的利率低于申购请求的利率阈值，也就是说，该类别的申购请求和金融产品将不能匹配，所以，服务器对于申购类别II的申购请求和金融产品进行等待。

这样的方式节省了执行匹配过程中***及数据库查询开销，也提升了匹配效率。

以上为本申请实施例提供的资源处理方法，基于同样的思路，本申请实施例还提供一种资源处理装置，如图4所示。

在图4中，所述资源处理装置包括：

类别确定模块401，获取各匹配请求，并确定获取到的各匹配请求所属的类别；

资源增量模块402，确定每一类别的匹配请求对应的最低资源增量数据；

判断处理模块403，从资源池中获取每一类别的资源，并在确定出任一类别的资源中最高增量标定数据高于同类别匹配请求的最低资源增量数据时，将该类资源与同类别的匹配请求进行匹配。

所述类别确定模块401，确定各匹配请求中所包含的类别特征信息，根据预设的分类项以及各匹配请求所包含的所述类别特征信息，确定所述各匹配请求分别所属的类别。

所述资源增量模块402，针对每一类别的匹配请求，确定该类别的所有匹配请求的资源增量的最低值，根据预设的增量波动值，以及资源增量的最低值，确定该类别的最低资源增量数据与预设的增量波动值的和值，将该和值确定为该类别的匹配请求中的最低资源增量数据。

所述装置还包括：动态调节模块404，针对每一类别，统计设定时间段内，该类别的资源增量数据与所述增量波动值之间的各差值，根据所述各差值，确定各差值的平均值，根据所述平均值与所述增量波动值的和值，更新所述增量波动值。

基于一种实际应用场景，本申请实施例还提供一种针对金融产品的申购请求处理装置，如图5所示。所述装置包括：

类别确定模块501，获取针对金融产品的各申购请求，并确定所述各申购请求所属的类别。

利率确定模块502，确定每一类别的申购请求对应的最低利率。

处理模块503，从已发布的所有金融产品中获取每一类别的金融产品，并在确定出任一类别的金融产品所对应的最高利率高于同类别的申购请求的最低利率时，将该类别的金融产品与同类别的申购请求进行匹配。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种资源处理方法，其特征在于，包括：

获取各匹配请求，并确定获取到的各匹配请求所属的类别；

确定每一类别的匹配请求对应的最低资源增量数据；

从资源池中获取每一类别的资源，并在确定出任一类别的资源中最高增量标定数据高于同类别匹配请求的最低资源增量数据时，将该类资源与同类别的匹配请求进行匹配。

2.如权利要求1所述的方法，其特征在于，确定获取到的所述各匹配请求所属的类别，具体包括：

确定各匹配请求中所包含的类别特征信息；

根据预设的分类项以及各匹配请求所包含的所述类别特征信息，确定所述各匹配请求分别所属的类别。

3.如权利要求1所述的方法，其特征在于，确定每一类别的匹配请求所对应的最低资源增量数据，具体包括：

针对每一类别的匹配请求，确定该类别的所有匹配请求的资源增量的最低值；

根据预设的增量波动值，以及资源增量的最低值，确定该类别的最低资源增量数据与预设的增量波动值的和值；

将该和值确定为该类别的匹配请求中的最低资源增量数据。

4.如权利要求3所述的方法，其特征在于，所述方法还包括：

针对每一类别，统计设定时间段内，该类别的资源增量数据与所述增量波动值之间的各差值；

根据所述各差值，确定各差值的平均值；

根据所述平均值与所述增量波动值的和值，更新所述增量波动值。

5.一种针对金融产品的申购请求处理方法，其特征在于，包括：

获取针对金融产品的各申购请求，并确定所述各申购请求所属的类别；

确定每一类别的申购请求对应的最低利率；

从已发布的所有金融产品中获取每一类别的金融产品，并在确定出任一类别的金融产品所对应的最高利率高于同类别的申购请求的最低利率时，将该类别的金融产品与同类别的申购请求进行匹配。

6.一种业务处理装置，其特征在于，包括：

类别确定模块，获取各匹配请求，并确定获取到的各匹配请求所属的类别；

资源增量模块，确定每一类别的匹配请求对应的最低资源增量数据；

处理模块，从资源池中获取每一类别的资源，并在确定出任一类别的资源中最高增量标定数据高于同类别匹配请求的最低资源增量数据时，将该类资源与同类别的匹配请求进行匹配。

7.如权利要求6所述的装置，其特征在于，所述类别确定模块，确定各匹配请求中所包含的类别特征信息，根据预设的分类项以及各匹配请求所包含的所述类别特征信息，确定所述各匹配请求分别所属的类别。

8.如权利要求6所述的装置，其特征在于，所述资源增量模块，针对每一类别的匹配请求，确定该类别的所有匹配请求的资源增量的最低值，根据预设的增量波动值，以及资源增量的最低值，确定该类别的最低资源增量数据与预设的增量波动值的和值，将该和值确定为该类别的匹配请求中的最低资源增量数据。

9.如权利要求8所述的装置，其特征在于，所述装置还包括：动态调节模块，用于针对每一类别，统计设定时间段内，该类别的资源增量数据与所述增量波动值之间的各差值，根据所述各差值，确定各差值的平均值，根据所述平均值与所述增量波动值的和值，更新所述增量波动值。

10.一种针对金融产品的申购请求处理装置，其特征在于，包括：

类别确定模块，获取针对金融产品的各申购请求，并确定所述各申购请求所属的类别；

利率确定模块，确定每一类别的申购请求对应的最低利率；

处理模块，从已发布的所有金融产品中获取每一类别的金融产品，并在确定出任一类别的金融产品所对应的最高利率高于同类别的申购请求的最低利率时，将该类别的金融产品与同类别的申购请求进行匹配。