CN111669341B - 互联网资源调度方法及装置 - Google Patents

Abstract

本申请公开了一种互联网资源调度方法及装置，用以解决现有技术中的互联网资源调度方式导致资源利用率降低的问题。所述互联网资源调度方法包括：在一个调度周期内，每当确定将第一设备的资源调度给第二设备时，为所述第一设备增量地保留资源；在所述调度周期结束时，若确定所述第二设备未对从所述第一设备调度的资源进行归还，则将为所述第一设备保留的资源调度给所述第一设备。

Description

互联网资源调度方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种互联网资源调度方法及装置。

背景技术

随着计算机技术和网络技术的迅速发展，各种设备互联互助的能力也得到了加强，尤其是互联设备之间互联网资源方面互助能力的加强，十分有利于提高互联设备的工作性能。其中，互联网资源可以指存储空间、网络带宽、处理线程等与互联网相关的资源。

互联网资源方面互助一般是通过资源调度实现的。假定第一设备、第二设备与调度服务器相互连接，其中，第一设备、第二设备分别可以有多个。当第二设备资源不足而第一设备存在空闲资源时，调度服务器可以一次或多次地将第一设备的资源调度给第二设备使用，使用完毕后第二设备可以将该资源归还给第一设备。

在现有技术中，调度服务器一般还会维护一个应急资源库，调度服务器会在应急资源库中预先为每个第一设备保留固定量的资源，以用于在第二设备无法及时归还资源时，代替第二设备向第一设备归还，从而可以降低对第一设备的不利影响。

但是，在实际应用中，无法预计第一设备将会被调度的资源量，出于可靠性方面的考虑，在上述现有技术中，调度服务器会将上述的固定量设置得尽量大，但是，这种方式导致闲置资源增加，资源利用率降低。

发明内容

本申请实施例提供一种互联网资源调度方法及装置，用以解决现有技术中的互联网资源调度方式导致资源利用率降低的问题。

本申请实施例还提供一种担保方法及装置。

本申请实施例采用下述技术方案：

第一方面，本申请实施例提供的一种互联网资源调度方法，包括：

在一个调度周期内，每当确定将第一设备的资源调度给第二设备时，为所述第一设备增量地保留资源；

在所述调度周期结束时，若确定所述第二设备未对从所述第一设备调度的资源进行归还，则将为所述第一设备保留的资源调度给所述第一设备。

第二方面，本申请实施例提供的一种互联网资源调度装置，包括：

保留调度模块，在一个调度周期内，每当确定将第一设备的资源调度给第二设备时，为所述第一设备增量地保留资源；

归还调度模块，在所述调度周期结束时，若确定所述第二设备未对从所述第一设备调度的资源进行归还，则将为所述第一设备保留的资源调度给所述第一设备。

第三方面，本申请实施例提供的一种担保方法，包括：

在一个担保周期内，每当确定担保请求方在担保受益方处产生消费金额时，为所述担保请求方提高担保金额；

在所述担保周期结束时，若确定所述担保请求方未对在所述担保受益方处产生的消费金额进行结算，则将所述担保金额结算给所述担保受益方。

第四方面，本申请实施例提供的一种担保装置，包括：

担保模块，在一个担保周期内，每当确定担保请求方在担保受益方处产生消费金额时，为所述担保请求方提高担保金额；

结算模块，在所述担保周期结束时，若确定所述担保请求方未对在所述担保受益方处产生的消费金额进行结算，则将所述担保金额结算给所述担保受益方。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：在一个调度周期内，初始时可以不为第一设备保留资源，而是随着被调度给第二设备的第一设备的资源的增加，相应地增加为第一设备保留的资源，从而可以在满足第二设备对调度资源需求的前提下，及时地对为第一设备保留的资源量进行动态调整，相比于现有技术可以减少闲置资源，提高资源利用率，因此，可以部分或全部地解决现有技术的问题。

附图说明

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

图1为本申请实施例提供的一种互联网资源调度方法的流程示意图；

图2为本申请实施例提供的一种实际应用场景下，互联网资源调度方法的实施过程示意图；

图3为本申请实施例提供的一种互联网资源调度装置的结构示意图；

图4为本申请实施例提供的一种担保方法的流程示意图；

图5为本申请实施例提供的一种实际应用场景下，担保方法的实施过程示意图；

图6为本申请实施例提供的一种实际应用场景下，担保方法的交互过程时序图；

