事务处理方法及装置
技术领域
本申请涉及计算机技术领域,尤其涉及一种事务处理方法及装置。
背景技术
事务是计算机技术领域中一个广泛使用的概念,是恢复和并发控制的基本单位,由计算机所处理的多个任务组成,随着计算机性能的快速发展,事务处理需求也越来越多;事务具有一致性,一致性要求如果事务中某个任务发生处理异常,数据库中关于该事务的所有数据均需返回至事务处理前的状态,以保证数据库内数据与事务的处理进程保持一致。
现有技术中,通过使用两阶段提交协议来进行事务的处理,该协议具体包括:1)预处理阶段,事务协调器发送预处理请求给事务处理中涉及的参与者,通知它们准备提交数据;2)回滚阶段,如果事务协调器一直未收到某一参与者的响应或有任一参与者做出否定响应,即表示该参与者准备失败,则将一个回滚请求发送给所有参与者,使得数据库中关于该事务的所有数据恢复至事务处理前状态。
然而,该现有技术中,若有参与者由于事务处理能力较差或网络抖动等原因,一直未能完成预处理请求,而在完成回滚请求并发出回滚请求完成响应后,才完成预处理请求,则会导致后续该参与者一直处于准备状态,而事务协调器则因收到了参与者的回滚完成响应后,误认为参与者均回滚完成,使得事务的一致性被破坏,导致数据库内关于该事务的数据将会一片混乱而不可预测,造成数据库无法正常使用。
综上,现有技术中的事务处理存在着事务一致性难以保证的问题。
申请内容
本申请实施例提供一种事务处理方法及装置,解决了现有技术中事务处理过程中一致性难以保证的技术问题。
本申请实施例还提供一种事务处理方法,其包括:
获取待处理事务的第一请求,所述第一请求为预处理请求;
判断所述待处理事务的第二请求是否符合预设条件,所述第二请求为回滚请求;
若是,结束所述第一请求;若否,执行所述第一请求。
本申请实施例还提供一种事务处理方法,其包括:
获取待处理事务的第一请求,所述第一请求为回滚请求;
判断所述待处理事务的第二请求是否符合预设条件,所述第二请求为预处理请求;
若是,结束所述第一请求;若否,执行所述第一请求。
本申请实施例还提供一种事务处理装置,其包括:
获取模块,用于获取待处理事务的第一请求,所述第一请求为预处理请求;
判断模块,用于判断所述待处理事务的第二请求是否符合预设条件,所述第二请求为回滚请求;
执行模块,若所述第二请求符合预设条件,用于结束所述第一请求,若所述第二请求不符合预设条件,用于执行所述第一请求。
本申请实施例还提供一种事务处理装置,其包括:
获取模块,用于获取待处理事务的第一请求,所述第一请求为回滚请求;
判断模块,用于判断所述待处理事务的第二请求是否符合预设条件,所述第二请求为预处理请求;
执行模块,若所述第二请求符合预设条件,用于结束所述第一请求,若所述第二请求不符合预设条件,用于执行所述第一请求。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:
本申请实施例中,根据第二请求是否符合预设条件来决定是否结束刚获取到的第一请求,无论第一请求是预处理请求还是回滚请求,均能实现回滚请求被执行后预处理请求不会被执行,预处理请求被执行后回滚请求才会执行;避免预处理请求在回滚请求后完成来破坏事务的一致性,保证了数据库内关于该事务的数据的正确性。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本申请实施例提供的事务处理方法的过程。
图2为本申请实施例提供的事务处理方法中判断待处理事务的第二请求是否符合预设条件的具体过程,此时,第一请求为预处理请求,第二请求为回滚请求。
图3为本申请另一实施例提供的事务处理方法中判断待处理事务的第二请求是否符合预设条件的具体过程,此时,第一请求为回滚请求,第二请求为预处理请求。
图4为本申请实施例提供的事务处理装置的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
在事务在处理过程中,可能存在预处理请求在回滚请求完成后才结束导致事务一致性被破坏的情形,为保证事务的一致性,本申请实施例提供一种事务处理方法,以下结合附图详细介绍本方法。
图1为本申请实施例提供的事务处理方法的过程,包括如下步骤:
S10、获取待处理事务的第一请求。
本申请的实施例中,第一请求是指事务的预处理请求,用于通知参与者准备提交数据。
通常提交数据的动作均伴随着事务相关数据的转移,例如,通过网上银行内余额账户来进行网购货款支付,该支付过程即为一事务。首先,买家的网上银行余额账户获取预处理请求后,将货款转至托管账户,在货款成功存入托管账户后,视为余额账户完成了预处理请求;后续,货款再从托管账户提交至卖家账户,从而完成整个货款支付。
S20、判断该待处理事务的第二请求是否符合预设条件,若是,执行步骤S30;若否,执行步骤S40。
其中,第二请求为回滚请求,该预设条件为:第二请求(回滚请求)在处理中或已经处理完。
S30、结束该第一请求,并对管理事务处理的事务协调器发送预处理请求失败响应。
S40、执行该第一请求。
同样以网上银行内余额账户来进行网购货款支付为例,余额账户获取预处理请求后,若余额账户事务处理能力和网络传输能力均正常时,余额账户执行预处理请求时,回滚请求并未生成,自然回滚请求也不符合其预设条件,此时,继续执行第一请求,以推动整个事务处理进程。
然而,在余额账户处理能力较差或网络抖动较大时,余额账户在后续收到回滚请求后,开始执行回滚请求甚至完成回滚请求时,才获取到预处理请求;此时,因回滚请求符合预设条件,直接结束预处理请求,避免继续执行预处理请求导致的事务一致性问题,保证了数据库内关于该事务的数据的正确性。
图2为本申请实施例提供事务处理方法中判断待处理事务的回滚请求是否符合预设条件的具体过程图,该步骤S20包括:
S21a、生成待处理事务的事务信息,事务信息包括事务标识和事务状态。
本申请的实施例中,每次获取事务处理请求,无论该事务处理请求是预处理请求还是回滚请求,均会生成待处理事务的事务信息。
事务信息中事务标识可通过事务内容、事务参与者以及事务发起时间等多个因素来定义,与事务请求的类型无关,使得每个事务处理的过程中,该事务的事务信息具有唯一的事务标识。
事务信息中事务状态为正常或回滚,在获取预处理请求时,事务状态则标为正常;获取回滚请求时,事务状态则标为回滚。
S22a、判断已记载事务信息的事务信息总表内是否存在与待处理事务的事务标识相同的事务信息,若否,执行S23a,若是,执行S24a。
本申请的实施例中,提供一事务信息总表,每次生成事务信息后,均将该事务的事务信息存入事务信息总表内。事务信息总表对事务标识做数据完整性约束,使得每次事务处理均只会有唯一的事务信息。
在获取待处理事务的事务处理请求后,将待处理事务的事务信息插入事务信息总表,根据能够成功插入来判定是否存在与待处理事务的事务标识相同的事务信息。
若出现插入失败,则判定事务信息总表内存在与待处理事务的事务标识相同的事务信息,反之,则判定事务信息总表内不存在事务标识相同的事务信息,同时待处理事务的事务信息被插入事务信息总表内,完成对事务信息总表的更新。
当然,本申请的其他实施例中,还可通过提取待处理事务的事务标识,查询事务信息总表,判断该事务标识是否存在于其中,以实现事务信息总表内是否存在与待处理事务的事务标识相同的事务信息,在此不做赘述。
S23a、判定存在相同的事务信息,即回滚请求不符合预设条件。
在事务信息总表内不存在与待处理事务的事务标识相同的事务信息时,表明本次待处理事务的预处理请求为首次请求,可继续执行该预处理请求。
S24a、判断存于事务信息总表内的事务信息的事务状态是否为回滚,若否,执行S25a,若是,执行S26a。
若事务信息总表内存在与待处理事务的事务标识相同的事务信息,表明本次事务处理请求并非该事务的首次处理请求,通过判断记载于事务信息总表内事务信息的事务状态是否为回滚,来明确该事务的当前处理进度。
在事务信息总表内事务信息的事务状态为回滚时,表明该事务处理已经到了回滚阶段,此时,判定该事务的回滚请求正在处理或已处理完;反之,若在事务信息总表内事务信息的事务状态为正常,表明该事务处理还处于预处理阶段,通常为单个事务请求参与者做多次预处理请求,可继续执行当前的预处理请求。
S25a、判定回滚请求不符合预设条件。
S26a、判定回滚请求在处理中或已经处理完,即回滚请求符合预设条件。
本申请的实施例中,事务处理方法还包括:在待处理事务提交成功时,删除该待处理事务的事务信息,降低事务信息总表占用空间,同时也提高事务标识查询效率。
本申请另一实施例提供的事务处理方法的过程,与前述实施例中事务处理方法的过程相比,区别在于:第一请求为回滚请求,第二请求为预处理请求,预设条件为:预处理请求在处理中。
图3为本申请另一实施例提供事务处理方法中判断待处理事务的回滚请求是否符合预设条件的具体过程图,步骤S20包括:
S21b、生成待处理事务的事务信息,事务信息包括事务标识和事务状态。
S22b、判断已记载事务信息的事务信息总表内是否存在与待处理事务的事务标识相同的事务信息,若是,执行S23b,若否,执行S24b。
S23b、判定存在相同的事务信息,即预处理请求不符合预设条件。
S24b、判断是否能够将待处理事务的事务信息插入至事务信息总表,若是,执行S25b,若否,执行S26b。
在事务信息总表内并不存在与待处理事务相同事务标识的事务信息存在,且待处理事务的事务信息也无法插入事务信息总表时,表明之前事务参与者将获取预处理请求时所生成的事务信息插入事务信息总表的动作仍然在进行中。
此时,使得事务信息总表内不存在相同该事物标识的事务信息,事务参与者无法将获取回滚请求时所生成的事务信息也插入事务信息总表内,进而获得预处理请求在处理中的结论。
S25b、判定事务信息插入失败,即预处理请求不符合预设条件。
S26b、判定预处理请求在处理中,即预设处理请求符合预设条件。
通过设定预处理请求当预处理请求在处理中时,结束回滚请求,并对管理事务处理的事务协调器发送回滚请求失败响应。事务协调器等待预设延时后,再向事务参与者发送回滚请求,事务参与者重复前述执行步骤S21b-S26b,直至得到预处理请求已处理完或处理出错为止。
由于在完成预处理请求后,才能执行回滚请求;避免了预处理请求在回滚请求结束后才完成,保证了数据库内关于该事务的数据的正确性。
本申请的实施例中,事务处理方法还包括:在待处理事务回滚成功时,将待处理事务的事务状态更新为回滚。
若在回滚请求执行前,已经执行了该事务的预处理请求或执行预处理请求异常,在事务信息总表内已经存有该待处理事务的事务信息,且存于事务信息总表内的待处理事务的事务信息的事务状态为正常,则在回滚完成后,将该事务状态由正常改为回滚。
若在回滚请求执行前,该事务的预处理请求未执行,则将回滚请求时所生成的事务信息的事务状态直接更新为回滚。
图4为本申请实施例提供的事务处理装置的机构示意图,本申请实施例所提供的事务处理装置基于以上事务处理方法,故该装置的具体细节可参照以上处理方法,本文不再予以赘述。该事务处理装置包括:
获取模块10,用于获取待处理事务的第一请求。
判断模块20,用于判断待处理事务的第二请求是否符合预设条件。
执行模块30,若第二请求符合预设条件,用于结束第一请求,若第二请求不符合预设条件,用于执行第一请求。
本申请实施例中,第一请求是预处理请求,第二请求是回滚请求;预设条件为:回滚请求在处理中或已经处理完。
本申请实施例中,判断模块20具体包括:
信息生成单元,生成待处理事务的事务信息,事务信息包括事务标识和事务状态。
标识判断单元,用于判断事务信息总表内是否存在与待处理事务的事务标识相同的事务信息。
状态判断单元,若存在事务标识相同的事务信息,用于判断存于事务信息总表内的事务信息的事务状态是否为回滚,若事务状态是回滚,判定第二请求在处理中或已经处理完。
本申请实施例中,标识判断单元具体用于:
将待处理事务的事务信息插入事务信息总表。
判断是否有事务标识重复异常,若否,判定存在与待处理事务的事务标识相同的事务信息。
本申请实施例中,事务处理装置还包括:
信息删除模块,用于在待处理事务提交成功时,删除该待处理事务的事务信息。
本申请实施例中,第一请求是回滚请求,第二请求是预处理请求;预设条件为:第二请求在处理中。
本申请实施例中,判断模块20具体包括:
信息生成单元,用于生成待处理事务的事务信息,事务信息包括事务标识和事务状态。
标识判断单元,用于判断事务信息总表内是否存在与待处理事务的事务标识相同的事务信息。
插入判断单元,若不存在事务标识相同的事务信息,用于判断是否能够将待处理事务的事务信息插入至事务信息总表,若事务信息插入失败,判定第二请求在处理中。
本申请实施例中,插入判断单元具体用于:
将待处理事务的事务信息插入事务信息总表。
判断是否有事务标识重复异常,若否,判定存在与待处理事务的事务标识相同的事务信息。
本申请实施例中,事务处理装置还包括:
回滚更新模块,用于在待处理事务回滚成功时,将待处理事务的事务状态更新为回滚。
本申请实施例中,事务处理装置还包括响应发送模块,用于发送第一请求失败响应。
本申请实施例所提供的事务处理装置,根据第二请求是否符合预设条件来决定是否结束刚获取到的第一请求,无论第一请求是预处理请求还是回滚请求,均能实现回滚请求被执行后预处理请求不会被执行,预处理请求被执行后回滚请求才会执行;避免预处理请求在回滚请求后完成来破坏事务的一致性,保证了数据库内关于该事务的数据的正确性。
需要说明的是,本申请的实施例所提供事务处理方法的各步骤的执行主体均可以是同一设备,或者,该方法也由不同设备作为执行主体。比如,步骤21和步骤22的执行主体可以为设备1,步骤23的执行主体可以为设备2;又比如,步骤21的执行主体可以为设备1,步骤22和步骤23的执行主体可以为设备2。
本领域内的技术人员应明白,本申请的实施例可提供为方法、装置、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(装置)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程事务处理设备的处理器以产生一个机器,使得通过计算机或其他可编程事务处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程事务处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程事务处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、事务结构、程序的模块或其他事务。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的事务信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、装置或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。