一种基于数据库的数据更新方法和系统转让专利

申请号 : CN201210237777.0

文献号 : CN103544153B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 郑高超

申请人 : 阿里巴巴集团控股有限公司

摘要 :

本申请提供了一种基于数据库的数据更新方法和系统,该方法包括:当接收到包含请求扣除的待扣数据量的数据更新请求时,判断本地内存中是否存储有预扣数据量,且该预扣数据量不小于待扣数据量;如果本地内存中存储有预扣数据量,则从本地内存中存储的预扣数据量中扣除待扣数据量;只有当本地内存中未存储有预扣数据量或者存储的预扣数据量小于待扣数据量时,才会从数据库中获取该数据的预算剩余量,并确定出数据库扣除量,将数据库扣除量作为本地内存中的预扣数据量进行存储,进而在本地内存中的预扣数据量中扣除待扣除量。该方法可以减少了对数据库的访问次数,进而减少了锁等待的等待时间,提高了系统单位时间内处理数据更新请求的数量。

权利要求 :

1.一种基于数据库的数据更新方法,其特征在于,包括:A、接收数据更新请求,所述数据更新请求中包括请求扣除的待扣数据量;

B、判断本地内存中是否存储有预扣数据量,且所述预扣数据量不小于所述待扣数据量,如果是,执行步骤E;如果否,则执行步骤C;

C、获取数据库中记录的所述数据的预算剩余量,并根据所述待扣数据量和所述预算剩余量确定数据库扣除量;

D、从所述数据库记录的预算剩余量中扣除所述数据库扣除量,并将所述数据库扣除量作为本地内存中的预扣数据量进行存储;

E、从所述本地内存中存储的预扣数据量中扣除所述待扣数据量,以更新本地内存中的预扣数据量。

2.根据权利要求1所述的方法,其特征在于,在所述根据所述待扣数据量和所述预算剩余量确定数据库扣除量之前,还包括:获取所述数据库中记录的预算总量;

相应的,所述根据所述待扣数据量和所述预算剩余量确定数据库扣除量,具体为:根据所述预算总量、预算剩余量以及待扣数据量之间的比例关系,确定数据库扣除量。

3.根据权利要求1所述的方法,其特征在于,从所述预算剩余量中扣除所述数据库扣除量之后,还包括:在数据库中记录所述从所述预算剩余量中扣除所述数据库扣除量的信息。

4.根据权利要求3所述的方法,其特征在于,在从所述本地内存中存储的预扣数据量中扣除所述待扣数据量之后,还包括:在数据库中记录所述从所述本地内存中存储的预扣数据量中扣除所述待扣数据量的信息。

5.根据权利要求4所述的方法,其特征在于,在将所述数据库扣除量作为本地内存中的预扣数据量进行存储之后,还包括:在本地内存中存储记录操作的标识信息,并建立本地内存中的预扣数据量与所述记录操作的标识信息的对应关系;

则所述在所述数据库中记录所述从所述本地内存中存储的预扣数据量中扣除所述待扣数据量的信息,具体包括:根据本地内存中的预扣数据量与所述记录操作的标识信息的对应关系,确定本地内存中的预扣数据量对应的当前记录操作;

在数据库中记录所述当前记录操作的使用明细,所述使用明细中表示所述当前记录操作对应的预扣数据量的每一次的扣除信息。

6.根据权利要求4所述的方法,其特征在于,还包括:判断当前时刻是否为预设的数据回收时刻,如果是,则从数据库中获取记录的预扣数据量的剩余量;

将所述剩余量添加到所述数据库记录的预算剩余量中,以更新所述数据库中记录的预算剩余量。

7.一种基于数据库的数据更新系统,其特征在于,包括:请求接收单元,用于接收数据更新请求,所述数据更新请求中包括请求扣除的待扣数据量;

判断单元,用于判断本地内存中是否存储有预扣数据量,且所述预扣数据量不小于所述待扣数据量,并当判断出本地内存中存储有预扣数据量,且所述预扣数据量不小于所述待扣数据量时,触发执行本地数据扣除单元的操作;当判断出本地内存中未存储有预扣数据量或者所述预扣数据量小于所述待扣数据量时,触发执行第一数据读取单元的操作;

第一数据读取单元,用于获取数据库中记录的所述数据的预算剩余量;

扣除量确定单元,用于根据所述待扣数据量和所述预算剩余量确定数据库扣除量,并执行数据更新单元的操作;

数据库更新单元,用于从所述数据库记录的预算剩余量中扣除所述数据库扣除量,并将所述数据库扣除量作为本地内存中的预扣数据量进行存储,并执行所述本地数据更新单元的操作;

本地数据更新单元,用于从所述本地内存中存储的预扣数据量中扣除所述待扣数据量,以更新本地内存中的预扣数据量。

8.根据权利要求7所述的系统,其特征在于,还包括第二数据读取单元,用于获取所述数据库记录的所述数据的预算总量;

相应的,所述扣除量确定单元具体为:用于根据所述预算总量、预算剩余量以及待扣数据量之间的比例关系,确定数据库扣除量。

9.根据权利要求8所述的系统,其特征在于,还包括:第一信息记录单元,用于所述数据更新单元从所述数据库记录的预算剩余量中扣除所述数据库扣除量时,在数据库中记录所述从所述预算剩余量中扣除所述数据库扣除量的信息。

