CN108270581A - 共享资源计费处理方法及装置 - Google Patents

Abstract

本发明公开了共享资源计费处理方法及装置，该方法包括：采用接收计费请求，其中所述计费请求包括对共享资源的使用量；响应于所述计费请求，从多个分片中选择至少一个分片，其中，所述共享资源被分为多个分片；锁定选择出的所述至少一个分片，其中，被锁定的分片不能被其他计费请求选择；根据所述计费请求从锁定的所述至少一个分片中进行所述使用量的计费处理。通过本发明实施例能够解决大量用户共享同一个资源时计费冲突的处理问题，在避免计费误差的前提下，保障了处理效率，减少了计费处理时的加锁等待。

Description

共享资源计费处理方法及装置

技术领域

本发明涉及通讯领域，具体而言，涉及共享资源计费处理方法及装置。

背景技术

电信行业计费账务领域处理共享类业务过程中，当出现多个用户产生并发的计费处理请求时经常会出现冲突，导致计费问题的出现，具体问题以流量共享类业务为例，如4个用户同时共享500M流量。计费***会对这4个用户创建一个虚拟群，在这些用户使用过程中，计费***会记录这些用的实际使用量(以下称：已用量)，当用户累加的使用量小于可用量时，免费；大于可用量时，按实际使用流量超出的量扣费。用户的使用记录会记录到计费***的BDS内存库该用户对应的记录上；在每次计费处理过程中，都会检测数据库记录的已用量是否超出可用量，用来判断是否需要收费或免费。

使用量扣减实例：加入数据记录为500M共享流量，已使用到498M，数据记录如下表一，表一表示扣减前的情况。

可用量500M记录在下表“用户ID”＝0的记录的可用上，每个用户的明细记录中不记录可用量，只记录该用户的可用量。各用户的已用量之和＝30+50+118+300＝498M。

表一

虚拟群ID	使用量ID	用户ID	可用量	已用量	账务周期	……
							31891320001	7651	0	500M	0	201603
31891320001	7651	31000000001	0	30M	201603
							31891320001	7651	31000000002	0	50M	201603
31891320001	7651	31000000003	0	118M	201603
							31891320001	7651	31000000004	0	300M	201603

当“用户ID”＝31000000001时，使用了1M，此用户记录的“已用量”由在表一中的30M，变成表二中的31M。如下表二，表二表示扣减后的情况。

表二

虚拟群ID	使用量ID	用户ID	可用量	已用量	账务周期	……
							31891320001	7651	0	500M	0	201603
31891320001	7651	31000000001	0	31M	201603
							31891320001	7651	31000000002	0	50M	201603
31891320001	7651	31000000003	0	100M	201603
							31891320001	7651	31000000004	0	300M	201603
31891320001	7651	31000000005	0	18M	201603

扣减过程中，扣减前是需要知道这5个用户的已用量之和是否超出500M，如超出就需要进行收费处理。这种共享处理过程当出现多个用户产生并发的计费处理请求时会出现冲突，在现有技术中，计费***有两种常见方案来实现这种多用户共享同一个资源的计费冲突处理。

方案一：查询方式，如图2所示，在前述场景中，当用户实际使用中，计费***根据计费请求信息(在线计费为消息、离线计费为话单)，通过使用用数据查询的方式，如(表二)，查询条件为当次已用量+数据库中的已用量小于可用量，能查询到结果则说明可以进行共享资源扣减，反之不能。在可扣减时将当次的使用量累加到的数据库中的已用量上。此种方案弊端是，不会对用户的已用量记录加锁，在边界计费(已用量接近使用量时)，会产生计费误差，比如：

当前已用量之和已达到498M，此时A、B两个用户同时使用，A用户用了2M，B用户用了1M，计费***内两个进程同时对A、B用户进行计费，A、B用户会累加3M(A用户2M+B用户1M)到数据库中，而数据库中实际记录的使用量之和就变成了501M，导致超出的这1M是无法计费的，产生计费偏差，降低计费的准确性；

