资源的处理方法及装置与流程

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

背景技术：

随着网络技术的不断发展，计算机设备可以为用户提供的资源也日趋多样化，如，计算机设备为用户提供缓冲存储资源。

目前，在现有技术中，针对计算机设备提供的任一类型的资源，计算机设备在将该资源提供给用户之前，需要先确定用户的资源使用权限，也就是，用户能够使用的最大资源量。在确定用户的资源使用权限时，用户可将资源申请信息发送给计算机设备。计算机设备在接收到用户发送的资源申请信息后，可根据资源申请信息确定出用户的资源使用权限。后续，当用户使用计算机设备提供的该资源时，可在计算机设备上执行资源获取的操作，以此生成资源获取请求。计算机设备在接收到用户的资源获取请求后，根据资源获取请求中携带的资源类型和资源数量，获取到对应的资源，并将资源提供给用户。

例如，假设云存储服务商只为注册过用户名的用户提供云存储空间(即，资源)，用户通过互联网提交用户的身份信息的方式，在云存储服务商的服务器注册了用户名。云存储服务商从而可为用户提供云存储空间。后续，用户准备在云存储服务商的服务器获取一定量的云存储空间，例如10g的云存储空间。这时，用户在计算机终端上执行云存储空间获取的操作，云存储服务商的服务器接收到用户输入的获取云存储空间的申请时，可以从云存储服务商的服务器剩余的云存储空间从划分出用户申请的一定容量的云存储空间。

但是，考虑到在实际应用中，用户申请新申请的云存储空间容量不能大于云存储服务商的服务器剩余的云存储空间，以免带来云存储空间的透支。因此， 在处理云存储空间申请的过程中，需要逐一比较用户新申请的云存储空间的容量与云存储服务商的服务器剩余的容量。然后，将该用户新申请的云存储空间的容量与云存储服务商的服务器剩余的容量记录下来。记录成功后，云存储服务商后续为用户分配云存储空间。当用户量众多时，计算机设备逐一处理云存储空间的申请，申请顺序排在后面的用户会存在明显的排队等待时间，资源申请处理效率低，从而使得用户体验满意度差。

因此，需要提供一种管控资源透支风险，并且处理资源申请效率高、用户体验满意度好的技术方案。

技术实现要素：

本申请实施例提供一种管控资源透支风险，并且处理资源申请效率高、用户体验满意度好的技术方案。

具体的，一种资源处理的方法，计算机在配置下执行以下步骤：

接收一个批次的资源申请；

确定所述批次的资源申请对应的总量；

确定业务系统的资源结余量；

当所述总量不大于所述资源结余量时，向所述业务系统发出资源申请记录成功的消息，使业务系统为进行所述批次的资源申请对应的用户分配资源。

本申请实施例还提供另一种资源处理的方法，计算机在配置下执行以下步骤：

接收一个批次内的、针对一个账号的业务付款请求；

确定所述批次内的、针对所述账号的付款总金额；

确定业务系统中所述账号的资金余额；

当所述付款总金额不大于所述资金余额时，向业务系统发出业务付款请求记录成功的消息，使业务系统为提出业务付款请求的用户分配资金。

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

接收模块，用于接收一个批次的资源申请；

解析模块，用于确定所述批次的资源申请对应的总量；

计算模块，用于确定业务系统的资源结余量；

处理模块，当所述总量不大于所述资源结余量时，向业务系统发出资源申请记录成功的消息，使业务系统为进行所述批次的资源申请对应的用户分配资源。

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

接收模块，用于接收一个批次内的、针对一个账号的业务付款请求；

解析模块，用于确定所述批次内的、针对所述账号的付款总金额；

计算模块，用于确定业务系统中所述账号的资金余额；

处理模块，用于当所述付款总金额不大于所述资金余额时，向业务系统发出业务付款请求记录成功的消息，使业务系统为提出业务付款请求的用户分配资金。

本申请实施例提供的信息的输入方法和系统，至少具有如下有益效果：