10.根据权利要求9所述的系统,其特征在于,还包括:第二信息记录单元,用于在所述数据更新单元在从所述本地内存中存储的预扣数据量中扣除所述待扣数据量时,在数据库中记录所述从所述本地内存中存储的预扣数据量中扣除所述待扣数据量的信息。

11.根据权利要求10所述的系统,其特征在于,还包括:标识存储单元,用于在本地内存中存储记录操作的标识信息,并建立本地内存中的预扣数据量与所述记录操作的标识信息的对应关系;

所述第二信息记录单元,具体包括:

操作记录确定单元,用于根据本地内存中的预扣数据量与所述记录操作的标识信息的对应关系,确定本地内存中的预扣数据量对应的当前记录操作;

第二信息记录子单元,用于在所述数据库中记录所述当前记录操作的使用明细,所述使用明细中表示所述当前记录操作对应的预扣数据量的每一次的扣除信息。

12.根据权利要求10所述的系统,其特征在于,还包括:回收时刻判断单元,用于判断当前时刻是否为预设的数据回收时刻,如果是,则从数据库中获取记录的预扣数据量的剩余量;

将所述剩余量添加到所述数据库记录的预算剩余量中,以更新所述数据库中记录的预算剩余量。

说明书 :

一种基于数据库的数据更新方法和系统

技术领域

[0001] 本申请涉及数据库技术领域,特别涉及一种基于数据库的数据更新方法和系统。

背景技术

[0002] 数据库是一个共享资源,可以供多个用户使用。为了充分利用数据库资源、发挥数据库共享资源的特点,允许多个用户并行地存取数据库。但是当多个用户并发存取同一数据时,在数据库中就会产生多个事务同时对同一数据进行存取操作的情况,如果对并发操作不加控制就可能会出现读取和存储不正确的数据,破坏数据库的一致性。
[0003] 以飞机票订票系统中的订票操作为例,假设某航班的机票余量为16张,甲售票点的甲售票员和乙售票点的乙售票员读出该航班剩余机票均为16张,如果甲售票员和乙售票员在同一时刻各卖出一张机票,则甲售票点将修改机票余量为16-1=15张,并写回数据库;同时乙售票点也会修改机票余量为16-1=15张,并写回数据库。这样,尽管订票系统一共卖出两张票时,数据库中机票的余量却仅减少一张,即数据库中的机票余量更新为16-1=15张,从而由于并发操作导致了丢失修改等问题,使得数据库出现的不一致性问题。
[0004] 为了避免由于用户的并发操作而导致数据库的不一致性,一般通过对数据库进行加设排它锁以实现并发控制,即某一事务对数据库中的某个表或该表的某一记录做锁定,以保证同一时间仅有该事务可以对该表或该条记录进行修改,只有该事务释放了它的锁之后,其他的事务才可以对该表或该条记录进行修改。这样,当较多用户同时访问数据库中某一数据对象(即产生多个事务的并发操作)时,如果某个事务对该数据对象进行封锁,其他事务则必须等待,从而由于锁资源不足而产生大量的锁等待,甚至失败操作。
[0005] 因此,目前需要本领域的技术人员迫切解决的一个技术问题就是:如何实现对资源有限的数据库系统的并发控制,以减少锁等待的等待时间。

发明内容

[0006] 本申请提供一种基于数据库的数据更新方法,用以解决现有技术中并发访问过程中所存在的锁等待的等待时间过长的问题。
[0007] 本申请还提供了一种基于数据库的数据更新系统,用以保证上述方法在实际中的实现及应用。
[0008] 为了解决上述问题,本申请公开了一种基于数据库的数据更新方法,包括:
[0009] A、接收数据更新请求,所述数据更新请求中包括请求扣除的待扣数据量;
[0010] B、判断本地内存中是否存储有预扣数据量,且所述预扣数据量不小于所述待扣数据量,如果是,执行步骤E;如果否,则执行步骤C;
[0011] C、获取数据库中记录的所述数据的预算剩余量,并根据所述待扣数据量和所述预算剩余量确定数据库扣除量;
[0012] D、从所述数据库记录的预算剩余量中扣除所述数据库扣除量,并将所述数据库扣除量作为本地内存中的预扣数据量进行存储;
[0013] E、从所述本地内存中存储的预扣数据量中扣除所述待扣数据量,以更新本地内存中的预扣数据量。
[0014] 本发明还公开了一种基于数据库的数据更新系统,包括:
[0015] 请求接收单元,用于接收数据更新请求,所述数据更新请求中包括请求扣除的待扣数据量;
[0016] 判断单元,用于判断本地内存中是否存储有预扣数据量,且所述预扣数据量不小于所述待扣数据量,并当判断出本地内存中存储有预扣数据量,且所述预扣数据量不小于所述待扣数据量时,触发执行本地数据扣除单元的操作;当判断出本地内存中未存储有预扣数据量或者所述预扣数据量小于所述待扣数据量时,触发执行第一数据读取单元的操作;
[0017] 第一数据读取单元,用于获取数据库中记录的所述数据的预算剩余量;
[0018] 扣除量确定单元,用于根据所述待扣数据量和所述预算剩余量确定数据库扣除量,并执行数据更新单元的操作;
[0019] 数据库更新单元,用于从所述数据库记录的预算剩余量中扣除所述数据库扣除量,并将所述数据库扣除量作为本地内存中的预扣数据量进行存储,并执行所述本地数据更新单元的操作;
[0020] 本地数据更新单元,用于从所述本地内存中存储的预扣数据量中扣除所述待扣数据量,以更新本地内存中的预扣数据量。
[0021] 与现有技术相比,本申请包括以下优点:
[0022] 在本申请中,本申请中当系统接收到数据更新请求时,并不会直接从数据库中获取数据以对数据库进行写操作,只有在本地内存中存储的预扣数据量小于该数据更新请求所请求的待扣数据量时,才会从执行从数据库中获取数据的操作,从而减少了对数据库的访问次数,即减少了对数据库的写操作次数,进而减少了锁等待的等待时间,并提高了系统单位时间内处理数据更新请求的数量,即提高了系统的吞吐量。
[0023] 当然,实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