图7为本申请实施例提供的一种担保装置的结构示意图。

具体实施方式

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

在本申请实施例中，所述资源可以为存储空间、网络带宽、处理线程、或网络上可使用的货币等互联网资源。第一设备、第二设备为可拥有所述资源的设备，比如，手机、平板电脑、可穿戴智能设备、车载移动台、个人计算机、计算机集群机器等；第一设备可以提供出自己的部分或全部资源，以用于调度给第二设备使用。

图1为本申请实施例提供的一种互联网资源调度方法的流程示意图。该方法的执行主体可以为资源调度服务器、第一设备或第二设备等，本申请对执行主体并不做限定。

图1中的方法的流程可以包括以下步骤：

S101：在一个调度周期内，每当确定将第一设备的资源调度给第二设备时，为所述第一设备增量地保留资源。

本申请对调度周期的长度并不做限定，可以取决于具体的资源、业务或设备。该长度通常为一天、一周、或一个月等。在一个调度周期内，可以多次将第一设备的资源调度给第二设备，本申请对调度次数与每次所调度的资源量并不做限定。

在本申请实施例中，任一次(称为：本次)“确定将第一设备的资源调度给第二设备时”可以指：本次即将把第一设备的资源调度给第二设备但尚未开始执行时；或者，本次正在将第一设备的资源调度给第二设备的过程中的某时刻；或者，本次已经将第一设备的资源调度给第二设备后的某时刻。

步骤S101中的“将第一设备的资源调度给第二设备”和“为所述第一设备增量地保留资源”这两个动作可以是同时执行的，也可以是按照一定的先后顺序执行的。一般而言，这两个动作的同步性越好，则越有利于精确地动态调整为第一设备保留的资源量。

在本申请实施例中，随着从第一设备调度给第二设备的总资源量逐渐增加，相应地也逐渐增加为第一设备保留的总资源量(也即，增量地保留资源)，以解决当第二设备未及时归还资源时给第一设备带来不便的问题。

S102：在所述调度周期结束时，若确定所述第二设备未对从所述第一设备调度的资源进行归还，则将为所述第一设备保留的资源调度给所述第一设备。

在本申请实施例中，第二设备可以在调度周期中归还部分或全部调度得来的资源，也可以在调度周期的结束时再归还该资源。在实际应用中，一般将调度周期结束的时刻作为第二设备归还资源的期限。

若确定截止该期限，第二设备未对从第一设备调度的资源进行归还(完全未归还，或者未完全归还)，则将为第一设备保留的部分或全部资源调度给第一设备，以作为对第一设备的补偿，从而可以防止因为第二设备未遵守该期限而对第一设备造成不利影响。

反之，若确定截止该期限，第二设备对从第一设备调度的资源全部进行了归还，则可以将该调度周期内为第一设备保留的资源释放，再开始下一个调度周期。在这种情况下，在调度周期的开始时刻，为第一设备保留的资源量可以为零。

在本申请实施例中，若第二设备在调度周期中归还了部分调度得来的资源，则也可以相应地减少为第一设备保留的资源。

需要说明的是，图1中的方法的各步骤的执行主体可以是同一设备，也可以是不同设备。比如，步骤S101和S102的执行主体均可以为设备1；又比如，步骤S101的执行主体可以为设备1，步骤S102的执行主体可以为设备2；等等。

通过图1中的方法，在一个调度周期内，初始时可以不为第一设备保留资源，而是随着被调度给第二设备的第一设备的资源的增加，相应地增加为第一设备保留的资源，从而可以在满足第二设备对调度资源需求的前提下，及时地对为第一设备保留的资源量进行动态调整，相比于现有技术可以减少闲置资源，提高资源利用率，因此，可以部分或全部地解决现有技术的问题。

基于图1中的方法，本申请实施例还提供了该方法的一些具体实施方案，以及扩展方案，下面进行说明。

在本申请实施例中，考虑到在实际应用中不可能无限量地为第一设备保留资源，因此，可以为第一设备预先设定可保留资源额度，随着为第一设备保留的资源量增加，该可保留资源额度相应地减少。进一步地，由于之所以为第一设备保留资源，是因为调度了第一设备的资源给第二设备，因此，还可以为第二设备预先设定可调度获得资源额度，以用于限定第二设备可通过调度获得的第一设备的资源量，从而也有利于防止为第一设备保留过多的资源。