一个批次的资源申请与资源结余量比较一次，当资源申请总量不大于资源结余量时，向业务系统发出申请记录成功的消息，使业务系统为进行资源申请的用户分配资源。从而，可以在防止资源透支的前提下，向业务系统发出申请记录成功的消息，使得业务系统为进行资源申请的用户分配资源，从而提高资源申请的处理效率，降低用户的排队等待时间，提高用户体验满意度。

附图说明

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

图1为本申请实施例提供的资源的处理方法的过程示意图。

图2为本申请实施例提供的另一种资源的处理方法的过程示意图。

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

具体实施方式

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

请参照图1，为本申请实施例提供的资源的处理方法，具体包括以下步骤：

s01：接收一个批次的资源申请。

用户通过互联网提交用户的身份信息的方式，在云存储服务商的服务器注册了用户名。云存储服务商从而可为用户提供云存储空间。后续，用户准备在云存储服务商的服务器获取一定量的云存储空间时，用户在计算机终端上执行云存储空间获取的操作。云存储服务商的服务器接收到用户输入的获取云存储空间的申请时，可以从云存储服务商的服务器剩余的云存储空间从划分出用户申请的一定容量的云存储空间。在一定时间段内，多个用户可以向云存储服务商的服务器发出这样的资源申请。

一定数量的资源申请，或者，一个时间段内的资源申请可以作为一个批次的资源申请。例如，500个资源申请，或者，1分钟内的资源申请可以作为一个批次的资源申请。服务器可以通过数据传输协议接收一个批次的资源申请。当然，一个批次的资源申请可以涉及多个用户，也可以仅涉及一个用户。

s02：确定所述批次的资源申请对应的总量。

服务器可以以解析资源申请的方式，确定该批次的资源申请中涉及的资源申请总量，例如，云存储空间的容量等。

s03：确定业务系统的资源结余量。

服务器可以根据资源总量与已经分配完毕的资源量两者之差，算得业务系统的资源结余量。例如，云存储空间剩余1t的容量。

进一步的，在本申请提供的另一种实施例中，确定业务系统的资源结余量，具体包括：

确定实际结余量和用户释放量；

确定二者之和，作为资源结余量。

业务系统的资源结余量可以包括业务系统的实际结余量和用户释放出的资源。具体的，例如，服务器在对云存储空间分配后实际结余10t的存储容量，然而，在一个批次的资源申请时，有若干用户共释放出了5t的存储容量，则该5t的云存储空间可以被进一步进行分配，可以将10t的云存储空间存储容量和5t的云存储空间存储容量两者之和15t的云存储空间存储容量，作为云存储空间的结余量。这样，可以动态地管理资源结余量，从而可以在防止资源透支风险的前提下，提高资源申请的处理效率。

s04：当所述总量不大于所述资源结余量时，向所述业务系统发出资源申请记录成功的消息，使业务系统为进行所述批次的资源申请对应的用户分配资源。

当批次的资源申请对应的总量不大于资源结余量时，说明服务器的资源未被透支，则可以向用户进行分配。例如，一个批次的云存储空间申请总量为1t，而此时服务器的云存储空间结余量为大于或等于1t，则向业务系统发出申请记录成功的消息，使业务系统为进行资源申请的用户分配资源。

在本申请提供的实施例中，一个批次的资源申请对应的总量与资源结余量比较一次，当批次的资源申请对应的总量不大于资源结余量时，向业务系统发出资源申请记录成功的消息，使业务系统为进行该批次的资源申请对应的用户分配资源。从而，可以在防止资源透支的前提下，向业务系统发出资源申请记录成功的消息，使得业务系统为进行该批次的资源申请对应的用户分配资源，从而提高资源申请的处理效率，降低用户的排队等待时间，提高用户体验满意 度。

进一步的，在本申请提供的另一种实施例中，当所述总量不大于资源结余量时，向业务系统发出资源申请记录成功的消息，具体包括：

当所述总量不大于资源结余量时，即时向业务系统发出资源申请记录成功的消息；

在发出资源申请记录成功的消息后的预设时间内，逐个处理该批次内用户的资源申请，形成资源处理记录。