由于资源共享类业开展比较广泛，这种方式不对数据加锁，不会产生锁等待，并发处理效率较好，但是存在的缺陷是不会对用户的已用量记录加锁，而计费***是一个高并发处理***，此种方式超出部分无法计费，在边界计费时(已用量接近使用量时)，会产生计费误差。

方案二：加锁方式，如图3所示，在前述场景中，用户实际使用中，计费***根据计费请求信息(在线计费为消息、离线计费为话单)，通过使用数据更新加锁方式如(图2)对数据中对相关联的使用量记录进行加锁处理，更新条件为当次已用量+数据库中的已用量小于可用量，如更新到的记录是0则说明共享资源使用完毕。如加锁成功，则可进行扣减处理。如出现加锁等待，则说明其他进程正在处理需要等待其他进程释放锁。

由于同一时刻同一记录只会被同一个进程上锁，此时在方案一中描述的场景下不会产生计费误差，如：

当前已用量之和已达到498M，此时A、B两个用户同时使用，A用户用了2M，B用户用了1M，计费***内两个进程同时对A、B用户进行计费，在使用数据更新方式做冲突检测时，只会有一个进程更新成功，另外一个进程会产生上锁等待，或回滚重做。假设A用对应的进程更新成功了，此时数据库中可用量更新为是498M+2M＝500M，B用户再更新时，就不会更新成功，程序会在后继对其进行收费处理，不会产生方案一中的计费误差。

但是此种方式由于使用了更新加锁机制，导致同一时刻在同一个虚拟群内的用户只能有一个计费进程成功更新到数据，造成计费处理的串行处理的现象，例如，在进行资源共享类业务计费处理时，由于采用数据库加锁机制，会导致数据库压力变大，同时同一时刻只会有一个进程加锁成功，造成此环节的处理实际是串行的，影响并发处理效率。同时在用户变更共享使用量时(比如增加共享使用量xxM)，必须先锁定表2中的所有记录，在更新完“用户ID”＝0记录的“可用量”后释放锁；更新过程如有计费请求，也会产生锁等待，导致处理效率下降，影响处理效率。

目前，计费***支持的资源共享计费(如流量共享、流量池、时长共享)套餐、业务已经越来越多的推广，同一个资源的共享成员从原来的几个，变成现在的几百个、几千个，而4G流量业务是一个高频使用的业务，无论是上述的方案一还是方案二都已经不满足计费***的高并发处理要求。

针对上述在大量用户共享同一个资源时计费冲突的处理问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了共享资源计费处理方法及装置，能够解决大量用户共享同一个资源时计费冲突的处理问题。

根据本发明的一个方面，提供了一种共享资源计费处理方法，包括：接收计费请求，其中，所述计费请求包括对共享资源的使用量；响应于所述计费请求，从多个分片中选择至少一个分片，其中，所述共享资源被分为多个分片；锁定选择出的所述至少一个分片，其中，被锁定的分片不能被其他计费请求选择；根据所述计费请求从锁定的所述至少一个分片中进行所述使用量的计费处理。

进一步地，响应于所述计费请求，从所述多个分片中选择所述至少一个分片包括：获取所述计费请求对应的资源的使用量；获取所述多个分片中资源剩余量能够满足所述使用量的分片；从所述能够满足所述使用量的分片中选择出所述至少一个分片。

进一步地，响应于所述计费请求，从所述多个分片中选择所述至少一个分片包括：获取所述计费请求对应的资源的使用量；在所有的单个分片的资源剩余量均不能满足所述使用量的情况下，依次组合多个分片；从能够满足所述使用量的分片组合中选择出一组分片组合作为所述至少一个分片。

进一步地，响应于所述计费请求，从所述多个分片中选择所述至少一个分片包括：获取所述计费请求对应的资源的使用量；从所述多个分片中选择一个分片进行锁定；在选择出的分片的资源剩余量小于所述使用量的情况下，从所述多个分片中剩余的分片中再次选择一个分片并进行锁定，直到所述使用量小于等于选择出的分片的剩余量之和，或者，直到所有的分片均被选择。