基于上一段中设定的额度，对于步骤S102，为所述第一设备增量地保留资源，具体可以包括：为所述第一设备增量地保留资源，减少第一设备的可保留资源额度，并相应地减少所述第二设备的可调度获得资源额度。

在本申请实施例中，执行主体可以采用多种方式，确定将第一设备的资源调度给第二设备。

例如，对于步骤S101，确定将第一设备的资源调度给第二设备，具体可以包括：根据第一设备和/或第二设备的调度信息，确定将第一设备的资源调度给第二设备。

若调度操作将由执行主体直接执行，则调度信息也可以由执行主体生成，无需从其他设备获取；而若调度操作将由其他设备直接执行，则执行主体可以从其他设备获取调度信息。其中，调度信息可以是尚未执行的调度指令以其相关信息，也可以是资源调度操作执行完毕后生成的调度日志，等等。

除了调度信息以外，执行主体还可以根据自身执行的调度操作，或者，针对其他设备的问询操作等，直接确定将第一设备的资源调度给第二设备。

在本申请实施例中，在为第一设备增量地保留资源时，为了尽量地减少闲置资源，可以严格地根据调度给第二设备的资源量，确定增量保留的资源量。

具体地，对于S101，每当确定将第一设备的资源调度给第二设备时，为所述第一设备增量地保留资源，可以包括：每当确定将第一设备的资源调度给第二设备时，为所述第一设备增量地保留资源，所增量保留的资源量不小于所述调度的资源量。优选地，所增量保留的资源量等于所述调度的资源量，如此，可以使得在所保留的资源足够应付第二设备未及时归还资源情况的前提下，尽量减少了闲置资源，有利于提高资源利用率。

需要说明的是，在实际应用中，可能有多个第一设备，则未必有足够的资源保留给每个第一设备，在这种情况下，对于某些第一设备，所增量保留的资源量也可以小于调度的资源量。

在本申请实施例中，第二设备的可调度获得资源额度通常不是由第二设备能够自主决定的，第二设备在大多数情况下，也未必需要把该可调度获得资源额度消耗殆尽，第二设备对于需要调度多少资源也可能有自己的计划。考虑到这些情况，可以允许设置第二设备的调度阈值，所述调度阈值用于限定在所述调度周期内，可从所述第一设备调度给所述第二设备的单次最大资源量和/或最大资源总量，从而可以提高第二设备的自主性和灵活性。

调度阈值可以完全由第二设备自行设置，也可以由第二设备向诸如执行主体等其他设备发送请求后，由其他设备响应于该请求而设置。一般地，调度阈值不大于其对应的可调度获得资源额度。

上面对本申请提供的互联网资源调度方法进行了说明，为了便于更直观地理解该方法，本申请实施例还提供了该方法的一个实例，如下所示。

图2为本申请实施例提供的一种实际应用场景下，互联网资源调度方法的实施过程示意图。

在图2中，资源为存储空间，调度周期的长度为1个月。

月初时，应急资源库中未为第一设备保留存储空间，在该月内，调度服务器将第一设备空闲的存储空间向第二设备调度共10次，每次10GB，共计100GB，在每次调度时，同步地在应急资源库中未第一设备增量地保留10GB存储空间。

该月结束后，下个月时，若确定第二设备未向第一设备归还100GB存储空间，则从应急资源库中调度为第一设备保留的100GB，代替第二设备归还给第一设备。

以上为本申请实施例提供的互联网资源调度方法，基于同样的思路，本申请实施例还提供相应的装置，如图3所示。

图3为本申请实施例提供的一种互联网资源调度装置的结构示意图，该装置包括：

保留调度模块301，在一个调度周期内，每当确定将第一设备的资源调度给第二设备时，为所述第一设备增量地保留资源；

归还调度模块302，在所述调度周期结束时，若确定所述第二设备未对从所述第一设备调度的资源进行归还，则将为所述第一设备保留的资源调度给所述第一设备。

可选地，保留调度模块301为所述第一设备增量地保留资源，具体包括：

保留调度模块301为所述第一设备增量地保留资源，并相应地减少所述第二设备的可调度获得资源额度。

可选地，保留调度模块301确定将第一设备的资源调度给第二设备，具体包括：

保留调度模块301根据第一设备和/或第二设备的调度信息，确定将第一设备的资源调度给第二设备。