在该实施例中，向业务系统发出资源申请记录成功的消息的时间与逐个处理批次内用户的资源申请的时间具有预设时间的间隔，从而，可以方便服务器集中计算资源申请的总量，防止出现资源透支，而在服务器计算完毕资源申请总量后的空闲时间内，逐个处理该批次内用户的资源申请，形成资源处理记录。具体的，假设，有1万个用户在1分钟内向服务器发出云存储空间的申请，当该云存储空间的申请总容量不大于服务器的云存储空间的结余容量时，可以即时向业务系统发出申请记录成功的消息，以便继续计算下1分钟内的云存储空间的申请。在服务器完成计算的空闲时间内，则逐个处理该批次内用户的资源申请，形成资源处理记录，这样可以平衡服务器的任务负荷量，提高处理效率。例如，服务器处理甲用户的资源申请，形成处理完毕甲用户的资源申请后的云储存空间结余容量，接着顺序处理乙用户的资源申请，形成处理完毕乙用户的在资源申请后的云储存空间结余容量。

进一步的，在本申请提供的另一种实施例中，所述方法还包括：

当所述总量大于所述资源结余量时，向业务系统发出资源申请记录失败的中间消息。

具体的，例如，有1万个用户在1分钟内向服务器发出云存储空间的申请，云存储空间的申请总容量为10t，而此时，服务器的云存储空间的结余量仅有5t，则向业务系统发出云存储空间申请记录失败的中间消息。当总量大于资源结余量时，服务器向业务系统发出云存储空间申请记录失败的中间消息，可以 及时作出反馈，以便后续进行针对的处理，从而可以提高资源申请的处理效率。

进一步的，在本申请提供的另一种实施例中，所述方法还包括：

以一个批次为单元，查找第一数量的批次，使得该第一数量的批次内的资源申请对应的所述总量不大于所述资源结余量，向业务系统发出第一数量的批次的资源申请记录成功的消息。

具体的，仍以上面的情形为例，有1万个用户在1分钟内向服务器发出云存储空间的申请，云存储空间的申请总容量为10t，而此时，服务器的云存储空间的结余量仅有5t，则向业务系统发出云存储空间申请记录失败的中间消息。假设，划分批次是以时间为参照，例如，以1分钟内的资源为一个批次。那么，可以查找10个批次的资源申请，在该10个批次内，假设云存储空间的申请总容量为50t，服务器的云存储空间的实际结余量仅有5t，而用户释放出的云存储空间容量为60t，在该10个批次的资源申请的云存储空间的资源申请对应的总量50t不大于65t的云存储空间的资源结余量，则可以向业务系统发出10个批次的云存储空间申请记录成功的消息，使业务系统为进行资源申请的对应的用户分配资源。这样可以在防止资源透支的前提下，一次性处理若干批次的资源申请，提高资源申请的处理效率。

下面介绍一种本申请实施例的具体的应用场景：

云存储服务商的服务器接收到一个批次的云存储空间的申请，例如，500个云存储空间的申请。服务器解析该批次的云存储空间的申请，假设，确定该批次的云存储空间的申请要求获得1t容量的云存储空间。服务器根据云存储空间总量与已经分配完毕的云存储空间两者之差，算得云存储空间的结余量。假设，算得的云存储空间的结余量大于或等于1t的云存储空间的申请容量时，服务器向分配云存储空间的业务系统发出云存储空间申请记录成功的消息，使业务系统为进行该批次的云存储空间申请对应的用户分配资源。而当算得的云存储空间的结余量小于1t的云存储空间的申请容量时，服务器向分配云存储空间的业务系统发出云存储空间申请记录失败的中间消息，以便后续处理。后 续处理可以是查找第一数量的批次，使得该第一数量的批次内的云存储空间的申请对应的总量不大于云存储空间的结余量。

进一步的，请参照图2，本申请还提供另一种资源处理的方法，计算机在配置下执行以下步骤：

s11：接收一个批次内的、针对一个账号的业务付款请求。

业务系统发生实际业务时，向服务器发出针对该业务的付款请求。例如，某用户甲发生一笔交易，需要向对方支付一笔款项。在业务高并发的情形下，例如，1分钟内用户甲的账号有5000次的业务付款请求。服务器可以接收一个批次的、针对该账号的业务付款请求。当然，这里的一个批次的针对一个账号的业务付款请求，同样可以是若干笔业务付款请求，也可以是，一个周期内的业务付款请求，具体的例如，5000笔业务付款请求，或者，1分钟内的业务付款请求。