进一步地，响应于所述计费请求，从所述多个分片中选择所述至少一个分片包括：获取所述计费请求对应的资源的使用量；在所有分片的资源剩余量之和均不能满足所述使用量的情况下，选择所有的分片作为所述至少一个分片；该共享资源计费处理方法还包括，对所述使用量中超过所述所有分片的资源剩余量之后的部分根据计费标准进行计费。

进一步地，根据所述计费请求从锁定的所述至少一个分片中进行所述使用量的计费处理包括：根据所述使用量从所述至少一个分片中进行扣减。

进一步地，从多个分片中选择至少一个分片是通过以下方式实现的：根据以下信息的至少之一计算得到HASH值：进程号、使用资源的用户的标识信息、分片的可扣减记录，其中，所述进程号是用于处理所述计费请求的进程的标识信息；从所述多个分片中选择分片标识与所述HASH值对应的所述至少一个分片。

根据本发明实施例的另一个方面，还提供了一种共享资源计费处理装置，包括：接收单元，用于接收计费请求，其中，所述计费请求包括对共享资源的使用量；选择单元，用于响应于所述计费请求，从多个分片中选择至少一个分片，其中，所述共享资源被分为多个分片；锁定单元，用于锁定选择出的所述至少一个分片，其中，被锁定的分片不能被其他计费请求选择；处理单元，用于根据所述计费请求从锁定的所述至少一个分片中进行所述使用量的计费处理。

进一步地，所述处理单元用于根据所述使用量从所述至少一个分片中进行扣减。

进一步地，所述选择单元包括：计算模块，用于根据以下信息的至少之一计算得到HASH值：进程号、使用资源的用户的标识信息、分片的可扣减记录，其中，所述进程号是用于处理所述计费请求的进程的标识信息；第一选择模块，用于从所述多个分片中选择分片标识与所述HASH值对应的所述至少一个分片。

进一步地，所述选择单元包括：第一获取模块，用于获取所述计费请求对应的资源的使用量；第二获取模块，用于获取所述多个分片中资源剩余量能够满足所述使用量的分片；第二选择模块，用于从所述能够满足所述使用量的分片中选择出所述至少一个分片。

进一步地，所述选择单元还包括：组合模块，用于在所有的单个分片的资源剩余量均不能满足所述使用量的情况下，依次组合多个分片；第三选择模块，用于从能够满足所述使用量的分片组合中选择出一组分片组合作为所述至少一个分片。

进一步地，所述选择单元包括：锁定模块，用于从所述多个分片中选择一个分片进行锁定；第四选择模块，用于在选择出的分片的资源剩余量小于所述使用量的情况下，从所述多个分片中剩余的分片中再次选择一个分片并进行锁定，直到所述使用量小于等于选择出的分片的剩余量之和，或者，直到所有的分片均被选择。

进一步地，所述选择单元包括：第五选择模块，用于在所有分片的资源剩余量之和均不能满足所述使用量的情况下，选择所有的分片作为所述至少一个分片；计费模块，用于对所述使用量中超过所述所有分片的资源剩余量之后的部分根据计费标准进行计费。

在本发明实施例中，采用接收计费请求，其中，所述计费请求包括对共享资源的使用量；响应于所述计费请求，从多个分片中选择至少一个分片，其中，所述共享资源被分为多个分片；锁定选择出的所述至少一个分片，其中，被锁定的分片不能被其他计费请求选择；根据所述计费请求从锁定的所述至少一个分片中进行所述使用量的计费处理。通过本发明实施例进而解决了大量用户共享同一个资源时计费冲突的处理问题，在避免计费误差的前提下，保障了处理效率，减少了计费处理时的加锁等待。

附图说明

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

图1是根据本发明实施例的一种共享资源计费处理方法的流程图；