可选地，保留调度模块301每当确定将第一设备的资源调度给第二设备时，为所述第一设备增量地保留资源，具体包括：

保留调度模块301每当确定将第一设备的资源调度给第二设备时，为所述第一设备增量地保留资源，所增量保留的资源量不小于所述调度的资源量。

可选地，在所述担保周期内，所述装置还包括：

设置模块303，响应于所述第二设备的请求，对所述第二设备的调度阈值进行设置，所述调度阈值用于限定在所述调度周期内，可从所述第一设备调度给所述第二设备的单次最大资源量和/或最大资源总量。

可选地，在所述调度周期的开始时刻，为所述第一设备保留的资源量为零。

本申请实施例提供的互联网资源调度装置是与互联网资源调度方法一一对应的，因此，该装置也具有与该方法类似的有益技术效果，由于上面已经对该方法的有益技术效果进行了详细说明，因此，这里不再赘述该装置的有益技术效果。

本申请实施例提供的互联网资源调度方法及装置的发明思路还可以应用于其他场景，用于解决类似的问题。

例如，本申请实施例基于上述发明思路，还提供了一种担保方法及装置，用以解决现有技术中对于消耗型业务，无法提供担保服务的问题。下面进行说明。

在金融领域，银行、保险公司或担保公司等主体可以采用保函、信用支付等方式，为用户提供担保服务。以保函为例，保函又称保证书，是指上述主体(称为：担保方)响应于用户(称为：担保请求方)的请求，向第三方(称为：担保受益方)开立的一种书面信用担保凭证，保证在担保请求方未能按双方协议履行起责任或义务时，由担保方代其履行一定金额、一定期限范围内的某种支付责任或经济赔偿责任。

目前互联网形式的保函为在线开立的担保协议，形式上并非传统纸质凭证。在现有技术中，对于消耗型业务，无法提供在线保函包含或在线信用支付等担保服务，其中，消耗型业务是指按照实际使用量或实际使用效果付费的业务，比如，按数据流量付费的电信服务类业务、按使用效果点击量付费的互联网P4P类业务等。原因如下：

现有技术中的保函在创建时即需明确保函金额(担保金额)，也即，在保函票面上明确所担保的金额，通常是是担保请求方与担保受益方的交易货值的一定百分比，如20％、50％或100％全额等。

但是，对于消耗型业务，采用的是先使用后结算消费金额的模式，则在业务订购初期尚无法明确在接下来的一段时期的总消费金额，担保方无法确定担保金额，因此无法提供担保服务，从而给消费用户带来了不便。本申请实施例提供的一种担保方法及装置可以解决该问题。

图4为本申请实施例提供的一种担保方法的流程示意图。该方法的执行主体可以为担保方的设备、第一设备、或第二设备等。

图4中的方法的流程可以包括以下步骤：

S401：在一个担保周期内，每当确定担保请求方在担保受益方处产生消费金额时，为所述担保请求方提高担保金额。

在本申请实施例中，可以通过实时监控的方式，或者轮训监控，或者定时监控等方式，确定担保请求方是否在担保受益方处产生消费金额。需要说明的是，所述消费金额是指增量产生的消费金额。

在本申请实施例中，任一次(称为：本次)“确定担保请求方在担保受益方处产生消费金额时”可以指：本次担保请求方即将在担保受益方处产生消费金额但尚未产生时；或者，本次担保请求方在担保受益方处产生消费金额的过程中的某时刻；或者，本次担保请求方在担保受益方处已经产生消费金额后的某时刻。

因此，步骤S401中的“担保请求方在担保受益方处产生消费金额”和“为所述担保请求方提高担保金额”这两个动作可以是同时执行的，也可以是按照预定的先后顺序执行的。一般而言，这两个动作的同步性越好，则越有利于精确地为担保请求方动态调整担保金额。

S402：在所述担保周期结束时，若确定所述担保请求方未对在所述担保受益方处产生的消费金额进行结算，则将所述担保金额结算给所述担保受益方。

为了便于理解，将担保方法提到的概念与上述调度方法中的概念进行对照说明。担保周期对应于上述的调度周期，担保收益方对应于上述的第一设备，担保请求方法对应于上述的第二设备，担保方的设备对应于上述的调度服务器，消费金额对应于被调度给第二设备的第一设备的资源，担保金额对应于为第一设备保留的资源。

在本申请实施例中，若担保请求方在担保周期中结算了部分消费金额，则也可以相应地为担保请求方降低担保金额。