s12：确定所述批次内的、针对所述账号的付款总金额。

服务器可以以解析业务付款请求的方式，确定该批次的业务付款请求涉及的付款总金额。

s13：确定业务系统中所述账号的资金余额。

服务器可以查询获得所述账号的资金余额。

进一步的，在本申请提供的另一种实施例中，确定业务系统中所述账号的资金余额，具体包括：

确定实际资金余额和针对所述账号的资金汇入金额；

确定所述实际资金余额和所述资金汇入金额二者之和，作为资金余额。

账号的资金余额可以包括业务系统中该账号在业务付款请求前的实际资金余额和处理业务付款请求时该账号的资金汇入金额。具体的，例如，该账号在业务系统中在业务付款请求提出前实际资金余额为10万元，而在处理业务付款请求时，该账号又有5万元的资金汇入，则可以将实际资金余额10万元和5万元的汇入金额之和15万元作为资金余额。这样，可以动态地管理该账 号下的资金，从而可以在防止资金透支风险的前提下，提高业务付款请求的处理效率。

s14：当所述付款总金额不大于所述资金余额时，向业务系统发出业务付款请求记录成功的消息，使业务系统为提出业务付款请求的用户分配资金。

服务器可以比较批次内的、针对所述账号的付款总金额和资金余额，当付款总金额不大于资金余额时，向业务系统发出业务付款请求记录成功的消息，以便业务系统为提出业务付款请求的用户分配资金——付款。

在本申请提供的实施例中，一个批次的业务付款请求对应的付款总金额与资金余额比较一次，当付款总金额不大于资金余额时，向业务系统发出业务付款请求记录成功的消息，使业务系统为提出业务付款请求的用户分配资金——付款。从而，可以在防止资金透支的前提下，向业务系统发出业务付款请求记录成功的消息，使得业务系统为提出业务付款请求的用户分配资金，从而提高业务付款请求的处理效率，降低用户的排队等待时间，提高用户体验满意度。

进一步的，在本申请提供的又一实施例中，当所述付款总金额不大于所述资金余额时，向业务系统发出业务付款请求记录成功的消息，具体包括：

当所述付款总金额不大于所述资金余额时，即时向业务系统发出业务付款请求记录成功的消息；

在发出业务付款请求记录成功的消息后的预设时间内，逐个处理批次内、针对所述账号的业务付款请求，形成资金处理记录。

具体的，例如，当付款总金额不大于资金余额时，服务器即时向业务系统发出业务付款请求记录成功的消息，在发出业务付款请求记录成功的消息后的10分钟内，服务器逐个处理批次内、针对所述账号的业务付款请求，形成该账号的资金余额变动明细记录。当然，还可以将业务付款请求时的各种单据以附件的形式存档。在服务器完成账号资金余额计算以及确定批次的业务付款请求总额计算的空闲时间内，逐个处理该批次内用户的业务付款请求，形成该账号的资金余额变动明细记录，这样可以平衡服务器的任务负荷量，提高处理效 率。

进一步的，在本申请提供的另一种实施例中，所述方法还包括：

当所述付款总金额大于所述资金余额时，发出业务付款请求记录失败的中间消息。

具体的，例如，有1万个用户在1分钟内向服务器发出业务付款请求，业务付款请求的付款总金额为10万元，而此时，该账号的资金余额仅有5万元，则向业务系统发出业务付款请求记录失败的中间消息。当付款总金额大于资金余额时，服务器向业务系统发出业务付款请求记录失败的中间消息，可以及时作出反馈，以便后续进行针对的处理，从而可以提高业务付款请求的处理效率。

进一步的，在本申请提供的另一种实施例中，所述方法还包括：

以一个批次为单元，查找第一数量的批次，使得该第一数量的批次内的针对一个账号的业务付款请求对应的所述付款总金额不大于所述资金余额，向业务系统发出第一数量的批次的业务付款请求记录成功的消息。