图2是根据本发明现有技术方式一的流程图；

图3是根据本发明现有技术方式二的流程图；

图4是根据本发明实施例的以CBE融合计费集群为例的方法流程图；

图5是根据本发明实施例的分片处理的具体流程图；

图6是根据本发明实施例的每一个计费进程的处理过程流程图；

图7是根据本发明实施例的共享资源计费处理装置的结构框图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本发明的一个实施例提供了一种共享资源计费处理方法。图1是根据本发明实施例的共享资源计费处理方法的流程图。如图1所示，该流程包括如下步骤：

步骤S102，接收计费请求，其中，计费请求包括对共享资源的使用量；

步骤S104，响应于计费请求，从多个分片中选择至少一个分片，其中，共享资源被分为多个分片；

步骤S106，锁定选择出的至少一个分片，其中，被锁定的分片不能被其他计费请求选择；

步骤S108，根据计费请求从锁定的至少一个分片中进行所述使用量的计费处理。

在上述步骤中，通过将共享资源预先分配成多个片，根据情况选择需要锁定的片，每次处理计费请求时，一个计费进程只会加锁一个分片的可扣减记录，在同一时刻，其他计费进程可对其他可扣减记录进行加锁，与现有技术相比，不再是直接将剩余共享资源全部锁定，如果同时有多个用户发出查询剩余共享资源请求时，可以同时满足大量用户的请求，不再需要锁等待。规避了上锁带来的加锁等待，提升并发效率。此外，每次处理计费请求时，一个计费进程会锁定其中一个分片的可扣减记录进行扣减处理；确保计费的准确性，不会存在背景技术中方案一的导致的计费误差。解决了大量用户共享同一个资源时计费冲突的处理问题，在避免计费误差的前提下，保障了处理效率，减少了计费处理时的加锁等待。

在上述步骤S106选择分片的过程中，分片可以为一个也可以为多个，分片有多种选择的方式，第一种分片选择方式，在一个可选的实施方式中，当从多个分片中选择至少一个分片包括：

步骤S202，获取计费请求对应的资源的使用量；此处是指某个计费请求的用户还需要使用的资源量。

步骤S204，获取多个分片中资源剩余量能够满足使用量的分片；根据上述的用户还需要使用的资源量从多个分片中获取能够满足该使用量的分片。分片可以为一个也可以为多个。

步骤S206，从能够满足使用量的分片中选择出至少一个分片。

下面举例对上述步骤进行说明，如图4所示，图4代表以CBE融合计费集群为例本实施例的方法流程图：

计费账务处理***指电信企业计费账务处理的应用***，账务处理***为计费账务云，由CBE集群和BDS集群组成；

BDS集群：计费账务的数据分布在多主机(可以是X86主机和小型机，也可以是二者的混合集群)组成的集群，为了实现应用程序对数据访问的透明化，***提供了封装数据访问的计费账务数据服务(BDS)来实现数据的访问，BDS部署在X86集群，通过路由策略来为应用程序CBE提供数据访问服务，CBE集群只有通过BDS集群才能进行计费账务数据的访问；

CBE：融合计费引擎，为计费账务处理的应用程序，负责计费账务处理的功能实现。

在接收计费请求后对共享用户建立虚拟群以及对应的使用量记录表，将共享流量进行分片，每块分片使用分片ID作为标记。与背景技术中的表二相比，数据实体变更使用量记录表中，不再使用“用户ID”，不统计每个用户的使用量。针共享流量，引入“分片ID”并采用分片方式记录，将共享的流量分成N份，每片划分的额度可参数配置，如本文中共享500M流量的场景，每片100M，分成5片，记录如下表三：

表三

虚拟群ID	使用量ID	分片ID	可用量	已用量	账务周期	……
							31891320001	7651	1	100	0	201603
31891320001	7651	2	100	0	201603
							31891320001	7651	3	100	0	201603
31891320001	7651	4	100	0	201603
							31891320001	7651	5	100	0	201603