通过图1中的方法，在一个担保周期内，担保请求方在担保受益方处尚未产生消费金额时(一般包括该担保周期的开始时刻)，担保金额可以为零，此后，担保请求方在担保受益方处产生的每设定数量笔(一般为每笔)消费金额，相应地增加担保金额，从而无需在担保周期的开始时刻即确定总消费金额作为担保金额，而是可以及时地对担保金额进行动态调整，则对于消耗型业务，也可以提供担保服务，为消费用户带来了便利，因此，可以部分或全部地解决图4对应的现有技术中的问题。

基于图4中的方法，本申请实施例还提供了该方法的一些具体实施方案，以及扩展方案，下面进行说明。

在本申请实施例中，担保方一般不会无条件地为担保请求方担保，而是需要担保请求方提供相应的抵押物或信用记录，担保方可以根据担保请求方提供的这些物品或信息，确定担保请求方的授信额度，进而在该授信额度的范围内进行担保，以减少担保方的风险。

则对于步骤S401，为所述担保请求方提高担保金额，具体可以包括：根据所述担保请求方的授信额度，为所述担保请求方提高担保金额，并相应地减少所述授信额度。当授信额度没有剩余时，可以拒绝继续担保，还可以通知担保请求方和/或担保受益方，暂时拒绝或停止担保请求方和担保请求方与担保受益方之间的后续交易，以减少担保受益方的风险。

在本申请实施例中，对于步骤S101，确定担保请求方在担保受益方处产生消费金额，具体可以包括：根据担保请求方在担保受益方产生的账单信息，确定所述担保请求方在所述担保受益方处产生消费金额。

账单信息一般表现为单条消费流水记录或多条流水记录的集合，每条流水记录可以包含消费时间、所消费内容(例如，手机数据流量、云计算资源使用量)及其金额等信息。

在本申请实施例中，对于步骤S401，每当确定担保请求方在担保受益方处产生消费金额时，为所述担保请求方提高担保金额，具体可以包括：每当确定担保请求方在担保受益方处产生消费金额时，为所述担保请求方提高担保金额，所提高的额度不小于所述消费金额。优选地，所提高的额度等于所述消费金额，如此，可以使得担保金额足够的前提下，尽量减少了担保方的风险。

在本申请实施例中，在担保周期内，还可以执行：响应于所述担保请求方的请求，对所述担保请求方的使用额度进行设置，所述使用额度用于限定在所述担保周期内，所述担保请求方可在所述担保受益方处产生的单笔最大消费金额和/或最大消费金额总额。如此，可以提高担保请求方的自主性，有利于防止担保请求方不小心过度消费而造成的不必要损失。

进一步地，在实际应用中，担保请求方可以基于一个或多个已有参数差异化地设置使用额度，并将所设置的使用额度应用于其对应的参数所描述的使用场景中，从而有利于提高担保请求方的便利性。所述参数包括但不限于：用户标识、用户类型、业务标识、业务类型、日期、时间段，等等。

在本申请实施例中，前面已经提到，担保的具体实施方式可以有多种，比如，保函、信用支付等。以保函为例，保函金额即为所述担保金额。

对于步骤S401，在所述担保周期开始时，所述方法还包括：

响应于所述担保请求方的请求，为所述担保请求方创建保函，所述保函的保函金额用于担保在所述担保周期内，所述担保请求方在所述担保受益方处产生消费金额；进一步地，为所述担保请求方提高担保金额，具体可以包括：对所述保函包含进行修改，以提高所述保函金额。

进一步地，在实际应用中，担保方可能同时为多个担保请求方创建保函，以提供担保，基于上述担保方法，不同保函的保函金额可能需要频繁地进行动态调整，由此会涉及到大量账单信息。为了便于查询和管理，可以将各保函与对应的各账单信息进行关联，并进行持久化处理(比如，用诸如数据表等特定的数据结构保存该关联关系，并写入磁盘等掉电非易失存储设备中，等等)，以便于查询和管理。

例如，对于步骤S401，在所述担保周期开始时，还可以执行：为所述保函创建关联表，所述关联表用于关联所述保函与所述账单信息，以便于查询和管理。

在本申请实施例中，前面提到了担保方会根据担保请求方的授信额度进行担保，担保请求方还可以设置自己的使用额度。这两项参数都可能对担保请求方在担保受益方处进行的消费产生限制作用，以减少担保受益方和/或担保方的风险。