具体的，仍以上面的情形为例，有1万个用户在1分钟内向服务器发出业务付款请求，付款总金额为10万元，而此时，该账号的资金余额仅有5万元，则向业务系统发出业务付款请求记录失败的中间消息。假设，划分批次是以时间为参照，例如，以1分钟内的资源为一个批次。那么，可以查找10个批次的业务付款请求，在该10个批次内，假设付款总金额为50万元，该账号的实际资金余额仅有5万元，而该针对账号的资金汇入金额为60万元，在该10个批次的业务付款请求的付款总金额50万元不大于资金余额65万元，则可以向业务系统发出10个批次的业务付款请求记录成功的消息，使业务系统为提出业务付款请求的用户付款。这样可以在防止资金透支的前提下，一次性处理若干批次的业务付款请求，提高业务付款请求的处理效率。

下面介绍一种本申请实施例的具体的应用场景：

服务器接收到一个批次的业务付款请求，例如，500笔业务付款请求。服务器解析该批次的业务付款请求，假设，确定该批次的业务付款请求要求付款 1万元。服务器根据该账号的总金额与已经付款完毕的金额两者之差，算得资金余额。假设，算得的资金余额大于或等于1万元时，服务器向分配资金的业务系统发出业务付款请求记录成功的消息，使业务系统为进行提出业务付款请求的用户分配资金。而当算得的资金余额小于1万元时，服务器向分配资金的业务系统发出业务付款请求记录失败的中间消息，以便后续处理。后续处理可以是查找第一数量的批次，使得该第一数量的批次内的付款总金额不大于资金余额。

以上是本申请实施例提供的资源的处理方法，基于同样的思路，请参照图3，本申请还提供一种资源处理的装置1，包括：

接收模块11，用于接收一个批次的资源申请；

解析模块12，用于确定所述批次的资源申请对应的总量；

计算模块13，用于确定业务系统的资源结余量；

处理模块14，当所述总量不大于所述资源结余量时，向业务系统发出资源申请记录成功的消息，使业务系统为进行所述批次的资源申请对应的用户分配资源。

进一步的，在本申请提供的又一实施例中，所述装置还包括调度模块15；

所述调度模块15，用于：

当所述总量不大于所述资源结余量时，即时向业务系统发出资源申请记录成功的消息；

在发出申请记录成功的消息后的预设时间内，逐个处理批次内用户的资源申请，形成资源处理记录。

进一步的，在本申请提供的又一实施例中，所述计算模块13用于：

确定所述业务系统的实际结余量和所有用户释放资源的释放量；

确定所述实际结余量和所述释放量二者之和，作为资源结余量。

进一步的，在本申请提供的又一实施例中，所述处理模块14用于：

以一个批次为单元，查找第一数量的批次，使得该第一数量的批次内的资 源申请总量不大于资源结余量，向业务系统发出第一数量的批次的资源申请记录成功的消息。

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

接收模块11，用于接收一个批次内的、针对一个账号的业务付款请求；

解析模块12，用于确定所述批次内的、针对所述账号的付款总金额；

计算模块13，用于确定业务系统中所述账号的资金余额；

处理模块14，用于当所述付款总金额不大于所述资金余额时，向业务系统发出业务付款请求记录成功的消息，使业务系统为提出业务付款请求的用户分配资金。

进一步的，在本申请提供的又一实施例中，所述装置还包括调度模块15；

所述调度模块15，用于：

当所述付款总金额不大于所述资金余额时，即时向业务系统发出业务付款请求记录成功的消息；

在发出业务付款请求记录成功的消息后的预设时间内，逐个处理批次内、针对所述账号的业务付款请求，形成资金处理记录。

进一步的，在本申请提供的又一实施例中，所述计算模块13，用于：

确定实际资金余额和针对所述账号的资金汇入金额；

确定所述实际资金余额和所述资金汇入金额二者之和，作为资金余额。

进一步的，在本申请提供的又一实施例中，所述处理模块14，用于：

以一个批次为单元，查找第一数量的批次，使得该第一数量的批次内的针对一个账号的业务付款请求对应的所述付款总金额不大于所述资金余额，向业务系统发出第一数量的批次的业务付款请求记录成功的消息。

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

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

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

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

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

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

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

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

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

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