[0024] 为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
[0025] 图1是本申请的一种基于数据库的数据更新方法的实施例1的流程示意图;
[0026] 图2是本申请的一种基于数据库的数据更新方法的实施例2的流程示意图;
[0027] 图3是本申请一种基于数据库的数据更新方法的实施例3的流程示意图;
[0028] 图4是本申请一种基于数据库的数据更新系统的实施例1的结构示意图;
[0029] 图5是本申请一种基于数据库的数据更新系统的实施例2的结构示意图。

具体实施方式

[0030] 下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
[0031] 本申请可用于众多通用或专用的计算装置环境或配置中。例如:个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器装置、包括以上任何装置或设备的分布式计算环境等等。
[0032] 本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
[0033] 本申请的主要思想之一可以包括,当系统接收到数据更新请求时,如果本地内存中存储有预扣数据量,且该预扣数据量不小于该数据更新请求中的待扣数据量时,则直接从本地内存中存储的预扣数据量中扣除该待扣数据量;只有当本地内存中未存储有预扣数据量或者本地内存中存储的预扣数据量小于待扣数据量时,从数据库中获取该数据更新请求所对应的数据的预算剩余量,并根据该预算剩余量和待扣数据量确定数据库扣除量,从预算剩余量中扣除该数据库剩余量,并将数据库剩余量作为本地内存的预扣数据量进行存储,进而在本地内存的预扣数据量中扣除待扣数据量。这样,当系统接收到数据更新请求时,只有当本地内存中存储的预扣数据量不能满足该数据更新请求中请求扣除的待扣数据量时,才会从数据库中获取相应的数据对数据库进行读写操作,从而大大减少了对数据库中数据的读写次数,减少了数据库的锁操作次数,进而减少了锁等待时间,并提高了系统单位时间内处理数据更新请求次数,增大了系统吞吐量,提升了系统处理效率。
[0034] 参见图1,示出了本申请一种基于数据库的数据更新方法实施例1的流程图,本实施例可以包括以下步骤:
[0035] 步骤101:接收数据更新请求,该数据更新请求中包括请求扣除的待扣数据量。
[0036] 数据更新请求中包括待更新的数据信息以及请求扣除的待扣数据量等信息。该数据更新请求可以理解为获取数据库中存储的数据资源的请求,系统接收到该数据更新请求时,即可确定出待更新的数据资源,以及需要扣除的数据量。
[0037] 可以理解的是,该数据更新请求可以是本系统之外的其他终端或客户端向本系统发送的数据更新请求,也可以是系统的服务器中生成的数据更新请求,在此不做限制。
[0038] 例如,以飞机票订票系统而言,服务器系统可以接收用户从客户端发送机票订购请求;当然,售票点的售票员也可以根据用户需求向服务器输入机票订购请求,进而使得应用程序接收到该机票订购请求,在该机票订购请求中可以包括请求订购的机票种类以及订票数量,该机票订购请求就是一种数据更新请求。
[0039] 步骤102:判断本地内存中是否存储有预扣数据量,且本地内存中存储的预扣数据量不小于该待扣数据量,如果是,则执行步骤105;如果否,则执行步骤103。
[0040] 其中,本地内存也可以称为本地内存储器。
[0041] 当接收到数据更新请求时,系统并不会直接从数据库中获取相应的数据量,而是首先判断本地内存中是否存储有与该数据更新请求所请求的数据相对应的预扣数据量,以及该预扣数据量是否能够满足数据更新请求所请求的数据资源量,并根据判断结果来确定是否需要从数据库中获取数据来更新本地内存中的预扣数据量,以满足数据更新请求所请求的数据量。
[0042] 步骤103:获取数据库中记录的该数据的预算剩余量,并根据该待扣数据量和预算剩余量确定数据库扣除量。
[0043] 当本地内存未存储有满足数据更新请求的预扣数据量时,则依据数据更新请求所请求的数据资源类型,则从数据库中获取记录的该数据的预算剩余量。
[0044] 其中,预算剩余量为数据库中当前存储的该数据的剩余量。一般数据库中预先存储的总数据量可以称为预算总量,而从预算总量中扣除一定量的数据量之后,在数据库中该数据的剩余量则称为预算剩余量。在数据库中可以维护一个预算总表,在该预算总表中记录该预算总量和预算剩余量。以机票订购系统为例,设北京飞往西安的机票总数为150张,则在数据库中存储的该机票的预算总量为150,当在数据库中扣除了50张飞机票之后,数据库中当前的预算剩余量为100张。
[0045] 根据数据库中该数据的预算剩余量和待扣数据量来确定一数据库扣除量,可以通过在系统中内置数据扣除规则,当然根据实际需要的不同预置的数据扣除规则可能会有所不同。例如,可以根据预算剩余量和待扣数据量的比例关系来确定数据库扣除量,预设的扣除规则可以为:预算剩余量大于待扣数据量的50倍时,则确定数据库扣除量为该待扣数据量的10倍;当预算数据量小于或等于待扣数据量50倍时,则比较该待扣数据量的10与该预算剩余量的大小关系,当待扣剩余量的10倍小于预算剩余量时,则将待扣数据量作为数据库扣除量,否则,将待扣数据量的5倍作为数据库扣除量。
[0046] 无论采用何种方式确定数据库扣除量,都应保证确定出的数据库扣除量应大于或等于该数据更新请求中的待扣数据量且小于数据库的预算剩余量。该数据库扣除量即为确定出的需要从该数据库记录的预算剩余量中所扣除的数据量。
[0047] 步骤104:从数据库记录的预算剩余量中扣除该数据库扣除量,并将该数据库扣除量作为本地内存中的预扣数据量进行存储。
[0048] 在从数据库中记录的预算剩余量中扣除该数据库扣除量,将扣除结果写回至数据库中以更新数据库中记录的预算剩余量的同时,将数据库扣除量作为本地内存中的预扣数据量进行存储。
[0049] 其中将该数据库中的数据扣除量作为本地内存中的预扣数据量进行存储包括两种情况:
[0050] 其中一种方式为:将本地内存中的预扣数据量更新为数据库扣除量,即在当前时刻本地内存中存储的预扣数据量应与该数据库扣除量的数量值相同。例如,从确定出的数据库扣除量为1000,则当前时刻本地内存中的预扣数据量更新为1000。
[0051] 另一种方式为:将该数据库扣除量作为待存入到本地内存的预扣数据量存入到本地内存中,在当前时刻本地内存中的预扣数据量的总数据值应该为数据扣除量与当前时刻之前本地内存中已存储的预扣数据量之和。例如,当本地内存中的预扣数据量为50时,而接收到的数据更新请求中待扣数据量为60,本地内存中的预扣数据量不能满足本次数据更新请求所请求扣除的待扣数据量,则需要从数据库中获取该数据的预算剩余量,并确定数据库扣除量,假设确定出的数据库扣除量为1000,则将该数据库扣除量加入到本地内存的预扣数据量中,则当前时刻本地内存中的预扣数据量为1050。
[0052] 步骤105:从本地内存中存储的预扣数据量中扣除待扣数据量,以更新本地内存中的预扣数据量。
[0053] 当步骤102中判断出本地内存中存储的预扣数据量能够满足该数据更新请求所请求的数据量,或者是经过如上步骤103到104的操作并将从数据库中获取到的数据库扣除量作为本地内存中存储的待扣数据量,使得本地内存中的预扣数据量能够满足该数据更新请求所请求的数据量时,则从本地内存中扣除该数据更新请求所请求扣除的待扣数据量。
[0054] 在从本地内存中扣除了该次数据更新请求所请求扣除的待扣数据量之后,如果再次接收到数据更新请求且该数据更新请求所请求的待扣数据量小于当前时刻本地内存中存储的预扣数据量,则可以直接从本地内存的预扣数据量中扣除相应的待扣数据量。
[0055] 本领域技术人员可以理解,当本地内存进行数据读取的速度远大于在数据库进行数据存取的速度,因此,本申请不需要每次都从数据库中获取数据以完成对数据更新请求的处理,可以大大提高数据更新请求的处理速度,进而提高了单位时间内处理数据更新请求的次数,提高了系统吞吐量。
[0056] 本申请中并不是在每次接收到数据更新请求时都会对数据库进行存取操作,只有当判断出本地内存中存储的预扣数据量不能满足该数据更新请求的情况下,才会执行从数据库中获取数据、确定数据库扣除量并对更改数据库中的预算剩余量的操作,从而减少了对数据库的存取次数,进而减少了数据库锁操作次数,减少了锁等待时间的时间长度;同时,当本地内存中存储的预扣数据量能够满足数据更新请求所请求的待扣数据量时,则直接在本地内存的预扣数据量中扣除该待扣数据量,提高了对数据更新请求的处理速度,进而提高了单位时间内处理数据更新请求的次数,提高了系统吞吐量,提升了系统处理效率。
[0057] 在本申请中的基于数据库的数据更新方法可以应用于任意服务器系统中,如该方法可以应用于数据库服务器中,也可以应用于与数据库服务器进行数据交互的服务器系统中。可以理解的是,当本申请的方法应用于与数据库服务器进行数据交互的服务器中时,当系统判断出本地内存中未存储有预扣数据量或者是所述预扣数据量不能满足所述数据更新请求所请求的扣除的待扣数据量时,获取数据库中记录的预算剩余量可以理解为:向数据库服务器系统数据读取请求,该数据读取请求中包含读取与所述待扣数据量相对应的预算数据量;数据库服务器接收所述数据读取请求并将数据请求结果返回给该发出数据读取请求的服务器系统;该服务器系统依据预算数据量和待扣数据量确定出数据库扣除量时,向数据库服务器发送扣除该数据库扣除量的请求,数据库服务器接收该请求并从数据库记录的数据剩余量中扣除该数据库扣除量。
[0058] 在实际应用中,一般会存在分布于不同地理位置的多个服务器从数据库服务器中获取同一数据的情况,因此就可能存在分配到该系统的本地内存中的预扣数据量过大,而使得其他服务器或应用程序无法从数据库中获取到足够的数据量的情况。例如,仍以机票售票系统为例,设售票点有售票点A、售票点B和售票点C,如果售票点C的服务器从数据库获取到预算机票剩余量之后,确定出的待扣机票数量较大,虽然能够对售票点A服务器的售票过程不会产生影响,但是可能会使得数据库中存储的机票剩余量与实际相差悬殊,进而可能导致售票点B或C的服务器无法从数据库中获取到满足其机票订购需求的机票数量。为了避免该种情况的出现,需要更合理的确定待扣数据量,因此,在系统从数据库获取到预算剩余量的同时,还需要获取数据库记录的预算总量,并根据预算总量、预算剩余量以及数据更新请求中的待扣数据量来确定数据库扣除量。
[0059] 根据预算总量、预算剩余量和待扣数据量确定数据库扣除量的具体实现方式也可以根据需要设定,一般的可以根据预算总量、预算剩余量以及待扣数据量的比例关系来确定数据库扣除量。根据设定的扣除规则的不同,对于相同预算总量、预算剩余量和数据更新请求所请求的待扣数据量,确定出的数据库扣除量也可能会所有差异。
[0060] 为了便于理解,以积分扣除业务为例,来描述预算总量、预算剩余量和待扣数据量来确定数据库扣除量的过程:
[0061] 在积分扣除业务中数据库中存储的总积分是一定的,即预算总量为定值,假设预设的扣除规则为:
[0062] 1)如果预算剩余量小于或等于预算总量的1/30时,则数据库扣除量等于该待扣数据量;
[0063] 2)如果预算剩余量大于预算总量的1/30时,则选取该待扣除数据量的30倍与预算总量的1/100的中较小数据作为未选定数据量,将该未选定数据量与待扣数据量作比较,如果该未选定数据量大于该待扣数据量,则将该未选定数据量作为数据库数据量;如果该未选定数据量小于该待扣数据量,则将该待扣数据量作为数据库扣除量。
[0064] 假设积分的预算总量为12000积分,且当前的预算剩余量为8000积分。按照以上的预设扣除规则,预算剩余量大于预算总量的1/30,符合2)的条件。如果系统接收到的数据更新请求中包含的待扣数据量为50积分,该待扣数据量的30倍为1500积分,而预算总量的1/100为120积分,则选择二者中较小的数据即120积分作为未选定数据量,该未选定数据量
120积分大于待扣数据量50积分,因此将数据库扣除量定为120积分,从数据库的预算剩余量中扣除该120积分,并将这120积分作为本地内存中的预扣数据量进行存储。
[0065] 以上例子仅是为了清楚的理解本发明的方案也列举的一种扣除规则,但在实际应用中,对于有限数据资源的扣除系统,设定的扣除规则可能不同,本申请对扣除规则不做具体限定。
[0066] 参见图2,示出了本申请一种基于数据的数据更新方法的实施例2的流程示意图,本实施例包括如下步骤:
[0067] 步骤201:接收数据更新请求,该数据更新请求中包括请求扣除的待扣数据量。
[0068] 步骤202:判断本地内存中是否存储有预扣数据量,且本地内存中存储的预扣数据量不小于该待扣数据量,如果是,则执行步骤206;如果否,则执行步骤203。
[0069] 步骤203:获取数据库中记录的该数据的预算剩余量,并根据该待扣数据量和预算剩余量确定数据库扣除量。
[0070] 步骤201至步骤203的操作过程与图1所示实施例中的步骤101至步骤103的操作过程类似,在此不再赘述。
[0071] 步骤204:从数据库记录的预算剩余量中扣除该数据库扣除量,并在数据库中记录从预算剩余量中扣除数据库扣除量的信息。
[0072] 在本实施例中为了能够对数据库中记录的该数据的扣除情况进行记录,以便于数据库系统进行数据维护,在从数据库记录的预算剩余量中扣除该数据库扣除量时,还需要在数据库中记录从该预算剩余量中扣除数据库扣除量的信息。
[0073] 在数据中记录从预算剩余量中扣除数据库扣除量的信息可以为在数据库中生成一条记录,该条记录中记录有当前时刻从预算剩余量中扣除的数据库扣除量。
[0074] 具体的,可以在数据库中维护一个预扣记录表,当从预算剩余量中扣除数据库扣除量时,则在该预扣记录表中插入一条预扣记录,该预扣记录中记录有当前时刻扣除的数据库扣除量。如,仍以积分扣除业务为例,当从预算剩余量中扣除数据库扣除量为1000积分时,则在预扣记录表中插入一条预扣记录,在该预扣记录中记录有当前时刻扣除1000积分的信息。
[0075] 步骤205:将该数据库扣除量作为本地内存中的预扣数据量进行存储。
[0076] 步骤206:从本地内存中存储的预扣数据量中扣除待扣数据量,以更新本地内存中的预扣数据量,并在数据库中记录从该本地内存中存储的预扣数据量中扣除该待扣数据量的信息。
[0077] 在本地内存的预扣数据量中扣除待扣数据量的同时,也需要在数据库中记录从该预扣数据量中扣除该待扣数据量的信息,如通过在数据库表中生成一条记录,在该条记录中记录从该预扣数据量中扣除该待扣数据量的信息。
[0078] 在实际应用中,可以在同一数据表中记录从预算剩余量中扣除数据库扣除量,以及从本地内存中存储的预扣数据量中扣除该待扣数据量的信息。如将从本地内存的预扣数据量中扣除待扣数据量也可以记录在数据库维护的预扣记录表中。但是为了便于进行数据维护,在数据库中还可以维护一个使用明细表,当从本地内存中存储的预扣数据量中扣除待扣数据量时,则在该使用明细表中生成一条记录,以记录从预扣数据量中扣除待扣数据量的信息,该信息可以包括该待扣数据量的扣除时间以及具体的待扣数据量的数据等。
[0079] 当从数据库的预算剩余量中扣除数据库扣除量之后,采用将该数据库扣除量作为待存入到本地内存的预扣数据量存入到本地内存中,并将该数据扣除量与当前时刻之前本地内存中已存储的预扣数据量之和作为当前时刻本地内存中的预扣数据量的总数据值的方式时,则在数据库中记录每次从数据库中预算剩余量中扣除的数据库扣除量的信息,以及每次从本地内存中预扣数据量中扣除的待扣数据量的信息,即可确定实际的数据扣除请求,得到当前数据库中实际的预算剩余量。
[0080] 当从数据库的预算剩余量中扣除数据库扣除量之后,采用将本地内存中的预扣数据量更新为数据库扣除量的方式,即在当前时刻本地内存中存储的预扣数据量应与该数据库扣除量的数量值相同的情况下,由于在数据库中可能会记录有多条不同的从数据库中预扣数据量中扣除数据库扣除量的信息,而每次存储到本地内存中的数据库扣除量并不一定会完全扣除。
[0081] 例如,以积分扣除系统为例,在10:00时从数据库的预算剩余量中扣除的数据库扣除量为100积分,并将该100积分作为本地内存中的预扣数据量,则数据库中应至少记录有10:00时,扣除的数据库扣除量为100积分。同时根据接收到的数据更新请求,从本地内存中的预扣除数据量100中不断扣除数据量,并在数据库中记录从该预扣数据量中扣除的数据量明细。当本地内存中的预扣数据量不能满足数据更新请求,则系统会重新才从数据库中获取一数据库扣除量,假设当在10:05时,本地内存中存储的预扣数据量为5,已经不能满足数据更新请求中的待扣数据量,则在10:05时,系统从数据库的预算剩余量中扣除另一数据库扣除量200积分,并在数据库中插入一条记录来记录在10:05时,从数据库中扣除的数据量为200积分。这样数据库中将记录有至少两条从数据库中扣除数据库扣除量的信息,而对于10:00时,从数据库中扣除的100积分,实际上并未被扣除完全,仍剩余数据量5积分,然而在10:05分之后,系统再接收到数据更新请求,则是从本地内存的预扣数据量200积分中进行扣除,即实际上是在数据库扣除量200积分中扣除,而不再是从原来的数据库扣除量100积分中进行扣除。因此,在需要对不同时刻记录的数据库扣除量的信息进行区分,以确定哪条记录中记录的数据库扣除量仍存在剩余量,进而对实际未使用的剩余量进行回收。
[0082] 为了对不同时刻记录的操作信息进行区分,在数据库中记录扣除数据库扣除量的信息时,还可以生成与该记录信息相对应的记录操作的标识信息,以区别不同时刻扣除的数据库扣除量。
[0083] 对应的,从本地内存中的预扣数据量中扣除待扣数据量时,为了确定出当前时刻本地内存中的预扣数据量所对应的操作记录,在将该数据库扣除量作为本地内存中的预扣数据量进行存储的同时,还包括:
[0084] 在本地内存中存储记录操作的标识信息,并建立本地内存中的预扣数据量与所述记录操作的标识信息的对应关系。
[0085] 相应的,在所述数据库表中记录所述从所述本地内存中存储的预扣数据量中扣除所述待扣数据量的信息,具体包括:
[0086] 根据本地内存中的预扣数据量与所述记录操作的标识信息的对应关系,确定本地内存中的预扣数据量对应的当前记录操作;
[0087] 在数据库表中记录所述当前记录操作的使用明细,所述使用明细中表示所述当前记录操作对应的预扣数据量的每一次的扣除信息。
[0088] 仍以上面的积分扣除系统为例进行说明,系统在10:00从数据库中扣除数据库100积分,则生成该条记录操作时,生成与该记录操作的标识信息,如预扣记录1,时间:10:00,扣除100积分;当然也可以将生成该条记录的时间信息作为该记录操作的标识信息,也可以仅以“预扣记录1”作为标识信息而无需在记录时间信息。
[0089] 相应的,在10:05时,从数据库预算剩余量中扣除200积分时,在数据库中生成记录操作以及相应的标识信息,如,预扣记录2,时间:10:05,扣除200积分。
[0090] 为了区分出当前存储到本地内存中的预扣数据量为基于以上哪条记录操作而存储的,而在本地内存中也需要存储相应的记录操作的标识信息,如当在10:00时,从数据库中的预算剩余量中扣除100积分,并将这100积分作为本地内存中的预扣数据量时,在本地内存中存储操作记录的标识信息为“预扣记录1”,即此时本地内存中预扣数据量与数据库中预扣记录1中记录的数据库扣除量相对应的。则当每次从本地内存中的预扣数据量中扣除待扣数据量时,也会在数据库中记录在该预扣记录1记录的数据库扣除量中扣除待扣数据量。如从本地内存中预扣数据量中扣除20积分时,在数据库中也会记录在该预扣记录1的数据库扣除量中100积分中扣除20积分。
[0091] 当在10:05时,从数据库预算剩余量中扣除的数据库扣除量200积分时,将该200积分作为本地内存中的预扣数据量进行存储的同时,也会在本地内存中存储相应的记录操作的标识信息即“预扣记录2”。并将后续在本地内存中扣除的待扣数据量,如10积分时,在数据库中记录从预扣记录2记录的200积分中扣除待扣数据量10积分。
[0092] 当然,在生成操作记录的标识信息的方式并不限于该实例中所描述的方式,还可以有其他实现方式。另外,在数据库中记录从本地内存中扣除的待扣数据量信息的同时,也可以生成记录该待扣除数据量信息的记录操作相对应的标识信息。
[0093] 参见图3,示出了本发明一种基于数据库的数据更新方法实施例3的流程示意图,本实施例包括以下步骤:
[0094] 步骤301:接收数据更新请求,该数据更新请求中包括请求扣除的待扣数据量。
[0095] 步骤302:判断本地内存中是否存储有预扣数据量,且本地内存中存储的预扣数据量不小于该待扣数据量,如果是,则执行步骤206;如果否,则执行步骤203。
[0096] 步骤303:获取数据库中记录的该数据的预算剩余量,并根据该待扣数据量和预算剩余量确定数据库扣除量。
[0097] 步骤301至步骤303的操作过程与图1所示实施例中的步骤101至步骤103的操作过程类似,在此不再赘述。
[0098] 步骤304:从数据库记录的预算剩余量中扣除该数据库扣除量,并在数据库中记录从预算剩余量中扣除数据库扣除量的信息。
[0099] 步骤305:将该数据库扣除量作为本地内存中的预扣数据量进行存储。
[0100] 步骤306:从本地内存中存储的预扣数据量中扣除待扣数据量,以更新本地内存中的预扣数据量,在数据库中记录从该本地内存中存储的预扣数据量中扣除该待扣数据量的信息。
[0101] 以上步骤可以参见图1以及图2所示实施例的相应步骤的描述,在此不再赘述。
[0102] 步骤307:判断当前时刻是否为预设的数据回收时刻,如果是,则从数据库中获取记录的预扣数据量的剩余量,并将该剩余量添加到数据库的预算剩余量中,以更新数据库的预算剩余量。
[0103] 由于从数据库中扣除的数据库扣除量,仅是保存在本地内存中,并不数据库实际被扣除的数据总量,而由于系统在不同时刻从数据库中扣除了多次不同的数据库扣除量,因此需要每隔预设时间对数据库中存储的数据进行更新,以保证数据库中预算剩余量与数据的实际剩余量的偏差较小。具体的,在当前时刻为预设的数据回收时刻时,需要从数据库中获取记录的所有预扣数据量的剩余量,并将剩余量添加到数据库的预算剩余量中,进而更新数据库剩余量。
[0104] 确定当前时刻是否为预设的数据回收时刻的方式有多种,如可以预先设定数据回收周期,进而根据预设的数据回收周期来确定当前时刻是否为数据回收时刻。
[0105] 由图2所示的实施例可以看出,在数据库中可以同时记录有多条扣除数据库扣除量的信息,因此,在到达预设的数据回收时刻时,可以将是将数据库中记录的预扣数据量的剩余量均添加到数据库的预算剩余量中,也可以是仅将当前时刻本地内存中的预扣数据量之外其他预扣数据量的剩余量添加到数据库记录的预算剩余量中。
[0106] 例如,上面的积分扣除系统,在数据库中记录有:预扣记录1,时间:10:00时,数据库扣除量100;且对应该数据库扣除量100积分预扣数据量的剩余量为5积分。而在当前时刻本地内存中存储的预扣数据量是与数据库记录的预扣记录2中的扣除量200积分相对应的,因此,在进行数据回收时,可以仅根据与预扣记录1相对应的使用明细,来确定该数据库扣除量100积分的剩余量即5积分,并将该5积分加回到数据库记录的预算剩余量中;对于与预扣记录2中数据库扣除量200的实际剩余量而可以不加回到数据库的预算剩余量中。
[0107] 在实际应用中,在从数据库的预算剩余量中扣除数据库扣除量,并在数据库中记录扣除的数据库扣除量信息时,也可以相应的设定该数据库扣除量的记录信息的有效时长。如果在到达预设的数据回收时刻时,数据库中记录某条数据库扣除量的记录信息已经超出预设的有效时长,则将该条记录信息中记录的数据库扣除量对应的预扣数据量的剩余量加回到数据库记录的预算剩余量中。
[0108] 与上述本申请一种基于数据库的数据更新方法实施例1所提供的方法相对应,参见图4,本申请还提供了一种基于数据库的数据更新系统实施例1,在本实施例中,该系统可以包括:请求接收单元410、判断单元420、第一数据读取单元430、扣除量确定单元440、数据更新单元450和本地数据更新单元460。其中,请求接收单元410,用于接收数据更新请求,所述数据更新请求中包括请求扣除的待扣数据量。
[0109] 判断单元420,用于判断本地内存中是否存储有预扣数据量,且所述预扣数据量不小于所述待扣数据量,并当判断出本地内存中存储有预扣数据量,且所述预扣数据量不小于所述待扣数据量时,触发执行本地数据扣除单元的操作;当判断出本地内存中未存储有预扣数据量或者所述预扣数据量小于所述待扣数据量时,触发执行数据读取单元的操作;
[0110] 第一数据读取单元430,用于获取数据库中记录的所述数据的预算剩余量;
[0111] 扣除量确定单元440,用于根据所述待扣数据量和所述预算剩余量确定数据库扣除量,并执行数据更新单元的操作;
[0112] 数据库更新单元450,用于从所述数据库记录的预算剩余量中扣除所述数据库扣除量,并将所述数据库扣除量作为本地内存中的预扣数据量进行存储,并执行所述本地数据扣除单元的操作;
[0113] 本地数据更新单元460,用于从所述本地内存中存储的预扣数据量中扣除所述待扣数据量,以更新本地内存中的预扣数据量。
[0114] 其中,扣除量确定单元在确定从数据库的预算剩余量中扣除的数据库扣除量时,还可以参照其他的数据因数,相应的,本实施例的系统还可以包括:第二数据读取单元,用于获取所述数据库记录的所述数据的预算总量。
[0115] 相应的,扣除量确定单元具体为:用于根据所述预算总量、预算剩余量以及待扣数据量之间的比例关系,确定数据库扣除量。
[0116] 本申请的基于数据库的数据更新系统可以集成的任意一台可与数据库服务器进行数据交互的服务器中,也可以作为一个实体与服务器相连。
[0117] 本申请中的系统并不是在每次接收到数据更新请求时都会对数据库进行存取操作,只有当判断出本地内存中存储的预扣数据量不能满足该数据更新请求的情况下,才会执行从数据库中获取数据、确定数据库扣除量并对更改数据库中的预算剩余量的操作,从而减少了对数据库的存取次数,进而减少了数据库锁操作次数,减少了锁等待时间的时间长度;同时,当本地内存中存储的预扣数据量能够满足数据更新请求所请求的待扣数据量时,则直接在本地内存的预扣数据量中扣除该待扣数据量,提高了对数据更新请求的处理速度,进而提高了单位时间内处理数据更新请求的次数,提高了系统吞吐量,提升了系统处理效率。
[0118] 参见图5,示出了本申请一种基于数据库的数据更新系统实施例2的结构示意图,本实施例与图4所示实施例的不同之处在于:
[0119] 本实施例中还包括:第一信息记录单元470,用于在数据更新单元从数据库记录的预算剩余量中扣除数据库扣除量时,在数据库中记录所述从所述预算剩余量中扣除所述数据库扣除量的信息。
[0120] 第二信息记录单元480,用于所述数据更新单元在从所述本地内存中存储的预扣数据量中扣除所述待扣数据量时,在数据库中记录所述从所述本地内存中存储的预扣数据量中扣除所述待扣数据量的信息。
[0121] 进一步的,为了区分每次记录的从数据库中扣除的数据库扣除量,该系统还包括:
[0122] 标识存储单元,用于在本地内存中存储记录操作的标识信息,并建立本地内存中的预扣数据量与所述记录操作的标识信息的对应关系;
[0123] 相应的,该第二信息记录单元480,具体包括:操作记录确定单元和第二信息记录子单元。
[0124] 其中,操作记录确定单元,用于根据本地内存中的预扣数据量与所述记录操作的标识信息的对应关系,确定本地内存中的预扣数据量对应的当前记录操作。
[0125] 第二信息记录子单元,用于在数据库表中记录所述当前记录操作的使用明细,所述使用明细中表示所述当前记录操作对应的预扣数据量的每一次的扣除信息。
[0126] 进一步的,为了保证数据库的预算剩余量与该数据的实际剩余量不会有较大偏差,还需要对数据库中记录的预扣数据量的剩余量进行回收。对应的,本实施例的系统还包括:
[0127] 回收时刻判断单元,用于判断当前时刻是否为预设的数据回收时刻,如果是,则从数据库中获取记录的预扣数据量的剩余量,并将所述剩余量添加到所述数据库记录的预算剩余量中,以更新数据库中的预算剩余量。
[0128] 本实施例所述的装置可以集成到数据更新处理的服务器上,也可以单独作为一个实体与数据更新处理的服务器相连,另外,需要说明的是,当本申请所述的方法采用软件实现时,可以作为数据更新处理的服务器新增的一个功能,也可以单独编写相应的程序,本申请不限定所述方法或装置的实现方式。
[0129] 需要说明的是,本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
[0130] 最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0131] 为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
[0132] 通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
[0133] 以上对本申请所提供的一种基于数据库的数据更新方法及系统进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。