通过上述步骤在用户需要使用量不大时，单个的分片的资源剩余量能够满足所需要的使用量，适合该种选择方式，通过上述步骤可以快速找合适的分片。

在上述选择分片的过程中，第二种分片选择方式，当所有的单个分片的资源剩余量均不能满足使用量的情况下，在一个可选的实施方式中，依次组合多个分片；

从能够满足使用量的分片组合中选择出一组分片组合作为至少一个分片。

在从多个分片中选择一个分片时需要进行锁定，锁定的方式在一个可选的实施方式中为：

从多个分片中选择一个分片进行锁定；

下面结合一个可选的实施例对上述分片锁定的方式进行说明，如图5所示，图5是分片处理的具体流程图：

首先查询BDS内存库中可用共享资源分片，如存在可用分片则根据计算出的HashID锁定其中一个分片；如不存在可用分片，则表示共享资源已使用完毕，处理结束；

在锁定完成后，进行扣减处理；如当前分片的可用量减去已用量满足本次扣减需要，则在扣减后释放分片加锁，扣减结束；

如不满足则回到第一步。

在使用量变更时，直接按分片的大小对应增加各分片的使用量，不再对记录加锁，避免了锁等待。

在选择出的分片的资源剩余量小于使用量的情况下，从多个分片中剩余的分片中再次选择一个分片并进行锁定，直到使用量小于等于选择出的分片的剩余量之和，或者，直到所有的分片均被选择。

举例进行说明，参照图6所示，图6是每一个计费进程的处理过程流程图，当同一时刻有多个计费进程时，多条并发处理，进行冲突检测，每个计费进程按HASH(节点、进程号、用户号HASH)取模定位使用量表中的一分片记录，并进行加锁，更新已用量字段，不够扣除时，尝试加锁并扣除其他分片记录，采用多次hash确定扣减目标，直到扣减完成或者无法扣减(共享流量内已经对应的分片记录已无可用量大于已用量的记录)。上述每个计费进程按HASH取模定位使用量表中的一分片记录具体是，例如，hash值为进程号2012，一共有5个分片，则用2012除以5后余2，则先选择2号分片进行加锁。

通过上述实施方式可以更好的分配资源，减少冲突，减少等待时间。

在所有分片的资源剩余量之和均不能满足使用量的情况下，在一个可选的实施方式中，选择所有的分片作为至少一个分片；对使用量中超过所有分片的资源剩余量之后的部分根据计费标准进行计费。

在一个可选的实施方式中，根据计费请求从锁定的至少一个分片中进行计费处理包括：根据使用量从至少一个分片中进行扣减。使用量也可以在多个分片中分别进行扣减。

在共享资源计费处理时，从多个分片中选择至少一个分片的选择方法具体包括：根据以下信息的至少之一计算得到哈希(HASH)值：进程号、使用资源的用户的标识信息、分片的可扣减记录，其中，进程号是用于处理计费请求的进程的标识信息；从多个分片中选择分片标识与HASH值对应的至少一个分片。

下面举例对上述步骤进行说明：

每当接收到一次计费请求，产生一个计费进程，根据计费进程查找使用量记录表，根据表中各分片的可扣减记录进行哈希计算得到哈希(HASH)ID，然后根据哈希ID找到匹配的分片ID，当前计费进程锁定该分片ID，即对分片进行加锁；最后根据当前计费进程的使用量更新该分片ID对应的已用量，完成扣减动作，扣减完毕后，释放已加锁的使用量记录分片。

图6是根据本发明实施例的另一可选业务处理方法的流程图，如图6所示，图6是每一个计费进程的处理过程流程图，该流程可以包括如下步骤：

获取当前计费请求对应的使用量；

若所有分片中剩余量均小于使用量，则全部分片尝试加锁，重新查询分片的剩余量，然后从各分片中分摊扣减，若扣减失败，说明剩余量总额已不够当前扣减，则所有分片扣减完毕后，剩余的量另行计费。比如图5中，当前需要扣减5M，而所有分片中的剩余量总和只有4M，则所有分片扣减完成后，多出的1M流量根据计费标准进行计费。