具体地，在一个担保周期内，担保请求方在担保受益方进行的消费所产生的消费金额是逐渐累计的；若设置有使用额度用于限定消费总金额，则在每一笔所述消费进行之前，可以预先判断该笔消费所产生的消费金额是否会导致累计的总消费金额超过使用额度，若是，则可以拒绝该笔消费；类似地，若未设置有使用额度但设置有授信额度，则在每一笔所述消费进行之前，可以预先判断该笔消费所产生的消费金额是否会导致对应提高后的担保金额超过授信额度，若是，则可以拒绝该笔消费。

上面对本申请实施例提供的担保方法进行了详细说明。为了便于理解，本申请实施例还提供了一种实际应用场景下，担保方法(可以称为：消耗型赊购赊销模式)的实施过程示意图，如图5所示。在该实际应用场景下，担保周期时长为1个月。

在图5中，在担保周期的开始时刻，担保请求方在担保受益方处产生的消费金额(也即，订单金额)为零，相应地，担保方(也即，担保机构)的保函金额也为零；随着担保请求方在该担保周期内的消费累计，用于记录消费金额的账单总金额在逐渐增加，相应地，担保机构根据账单逐渐提高保函金额；到该担保周期的结束时刻(也即，担保到期时，为次月25日)，账单总金额为10000元，相应地，保函金额此时也锁定为10000元；接下来，担保请求方应当根据账单总金额，将10000元结算给担保受益方，而若担保请求方并未按时履行该义务，则由担保方根据锁定的担保金额，将10000元以垫付的方式，结算给担保受益方，此后，担保方再与担保请求方进行交涉以拿回垫付的10000元。

根据以上对图5中过程的分析，对于担保受益方，无论如何都能够按时收到10000元，利益不会受到损失，对于担保请求方，即使对于消耗型业务，也可以享受到先消费后付费的服务，体验较好，对于担保方，由于可以通过抵押物、信用记录等来约束担保请求方，则不用担心担保请求方不履行还款义务，而且担保金额的可控性和灵活性也很好。综上所述，这种担保方法在实际应用中可以正常运行，而且风险较小。

进一步地，在实际应用中，该担保方法会涉及担保请求方、担保受益方，以及担保方等多端之间的交互，为了便于理解可能这些交互过程，本申请实施例还提供了一种实际应用场景下，担保方法的交互过程时序图，如图6所示。

在图6中，包含有四端：担保请求方、担保受益方、数据访问层和担保方，其中，数据访问层具体可以为担保受益方与担保方之间的网关设备。

交互流程主要分为三大部分。第一、创建以及查询关联表；第二、创建保函；第三、修改保函。其中，担保请求方通过下订单在担保受益方处进行消费，支付单及支付明细(也可以是账单)可以用于记录担保请求方在担保受益方处的消费及已担保情况，关联表用于关联保函与具体的订单或者支付单等信息，以便于查询和管理。

需要说明的是，图6中的交互过程只是示例，并非对本申请的限定，在实际应用中，交互过程中的逻辑和涉及的交互信息也可能发生改变。

以上为本申请实施例提供的担保方法，基于同样的思路，本申请实施例还提供相应的装置，如图7所示。

担保模块701，在一个担保周期内，每当确定担保请求方在担保受益方处产生消费金额时，为所述担保请求方提高担保金额；

结算模块702，在所述担保周期结束时，若确定所述担保请求方未对在所述担保受益方处产生的消费金额进行结算，则将所述担保金额结算给所述担保受益方。

可选地，担保模块701为所述担保请求方提高担保金额，具体包括：

担保模块701根据所述担保请求方的授信额度，为所述担保请求方提高担保金额，并相应地减少所述授信额度。

可选地，担保模块701确定担保请求方在担保受益方处产生消费金额，具体包括：

担保模块701根据担保请求方在担保受益方产生的账单信息，确定所述担保请求方在所述担保受益方处产生消费金额。

可选地，担保模块701每当确定担保请求方在担保受益方处产生消费金额时，为所述担保请求方提高担保金额，具体包括：

担保模块701每当确定担保请求方在担保受益方处产生消费金额时，为所述担保请求方提高担保金额，所提高的额度不小于所述消费金额。

可选地，所述装置还包括：