若所有分片中存在剩余量大于使用量的分片，则筛选出这些分片，通过hash计算锁定对应的分片，然后尝试扣减，若扣减成功，则扣减接收并释放；若扣减失败则在其他的分片中继续采用哈希计算锁定一个分片，再次进行尝试扣减，直至找到合适的分片并扣减成功，如果最后仍扣减失败，则返回告警，或者全部分片尝试加锁，重新查询分片的剩余量，然后从各分片中分摊扣减。

通过上述实施例及可选的实施方式，取得如下技术效果：

既能确保计费***资源共享类业务的计费准确性，同时也能保障高并发状态下，资源共享类业务的计费处理效率，并降低数据的锁冲突概率，降低数据库的压力。具体的：每次处理计费请求时，一个计费进程会锁定其中一条可扣减记录，进行扣减处理；确保计费的准确性，不会存在方案一的导致的计费误差；每次处理计费请求时，一个进程只会加锁一个分片的可扣减记录，在同一时刻，其他进程可对其他可扣减记录进行加锁，规避了上锁带来的加锁等待，提升并发效率；使用量变更时，直接按分片的流量大小，增加分片ID记录到上述数据实体中，不再对记录加锁，避免锁等待；

在本实施例中，还提供了一种共享资源计费处理装置，图7是根据本发明实施例的共享资源计费处理装置的结构框图，如图7所示，该装置包括：

接收单元72，用于接收计费请求，其中，计费请求包括对共享资源的使用量；

选择单元74，用于响应于计费请求，从多个分片中选择至少一个分片，其中，共享资源被分为多个分片；

锁定单元76，用于锁定选择出的至少一个分片，其中，被锁定的分片不能被其他计费请求选择；

处理单元78，用于根据计费请求从锁定的至少一个分片中进行计费处理。

作为一个可选的实施方式，处理单元用于根据使用量从至少一个分片中进行扣减。

作为可选的实施方式，选择单元包括：

计算模块，用于根据以下信息的至少之一计算得到HASH值：进程号、使用资源的用户的标识信息、分片的可扣减记录，其中，进程号是用于处理计费请求的进程的标识信息；

第一选择模块，用于从多个分片中选择分片标识与HASH值对应的至少一个分片。

作为可选的实施方式，选择单元包括：

第一获取模块，用于获取计费请求对应的资源的使用量；

第二获取模块，用于获取多个分片中资源剩余量能够满足使用量的分片；

第二选择模块，用于从能够满足使用量的分片中选择出至少一个分片。

作为可选的实施方式，选择单元还包括：

组合模块，用于在所有的单个分片的资源剩余量均不能满足使用量的情况下，依次组合多个分片；

第三选择模块，用于从能够满足使用量的分片组合中选择出一组分片组合作为至少一个分片。

作为可选的实施方式，选择单元还包括

锁定模块，用于从多个分片中选择一个分片进行锁定；

第四选择模块，用于在选择出的分片的资源剩余量小于使用量的情况下，从多个分片中剩余的分片中再次选择一个分片并进行锁定，直到使用量小于等于选择出的分片的剩余量之和，或者，直到所有的分片均被选择。

作为可选的实施方式，选择单元还包括

第五选择模块，用于在所有分片的资源剩余量之和均不能满足使用量的情况下，选择所有的分片作为至少一个分片；

计费模块，用于对使用量中超过所有分片的资源剩余量之后的部分根据计费标准进行计费。

通过在本发明的上述实施例，在计费账务处理***中资源共享类业务在处理时，是采用的背景技术的方案二，随着4G业务的发展，人均消耗流量的增长，人均话单量的增长，导致在资源共享业务的处理中，锁冲突的现象越来越严重，较大的消耗了BDS内存库的性能，同时在话单积压状态下，方案二计费处理效率呈降低趋势，按照本实施例的方式，计费***整体话单处理效率提升25％，数据所冲突回滚现象降低30％，BDS内存库压力降低15％。

对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以硬件、固件和/或软件产品的形式体现出来。用计算机软件产品体现时，其可被存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

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

接收计费请求，其中，所述计费请求包括对共享资源的使用量；

响应于所述计费请求，从多个分片中选择至少一个分片，其中，所述共享资源被分为多个分片；

锁定选择出的所述至少一个分片，其中，被锁定的分片不能被其他计费请求选择；

根据所述计费请求从锁定的所述至少一个分片中进行所述使用量的计费处理。

2.根据权利要求1所述的方法，其特征在于，响应于所述计费请求，从所述多个分片中选择所述至少一个分片包括：

获取所述计费请求对应的资源的使用量；

获取所述多个分片中资源剩余量能够满足所述使用量的分片；

从所述能够满足所述使用量的分片中选择出所述至少一个分片。

3.根据权利要求1所述的方法，其特征在于，响应于所述计费请求，从所述多个分片中选择所述至少一个分片包括：

获取所述计费请求对应的资源的使用量；

在所有的单个分片的资源剩余量均不能满足所述使用量的情况下，依次组合多个分片；

从能够满足所述使用量的分片组合中选择出一组分片组合作为所述至少一个分片。

4.根据权利要求1所述的方法，其特征在于，响应于所述计费请求，从所述多个分片中选择所述至少一个分片包括：

获取所述计费请求对应的资源的使用量；

从所述多个分片中选择一个分片进行锁定；

在选择出的分片的资源剩余量小于所述使用量的情况下，从所述多个分片中剩余的分片中再次选择一个分片并进行锁定，直到所述使用量小于等于选择出的分片的剩余量之和，或者，直到所有的分片均被选择。

5.根据权利要求1所述的方法，其特征在于，响应于所述计费请求，从所述多个分片中选择所述至少一个分片包括：

获取所述计费请求对应的资源的使用量；

在所有分片的资源剩余量之和均不能满足所述使用量的情况下，选择所有的分片作为所述至少一个分片；

所述方法还包括，

对所述使用量中超过所述所有分片的资源剩余量之后的部分根据计费标准进行计费。

6.根据权利要求1至5中任一项所述的方法，其特征在于，根据所述计费请求从锁定的所述至少一个分片中进行所述使用量的计费处理包括：

根据所述使用量从所述至少一个分片中进行扣减。

7.根据权利要求1至5中任一项所述的方法，其特征在于，从多个分片中选择至少一个分片是通过以下方式实现的：

根据以下信息的至少之一计算得到HASH值：进程号、使用资源的用户的标识信息、分片的可扣减记录，其中，所述进程号是用于处理所述计费请求的进程的标识信息；

从所述多个分片中选择分片标识与所述HASH值对应的所述至少一个分片。

8.一种共享资源计费处理装置，其特征在于，包括：

接收单元，用于接收计费请求，其中，所述计费请求包括对共享资源的使用量；

选择单元，用于响应于所述计费请求，从多个分片中选择至少一个分片，其中，所述共享资源被分为多个分片；

锁定单元，用于锁定选择出的所述至少一个分片，其中，被锁定的分片不能被其他计费请求选择；

处理单元，用于根据所述计费请求从锁定的所述至少一个分片中进行所述使用量的计费处理。

9.根据权利要求8所述的装置，其特征在于，所述处理单元用于根据所述使用量从所述至少一个分片中进行扣减。

10.根据权利要求8所述的装置，其特征在于，所述选择单元包括：

计算模块，用于根据以下信息的至少之一计算得到HASH值：进程号、使用资源的用户的标识信息、分片的可扣减记录，其中，所述进程号是用于处理所述计费请求的进程的标识信息；

第一选择模块，用于从所述多个分片中选择分片标识与所述HASH值对应的所述至少一个分片。