设置模块703，在所述担保周期内，响应于所述担保请求方的请求，对所述担保请求方的使用额度进行设置，所述使用额度用于限定在所述担保周期内，所述担保请求方可在所述担保受益方处产生的单笔最大消费金额和/或最大消费金额总额。

可选地，在所述担保周期的开始时刻，所述担保金额为零。

可选地，所述担保金额为保函金额；在所述担保周期开始时，所述装置还包括：

保函模块704，响应于所述担保请求方的请求，为所述担保请求方创建保函，所述保函的保函金额用于担保在所述担保周期内，所述担保请求方在所述担保受益方处产生消费金额；

担保模块701为所述担保请求方提高担保金额，具体包括：

担保模块701对所述保函进行修改，以提高所述保函金额。

可选地，在所述担保周期开始时，所述装置还包括：

关联表模块705，在所述担保周期开始时，为所述保函创建关联表，所述关联表用于关联所述保函与所述账单信息，以便于查询和管理。

本申请实施例提供的担保装置是与担保方法一一对应的，因此，该装置也具有与该方法类似的有益技术效果，由于上面已经对该方法的有益技术效果进行了详细说明，因此，这里不再赘述该装置的有益技术效果。

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

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

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

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

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

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

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

Claims (11)

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

将第一设备的资源调度给第二设备，为所述第一设备增量地保留资源，所述资源应用于按照实际使用量或实际使用效果付费的互联网资源业务；其中，在一个调度周期内，每当确定将所述第一设备的资源调度给所述第二设备时，为所述第一设备增量地保留资源，并相应地减少所述第二设备的可调度获得资源额度，所增量保留的资源量不小于所调度的资源量；

若确定所述第二设备未对从所述第一设备调度的资源进行归还，则将为所述第一设备保留的资源调度给所述第一设备。

2.如权利要求1所述的方法，所述方法，还包括：

若确定所述第二设备已对从所述第一设备调度的资源进行了归还，则将为所述第一设备保留的资源释放，开始下一个调度周期。

3.如权利要求1或2所述的方法，所述第二设备归还资源的期限为调度周期结束的时刻。

4.如权利要求1所述的方法，确定将第一设备的资源调度给第二设备，具体包括：

根据所述第一设备的调度信息，确定将所述第一设备的资源调度给所述第二设备；

和/或，根据所述第二设备的调度信息，确定将所述第一设备的资源调度给所述第二设备。

5.如权利要求1所述的方法，确定将第一设备的资源调度给第二设备，具体包括：

根据所述第一设备自身执行的调度操作，将第一设备的资源调度给第二设备；

或者，根据所述第二设备自身执行的调度操作，将第一设备的资源调度给第二设备；

或者，根据其他设备的问询操作，确定将第一设备的资源调度给第二设备。

6.如权利要求1所述的方法，所述方法还包括：

响应于所述第二设备的请求，对所述第二设备的调度阈值进行设置，所述调度阈值用于限定可从所述第一设备调度给所述第二设备的单次最大资源量和/或最大资源总量。

7.如权利要求1所述的方法，在所述调度周期的开始时刻，为所述第一设备保留的资源量为零。

8.一种互联网资源调度装置，包括：

保留调度模块，将第一设备的资源调度给第二设备，为所述第一设备增量地保留资源，所述资源应用于按照实际使用量或实际使用效果付费的互联网资源业务；其中，在一个调度周期内，每当确定将所述第一设备的资源调度给所述第二设备时，为所述第一设备增量地保留资源，并相应地减少所述第二设备的可调度获得资源额度，所增量保留的资源量不小于所调度的资源量；

归还调度模块，若确定所述第二设备未对从所述第一设备调度的资源进行归还，则将为所述第一设备保留的资源调度给所述第一设备。

9.如权利要求8所述的装置，所述装置，还用于：

若确定所述第二设备已对从所述第一设备调度的资源进行了归还，则将为所述第一设备保留的资源释放，开始下一个调度周期。

10.如权利要求8所述的装置，所述保留调度模块，具体用于：

根据所述第一设备的调度信息，确定将所述第一设备的资源调度给所述第二设备；

和/或，根据所述第二设备的调度信息，确定将所述第一设备的资源调度给所述第二设备。

11.如权利要求8所述的装置，所述装置还包括：

设置模块，响应于所述第二设备的请求，对所述第二设备的调度阈值进行设置，所述调度阈值用于限定可从所述第一设备调度给所述第二设备的单次最大资源量和/或最大资源总量。