一种分布式系统业务数据一致性处理方法、装置
文献发布时间:2023-06-19 12:00:51
技术领域
本文涉及自动程序设计技术领域,尤其涉及一种分布式系统业务数据一致性处理方法、装置。
背景技术
随着互联网时代的不断发展,金融行业的业务规模不断扩大,系统也越来越复杂,单节点的服务已经无法满足需求,于是人们便对系统或者数据进行拆分,分布式系统便应运而生。然而,如何保证各个子系统间的信息、工作进度、状态一致并且协调有序地工作成为了分布式系统的一大难题。如果要实现强一致性,可能会导致系统整体性能低下,扩展性受到影响,并且架构也变得极其复杂,所以在互联网领域,很多情况下都是牺牲强一致性,来达到高可用性,系统往往只需要保证“最终一致性”,只要这个最终时间是在用户可以接受的范围内即可。但是金融领域由于涉及到资金安全,需要保证百分之百的准确性,因此如何解决现有技术中金融分布式系统数据一致性是亟需解决的问题。
发明内容
为解决金融数据一致性要求高,而现有技术无法确保金融分布式系统中业务数据高一致性的问题,本文实施例提供了一种分布式系统业务数据一致性处理方法、装置,通过将多种业务数据一致性处理方法相结合实现了金融分布式系统中业务成功率高,业务数据一致性好的效果。
本文实施例提供了一种分布式系统业务数据一致性处理方法,包括,
根据业务的需求,产生至少一个子服务调用请求发送给相应的子服务提供系统;
根据所述子服务提供系统反馈的服务执行结果进行第一一致性处理,并将所述第一一致性处理后所述子服务调用请求的状态记录于本地服务执行历史表中;
对所述本地服务执行历史表中经过所述第一一致性处理的处于第一特定状态的子服务调用请求进行第二一致性处理,并根据所述子服务提供系统的服务执行结果更新所述本地服务执行历史表中子服务调用请求的状态;
对所述本地服务执行历史表中处于第二特定状态的子服务调用请求进行第三一致性处理;
返回所述第一一致性处理步骤,接收所述子服务提供系统根据所述第三一致性处理反馈的服务执行结果。
本文实施例还提供了一种分布式系统业务数据一致性处理系统,包括服务调用系统、子服务提供系统;
所述服务调用系统进一步包括,
子服务调用请求产生单元,用于根据业务的需求,产生至少一个子服务调用请求发送给相应的子服务提供系统;
第一一致性处理单元,用于根据所述子服务提供系统反馈的服务执行结果进行第一一致性处理,并将所述第一一致性处理后所述子服务调用请求的状态记录于本地服务执行历史表中;
第二一致性处理单元,用于对所述本地服务执行历史表中经过所述第一一致性处理的处于第一特定状态的子服务调用请求进行第二一致性处理,并根据所述子服务提供系统的服务执行结果更新所述本地服务执行历史表中子服务调用请求的状态;
第三一致性处理单元,用于对所述本地服务执行历史表中处于第二特定状态的子服务调用请求进行第三一致性处理;返回所述第一一致性处理单元,接收所述子服务提供系统根据所述第三一致性处理反馈的服务执行结果。
本文实施例还提供了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述的方法。
本文实施例还提供了一种计算机可读存储介质,其上存储有计算机指令,该计算机指令被处理器执行时实现上述的方法。
利用本文实施例,通过将不同的一致性处理进行结合,可以进一步确保分布式系统中数据的一致性,并且通过第一一致性处理、第二一致性处理与第三一致性处理和第四一致性处理同时进行,可以提高失败的子服务调用请求再次尝试在子服务提供系统中执行并获得成功的可能性。
附图说明
为了更清楚地说明本文实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本文的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1所示为现有技术中TCC分布式事务的系统结构示意图;
图2所示为本文实施例一种分布式系统业务数据一致性处理方法的流程图;
图3所示为本文实施例一种分布式系统业务数据一致性处理系统的结构示意图;
图4所示为本文实施例一种分布式系统业务数据一致性处理系统的详细结构图;
图5所示为本文实施例一种分布式系统业务数据一致性处理方法的整体流程图;
图6所示为与图5所示本文实施例对应的系统结构示意图;
图7所示为本文实施例服务调用系统以及子服务提供系统的装置结构示意图。
【附图标号说明】
101、主业务服务器;
102、业务子系统;
103、业务活动管理器;
300、服务调用系统;
301、子服务调用请求产生单元;
302、第一一致性处理单元;
3021、第一处理模块;
3022、第二处理模块;
30221、计算模块;
30222、反向子服务调用请求模块;
3023、第三处理模块;
303、第二一致性处理单元;
3031、第四处理模块;
3032、第五处理模块;
3033、第六处理模块;
304、第三一致性处理单元;
3041、第七处理模块;
3042、第八处理模块;
3043、第九处理模块;
305、第四一致性处理单元;
3051、第十处理模块;
3052、第十一处理模块;
3053、第十二处理模块;
400、子服务提供系统;
401、消息中间件;
402、执行单元;
403、比对单元;
601、服务调用系统;
602、子服务提供系统;
603、消息队列;
604、文件处理系统;
702、计算设备;
704、处理设备;
706、存储资源;
708、驱动机构;
710、输入/输出模块;
712、输入设备;
714、输出设备;
716、呈现设备;
718、图形用户接口;
720、网络接口;
722、通信链路;
724、通信总线。
具体实施方式
下面将结合本文实施例中的附图,对本文实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本文一部分实施例,而不是全部的实施例。基于本文中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本文保护的范围。
如图1所示为现有技术中TCC分布式事务的系统结构示意图,在本图中描述了现有技术中TCC分布式事务处理的思想,用于保持分布式系统中各个子系统的一致性。TCC分布式事务处理是指将事务处理分为三个阶段,分别为Try阶段,Confirm阶段以及Cancel阶段,TCC也就是这三个阶段的首字母组成。其中,Try阶段用于对业务系统做检测及资源预留;Confirm阶段用于对业务系统做确认提交,Try阶段执行成功并开始执行Confirm阶段时,默认Confirm阶段是不会出错的,即:只要Try成功,Confirm一定成功;Cancel阶段用于在业务执行错误,需要回滚时将执行的业务取消,预留资源释放。
在图1所示的分布式系统中主业务服务器101发起整个业务活动,其中可能涉及多个子业务配合完成一个主业务,主业务服务器101开始调用链路依次到不同的业务子系统102执行Try逻辑做子业务检测和资源预留;业务活动管理器103控制各个业务子系统102中业务活动的一致性,登记业务活动操作并记录业务活动的日志;如果Try逻辑在所有业务子系统102中处理正常,则业务活动管理器103执行Confirm逻辑,调用不同的子业务来完成主业务;如果某个子服务的Try逻辑处理有问题,TCC分布式事务处理系统会推进执行各个业务子系统102的Cancel逻辑,撤销前面执行的各种操作。在TCC分布式事务处理系统中为了解决一致性的问题,需要每个业务子系统102都先执行Try逻辑,再执行Confirm,这使得整个系统臃肿且复杂,应用侵入性较强,改造成本高;并且,在如图1所示的例子中,如果Try逻辑处理有问题,不同的业务子系统102中执行Cancel逻辑时,有的业务子系统(例如图1中的业务子系统A)收到Cancel指令,而有的业务子系统(例如图1中的业务子系统B)没有收到Cancel指令,就会导致业务子系统A回滚成功,而业务子系统B没有回滚,整个系统就会处于不一致的状态。
如图2所示为本文实施例一种分布式系统业务数据一致性处理方法的流程图,在本图中描述了分布式系统中通过相互结合、交叉的业务数据一致性处理手段达到简单有效、更便利的方式确保业务数据的一致性。本图的实施例中主要描述了服务调用系统的流程方法,该流程方法中的每个步骤都可能由软件程序或者通用芯片,具体包括:
步骤201,根据业务的需求,产生至少一个子服务调用请求发送给相应的子服务提供系统;
步骤202,根据所述子服务提供系统反馈的服务执行结果进行第一一致性处理,并将所述第一一致性处理后所述子服务调用请求的状态记录于本地服务执行历史表中;
步骤203,对所述本地服务执行历史表中经过所述第一一致性处理的处于第一特定状态的子服务调用请求进行第二一致性处理,并根据所述子服务提供系统的服务执行结果更新所述本地服务执行历史表中子服务调用请求的状态;
步骤204,对所述本地服务执行历史表中处于第二特定状态的子服务调用请求进行第三一致性处理;
步骤205,返回所述第一一致性处理步骤,接收所述子服务提供系统根据所述第三一致性处理反馈的服务执行结果。
通过本文实施例中的方法中同步的第一一致性处理和第二一致性处理以及异步的第三一致性处理,可以提高分布式系统中子服务调用的成功率,保证各个子系统中业务数据的一致性,使得分布式系统采用简单有效的方式实现了整个系统最终一致性,自动修复程度高。
作为本文实施例的一个方面,产生至少一个子服务调用请求发送给相应的子服务提供系统中进一步包括,所述子服务调用请求包括唯一标识符。
在本步骤中,所述子服务调用请求的唯一标识符用以在所有子服务提供系统以及服务调用系统中唯一的标识该子服务调用请求。
作为本文实施例的一个方面,根据所述子服务提供系统反馈的服务执行结果中包括,所述子服务调用请求被执行成功的成功状态,以及所述子服务调用请求被执行失败的失败状态。
在本步骤中,所述子服务调用请求在子服务提供系统中被执行,如果执行成功则由所述子服务提供系统反馈成功状态,否则反馈失败状态,不会反馈超时状态,而该超时状态是由服务调用系统根据发出子服务调用请求后,在一预定时间内没有接收到子服务提供系统反馈关于该子服务调用请求执行成功或者失败的状态后,才将该子服务调用请求的状态修改为超时状态,并存储于本地服务执行历史表中。
作为本文实施例的一个方面,所述第一一致性处理包括,
将成功状态的子服务调用请求记录于所述本地服务执行历史表中,并结束;
将失败状态的子服务调用请求记录于所述本地服务执行历史表中,并向相应的子服务提供系统重发所述子服务调用请求,接收所述子服务提供系统反馈的服务执行结果;
如果超过预定时间所述子服务提供系统未反馈服务执行结果,则将超时状态的子服务调用请求为超时状态记录于所述本地服务执行历史表中。
在本步骤中,所述子服务提供系统如果没有出错,则可以正确的执行所述子服务调用请求,并将服务执行结果,即该子服务调用请求为成功状态的信息反馈给服务调用系统;如果所述子服务提供系统出错,则不会正确执行所述子服务调用请求,将服务执行结果,即该子服务调用请求为失败状态的信息反馈给服务调用系统,而服务调用系统会根据该服务执行结果重新将子服务调用请求发送给子服务提供系统,以便于重新尝试执行子服务调用请求,从而完成整个业务所述的所有子服务;超过一预定时间,子服务提供系统未向所述服务调用系统反馈服务执行结果,则服务调用系统仅修改本地服务执行历史表,将该子服务调用请求的状态修改为超时状态,并不在第一一致性处理中对该子服务调用请求再进行其他处理。
作为本文实施例的一个方面,在向相应的子服务提供系统重发所述子服务调用请求,接收所述子服务提供系统反馈的服务执行结果中进一步包括,
计算重发所述子服务调用请求的时间,如果超过了第一时间门限,所述子服务调用请求的状态为失败状态,则报错退出。
在本步骤中,所述第一时间门限可以为30秒、50秒等时间区间,如果在合理长的时间内所述子服务调用请求均无法被子服务提供系统成功执行,则会触发报错并退出本文的一致性处理方法。可以向子服务提供系统发送报错信息,其中可以包括子服务调用请求的唯一标识符,以及报错原因,即多次尝试执行子服务均失败,请求所述子服务提供系统反馈执行失败原因,并通知所述子服务提供系统的人工管理接口以分析所述子服务调用请求执行失败的原因。
在其他的实施例中,还可以根据所述子服务调用请求被重复发送给子服务提供系统的次数进行计算,如果重复执行所述子服务调用请求的次数超过预定的门限值,则报错退出。
作为本文实施例的一个方面,在所述报错退出之中还包括,
向与造成报错退出的子服务调用请求相关联的其他子服务调用请求对应的子服务提供系统发送反向子服务调用请求,使得所述对应的子服务提供系统执行反向子服务调用请求回滚已经执行成功的子服务调用请求。
在本步骤中,所述反向子服务调用请求具有与原子服务调用请求相反的执行顺序,例如原子服务调用请求是新增客户信息,那么反向子服务调用请求就是删除该客户信息。当一个业务需求包含多个自服务调用请求时,其中一些子服务调用请求在相应的子服务提供系统中执行成功,但是某些或者某个子服务调用请求执行失败,并且反复失败超过门限值时,则需要在所有与该业务需求相关的所有子服务提供系统中反向执行原子服务调用请求,使得所有子服务提供系统中的数据与服务调用系统中的数据一致,从而能够进一步更好的保障整个分布式系统中的数据一致性。
作为本文实施例的一个方面,对所述本地服务执行历史表中经过所述第一一致性处理的处于第一特定状态的子服务调用请求进行第二一致性处理中进一步包括,
对所述本地服务执行历史表中状态为超时状态的子服务调用请求生成查询请求;
向相应的子服务提供系统发送所述查询请求;
接收所述相应的子服务提供系统反馈的服务执行结果。
在本步骤中,所述查询请求中包括超时状态子服务调用请求的唯一标识符,当将该查询请求发送给相应的子服务提供系统后,所述子服务提供系统在服务执行状态表中查询所述子服务调用请求的唯一标识符,在所述服务执行状态表中仅记录有所述子服务调用请求的两种状态,即成功状态和失败状态,子服务提供系统将查询到的子服务调用请求的执行结果反馈给服务调用系统。服务调用系统可以根据执行结果更新所述本地服务执行历史表中子服务调用请求的状态,例如将本地服务执行历史表中子服务调用请求的状态由在第一一致性处理中的超时状态改为成功状态或者失败状态。
作为本文实施例的一个方面,接收所述相应的子服务提供系统反馈的服务执行结果中进一步包括,
如果在第二时间门限内未接收到所述相应的子服务提供系统反馈的服务执行结果,则所述本地服务执行历史表中状态为超时状态的子服务调用请求依然为超时状态,并向所述相应的子服务提供系统重发所述查询请求;
当到达第三时间门限为止始终未收到所述相应的子服务提供系统反馈的服务执行结果,则报错退出。
在本步骤中,所述第二时间门限例如可以为10秒、15秒等,重复发送多次查询请求后,例如1分钟、2分钟等,均未收到相应子服务提供系统反馈的服务执行结果,则会向服务调用系统的人工管理接口发送报警信息,其中可以包括子服务调用请求的唯一标识符,以及尝试重发的次数、时间以及最终超时的状态,从而服务调用系统的人工管理接口可以分析子服务调用请求执行超时的原因。
作为本文实施例的一个方面,对所述本地服务执行历史表中处于第二特定状态的子服务调用请求进行第三一致性处理中进一步包括,
读取所述本地服务执行历史表中状态为超时状态或失败状态的子服务调用请求;
将读取出来的子服务调用请求发送到消息队列;
所述子服务提供系统获取所述消息队列中的子服务调用请求;
所述子服务提供系统执行所述子服务调用请求;
接收所述子服务提供系统的服务执行结果。
在本步骤中,服务调用系统通过消息管理单元将超时状态或者失败状态的子服务调用请求放入消息队列中,例如可以以kafka消息形式将子服务调用请求发送到kafka消息队列中,子服务提供系统的消息中间件监听到kafka消息队列中有新的子服务调用请求的消息后,将查询服务执行状态表中对应的子服务调用请求的状态,如果没有该子服务调用请求则在子服务提供系统上执行该子服务调用请求,并在服务执行状态表中记录该子服务调用请求以及其状态;如果服务执行状态表中记录的该子服务调用请求的状态为成功状态,则通过所述第一一致性处理中反馈服务执行结果的通信接口反馈子服务调用请求的状态;如果服务执行状态表中记录的该子服务调用请求的状态为失败状态,则在子服务提供系统中重新执行该子服务调用请求,如果反复执行后均无法正确执行该子服务调用请求,则通过所述第一一致性处理中反馈服务执行结果的通信接口反馈子服务调用请求的失败状态。
通常的消息队列是单向的,即一方只会从消息队列中写入信息,然后另一方从消息队列中获取信息并执行,并不会反馈给消息写入方消息执行的结果,而在本文的实施例中,将消息队列与第一一致性处理的步骤相互结合,子服务提供系统通过第一一致性处理过程中的通信接口将消息队列中的子服务调用请求的执行结果反馈给服务调用系统,实现了基于消息队列的执行结果反馈机制。
作为本文实施例的一个方面,对所述本地服务执行历史表中处于第二特定状态的子服务调用请求进行第三一致性处理包括,
在进行第一一致性处理以及第二一致性处理的过程中,同步进行所述第三一致性处理。
在本步骤中,在进行第一一致性处理的过程中,例如在接收到子服务提供系统反馈的服务执行结果后,所述本地服务执行历史表中的所述子服务调用请求状态被更新,可能出现了失败状态的子服务调用请求,此时,可以在第一一致性处理中重发所述失败状态的子服务调用请求之前,或者同时,通过消息管理单元将子服务调用请求放入消息队列中,子服务提供系统的消息中间件获得消息队列中的子服务调用请求。此时,子服务提供系统得到了两个相同唯一标识符的子服务调用请求,一个来自于第一一致性处理过程中重发的子服务调用请求,一个来自于消息队列中的子服务调用请求,子服务提供系统判断每个子服务调用请求的唯一标识符是否相同,如果相同则仅保留一次子服务调用请求执行成功的结果,如果该子服务调用请求被执行多次,执行结果包括成功以及失败,则该子服务调用请求状态为成功状态,如果多次子服务调用请求执行结果均为失败,则子服务调用请求状态为失败状态。也就是说,当子服务提供系统接收到多个重复执行子服务调用请求时,如果成功一次,则反馈服务执行结果为成功状态,如果全部失败,则反馈服务执行结果为失败状态。
在其他实施例中,子服务提供系统还可以对接收到重复执行的子服务调用请求进行计数,将通过第一一致性处理发送过来的重复执行子服务调用请求,以及从第三一致性处理中消息队列中获取的子服务调用请求的数量进行累加,根据不同子服务调用请求的累加值的大小,对子服务调用请求执行顺序进行排序,累加值大的优先执行,累加值小的滞后执行,从而可以更快的重新执行子服务调用请求,完成该子服务调用请求,从而完成整个业务服务。
作为本文实施例的一个方面,本文实施例的方法还包括,
对所述本地服务执行历史表中处于第二特定状态的子服务调用请求进行第四一致性处理;
返回所述第一一致性处理步骤,接收所述子服务提供系统根据所述第四一致性处理反馈的服务执行结果。
在本步骤中,在第一一致性处理、第二一致性处理、第三一致性处理的过程中,或者在某个处理之后,服务调用系统可以根据本地服务执行历史表中记录的第二特定状态的子服务调用请求生成相应的数据核对文件,在日终(或者特定的时间段)系统不进行业务响应时将数据核对文件发送给子服务提供系统,以便于子服务提供系统将数据核对文件与服务执行状态表中记录的子服务调用请求进行对比,如果两者记录的状态不一致时,例如服务执行状态表中子服务调用请求的状态为失败状态,在数据核对文件中该子服务调用请求为超时状态,则子服务提供系统将会通过所述第一一致性处理中反馈服务执行结果的通信接口反馈该子服务调用请求的失败状态。
作为本文实施例的一个方面,对所述本地服务执行历史表中处于第二特定状态的子服务调用请求进行第四一致性处理进一步包括,
抽取所述本地服务执行历史表中处于超时状态和失败状态的子服务调用请求;
将抽取的子服务调用请求形成数据核对文件,并发送到子服务提供系统;
在接收所述子服务提供系统根据所述第四一致性处理反馈的服务执行结果中进一步包括,
接收所述子服务提供系统利用所述数据核对文件与服务执行状态表比对后反馈的服务执行结果。
在本步骤中,将本地服务执行历史表中处于失败和超时的子服务调用请求抽取出来后生成数据核对文件,通过数据文件传输通道将数据核对文件进行传输,本实施例中的数据传输通道不同于第一一致性处理、第二一致性处理、第三一致性处理过程中所涉及到的即时通信接口,由于数据核对文件的体积较大,因此采用数据文件传输通道可以通过更宽的预留贷款将数据核对文件传送到子服务提供系统。在子服务提供系统中将数据核对文件与服务执行状态表中的子服务调用请求进行比对,如果两者的状态不一致,例如数据核对文件中子服务调用请求的状态为超时状态,所述子服务提供系统中服务执行状态表中的子服务调用请求为成功状态,则会通过所述第一一致性处理中反馈服务执行结果的通信接口反馈子服务调用请求的成功状态;如果数据核对文件中子服务调用请求的状态为失败状态,所述子服务提供系统中服务执行状态表中的子服务调用请求为失败状态(或者服务执行状态表中没有该子服务调用请求),则会在子服务提供系统中执行该子服务调用请求,并将服务执行结果,例如成功状态或失败状态,通过所述第一一致性处理中反馈服务执行结果的通信接口反馈子服务调用请求的状态。
通过上述本文实施例的方法,通过将不同的一致性处理进行结合,可以进一步确保分布式系统中数据的一致性,并且通过第一一致性处理、第二一致性处理与第三一致性处理和第四一致性处理同时进行,可以提高失败的子服务调用请求再次尝试在子服务提供系统中执行并获得成功的可能性。
如图3所示为本文实施例一种分布式系统业务数据一致性处理系统的结构示意图,在本图中可以通过软件程序、通用芯片、单独的计算机、服务器等方式实现各个单元、模块的功能,并不限制某个单元、模块为软件程序或者硬件电路,通过将多种一致性处理单元相结合,可以进一步提高整个分布式系统的业务数据一致性,该装置具体包括:
服务调用系统300,子服务提供系统400;其中,
所述服务调用系统300进一步包括,
子服务调用请求产生单元301,用于根据业务的需求,产生至少一个子服务调用请求发送给相应的子服务提供系统;
第一一致性处理单元302,用于根据所述子服务提供系统反馈的服务执行结果进行第一一致性处理,并将所述第一一致性处理后所述子服务调用请求的状态记录于本地服务执行历史表中;
第二一致性处理单元303,用于对所述本地服务执行历史表中经过所述第一一致性处理的处于第一特定状态的子服务调用请求进行第二一致性处理,并根据所述子服务提供系统的服务执行结果更新所述本地服务执行历史表中子服务调用请求的状态;
第三一致性处理单元304,用于对所述本地服务执行历史表中处于第二特定状态的子服务调用请求进行第三一致性处理;返回所述第一一致性处理单元302,接收所述子服务提供系统400根据所述第三一致性处理反馈的服务执行结果。
作为本文实施例的一个方面,所述服务执行结果中包括,所述子服务调用请求被执行成功的成功状态,以及所述子服务调用请求被执行失败的失败状态;如果超过预定时间所述子服务提供系统未反馈服务执行结果,则所述子服务调用请求为超时状态。
作为本文实施例的一个方面,如图4所示为本文实施例一种分布式系统业务数据一致性处理系统的详细结构图,在本图中描述了更加详细的系统逻辑结构,所述第一一致性处理单元302进一步包括,
第一处理模块3021,用于将成功状态的子服务调用请求记录于所述本地服务执行历史表中,并结束;
第二处理模块3022,用于将失败状态的子服务调用请求记录于所述本地服务执行历史表中,并向相应的子服务提供系统400重发所述子服务调用请求,接收所述子服务提供系统400反馈的服务执行结果;
第三处理模块3023,用于将超时状态的子服务调用请求记录于所述本地服务执行历史表中。
作为本文实施例的一个方面,所述第二处理模块3022进一步包括,
计算模块30221,用于计算重发所述子服务调用请求的时间,如果超过了第一时间门限,所述子服务调用请求的状态均为失败状态,则报错退出。
作为本文实施例的一个方面,所述第二处理模块3022进一步包括,
反向子服务调用请求模块30222,用于向与造成报错退出的子服务调用请求相关联的其他子服务调用请求对应的子服务提供系统发送反向子服务调用请求,使得所述对应的子服务提供系统执行反向子服务调用请求回滚已经执行成功的子服务调用请求。
作为本文实施例的一个方面,所述第二一致性处理单元303进一步包括,
第四处理模块3031,用于对所述本地服务执行历史表中状态为超时状态的子服务调用请求生成查询请求;
第五处理模块3032,用于向相应的子服务提供系统发送所述查询请求;
第六处理模块3033,用于接收所述相应的子服务提供系统反馈的服务执行结果。
作为本文实施例的一个方面,所述第六处理模块3033中进一步用于,如果在第二时间门限未接收到所述相应的子服务提供系统反馈的服务执行结果,则所述本地服务执行历史表中状态为超时状态的子服务调用请求依然为超时状态,并通知所述第五处理模块3032向所述相应的子服务提供系统重发所述查询请求;
当到达第三时间门限为止始终未收到所述相应的子服务提供系统反馈的服务执行结果,则报错退出。
作为本文实施例的一个方面,所述第三一致性处理单元304进一步包括,
第七处理模块3041,用于读取所述本地服务执行历史表中状态为超时状态或失败状态的子服务调用请求;
第八处理模块3042,用于将读取子服务调用请求发送到消息队列;
所述子服务提供系统400包括消息中间件401和执行单元402,其中,
所述消息中间件401,用于获取所述消息队列中的子服务调用请求;
所述执行单元402,用于执行所述子服务调用请求;
第九处理模块3043,用于接收所述子服务提供系统400的服务执行结果。
作为本文实施例的一个方面,所述第三一致性处理单元304与所述第一一致性处理单元302以及第二一致性处理单元303同时进行处理。
作为本文实施例的一个方面,还包括第四一致性处理单元305,用于对所述本地服务执行历史表中处于第二特定状态的子服务调用请求进行第四一致性处理;接收所述子服务提供系统400根据所述第四一致性处理反馈的服务执行结果,返回所述第一一致性处理单元302。
作为本文实施例的一个方面,所述第四一致性处理单元305进一步包括,
第十处理模块3051,用于抽取所述本地服务执行历史表中处于第二特定状态的子服务调用请求;
第十一处理模块3052,用于将抽取的子服务调用请求形成数据核对文件,并发送到子服务提供系统400;
所述子服务提供系统400进一步包括,比对单元403,用于利用所述数据核对文件与服务执行状态表比对后反馈的服务执行结果;
第十二处理模块3053,用于接收所述子服务提供系统利用所述数据核对文件与服务执行状态表比对后反馈的服务执行结果。
通过上述本文实施例的系统,通过将不同的一致性处理进行结合,可以进一步确保分布式系统中数据的一致性,并且通过第一一致性处理、第二一致性处理与第三一致性处理和第四一致性处理同时进行,可以提高失败的子服务调用请求再次尝试在子服务提供系统中执行并获得成功的可能性。
如图5所示为本文实施例一种分布式系统业务数据一致性处理方法的整体流程图,该图中描述了本文业务数据一致性处理方法的整体流程,本文实施例中以用户进行贷款开户作为总的业务服务内容,在该总业务服务中包括了若干子服务调用请求,例如包括调用银行核心存款系统把贷款的金额存入个人的存款银行卡账户,新增客户信息等,当贷款开户业务过程中需要新增客户信息时,客户信息统一都存放在子服务提供系统中,此时就需要服务调用系统(即执行贷款开户业务的系统)调用子服务提供系统(即客户信息系统)以完成新增客户的业务服务需求。与该方法对应的系统结构可以参考附图6所示,在该系统中包括了服务调用系统601以及子服务提供系统602,在分布式系统中可以具有多个完成相同或者不同服务的子服务提供系统,在本实施例中仅表示出一个子服务提供系统602,本文实施例并不限制子服务提供系统的数量,每个子服务提供系统都执行相同的流程方法,还包括消息队列603以及文件处理系统604,该系统中所执行的方法具体包括如下步骤:
步骤501,根据新增客户的业务需求,生成相应的子服务调用请求。
在本步骤中,生成的子服务调用请求为新增客户的请求,并且该子服务调用请求包括唯一流水号,以及能够提供该新增客户服务的子服务提供系统的地址。
生成唯一流水号的方式可以包括,由安全节点的编号,即具有银行系统中的加密信息的计算机(加密的编号例如为10000)、服务调用系统的标识符(例如机器编号)、时间、序列号等内容组成,所述产生子服务调用请求的时间可以精确到毫秒级别,并且可以取贷款开户业务开始之前的时间,或者还可以取每个子服务调用请求产生的时间,这样就可以确保产生的唯一流水号的唯一性。
步骤502,将子服务调用请求发送给相应的子服务提供系统。
在本步骤中,根据子服务提供系统的地址找到相应的服务调用接口,例如可以包括子服务提供系统接收该服务调用请求的端口号,安全验证规则等通信信息,根据这些通信信息将包括唯一流水号的服务调用请求发送给相应的子服务提供系统。
步骤503,子服务提供系统接收到子服务调用请求后,执行该子服务调用请求。
在本步骤中,子服务提供系统可以采用特定的软件、硬件功能模块来实现新增客户的服务调用请求,但是子服务提供系统由于需要处理所有关于客户信息的业务服务,例如新增客户、查询客户信息、删除客户信息等,因此并不是每一个子服务调用请求都会执行成功,或者可能需要将子服务调用请求挂起,等待某些优先级别高的调用请求执行完毕后才能执行该子服务调用请求,因此也存在延迟执行的可能。
在子服务提供系统中具有服务执行状态表,其中记录有子服务调用请求的唯一流水号以及该子服务调用请求执行结果,即该子服务调用请求执行的结果为成功状态,或者失败状态,如下表1所示:
表1
步骤504,子服务提供系统将子服务调用请求的服务执行结果通过通信接口反馈给服务调用系统。
在本步骤中,子服务提供系统根据服务执行状态表将子服务调用请求的服务执行结果反馈给服务调用系统。由于服务调用请求发送和服务执行结果反馈都是基于实时通信的机制,因此该通信接口可以响应实时需求,实时接收和发送信息。
但是在本步骤中,由于网络延迟、通信故障、系统问题、程序问题等多方面的原因可能造成子服务调用请求的服务执行结果可能反馈不及时,造成子服务调用请求的状态不能及时反馈给服务调用系统,这也就是各系统之间业务数据不一致问题产生的原因。
步骤505,服务调用系统根据接收到的服务执行结果,执行相应操作。
在本步骤中,当服务执行结果中的子服务调用请求为成功状态,则将该子服务调用请求记录于服务调用系统的本地服务执行历史表中,并将子服务调用请求的状态记录为成功状态,并跳过后续的步骤结束本文实施例的业务数据一致性处理方法。
当服务执行结果中的子服务调用请求为失败状态,则将该子服务调用请求记录于服务调用系统的本地服务执行历史表中,并将子服务调用请求的状态记录为失败状态;然后在一段时间内重发向子服务提供系统的通信接口发送该子服务调用请求,以使得子服务提供系统可以重复尝试执行该服务调用请求;当超过一段时间后,该子服务调用请求的状态还是为失败状态,则向人工管理接口报错,由服务调用系统的管理人员向子服务提供系统的管理人员发出分析失败原因的需求,从而可以得到该子服务调用请求执行失败的原因,同时还将向贷款开户业务相关的其他子服务提供系统发送反向子服务调用请求,请求这些子服务提供系统反向执行相应子服务调用请求,即反向执行在贷款开户业务中所涉及的在其他子服务提供系统中已经执行成功的子服务调用请求,将分布式系统中各个与贷款开户业务相关的子服务提供系统、服务调用系统中的业务数据保持一致。
当服务调用系统在一段时间内始终未收到子服务提供系统反馈的服务执行结果,则将该子服务调用请求记录于服务调用系统的本地服务执行历史表中,并将子服务调用请求的状态记录为超时状态。
步骤506,子服务提供系统根据服务调用系统发出的反向子服务调用请求进行反向操作。
由于每个子服务提供系统的功能结构都类似,虽然在本实施例中子服务提供系统602并不一定执行反向操作,但是为了说明业务数据一致性处理的流程方法表达了服务调用系统对于其他与本次贷款开户业务相关的子服务提供系统发出反向子服务调用请求的步骤,并且在子服务提供系统接收到反向子服务调用请求后,会执行与子服务调用请求处理步骤完全相反的步骤来消除业务数据上的不一致性。在本实施例中如果原子服务调用请求是新增客户信息,那么相应的反向子服务调用请求就是删除客户信息,每个更新类的子服务调用请求,即对数据库进行增、删、改等操作的服务调用请求,当服务调用系统出现错误或者子服务提供系统出现错误等情况时,都会自动调用这个反向子服务调用请求来完成回滚。
步骤507,根据服务调用系统的本地服务执行历史表中的子服务调用请求的状态,向子服务提供系统发出查询请求。
在本步骤中,服务调用系统查询本地服务执行历史表中子服务调用请求的状态,当子服务调用请求为超时状态时,生成查询请求,其中至少包括超时状态子服务调用请求的唯一流水号,通过子服务提供系统的实时查询通信接口将查询请求发送给子服务提供系统。
步骤508,子服务提供系统根据查询请求查询服务执行状态表,并反馈查询结果。
查询唯一流水号的子服务调用请求在服务执行状态表中的状态,由于在服务执行状态表中的子服务调用请求只有两个状态,即成功状态或失败状态,因此只会向服务调用系统反馈这两种状态的服务执行结果。
步骤509,当子服务调用请求的状态为失败状态时,重复执行该子服务调用请求。
在本步骤中,子服务提供系统在查询到子服务调用请求为失败状态时,可以跳转回步骤504,将再次执行该子服务调用请求,如果执行成功,则将改写服务执行状态表中该子服务调用请求的状态为成功状态;如果反复执行该子服务调用请求后还是失败状态,则保持服务执行状态表中该子服务调用请求的状态为失败状态。
通过再次执行该子服务调用请求,可以通过步骤504中的通信接口将服务执行结果,即子服务调用请求成功或者失败状态的信息反馈给服务调用系统。
步骤510,如果在一预定时间内没有接收到子服务提供系统反馈的查询结果,则重复发送查询请求。
在本步骤中,如果查询请求的重复发送次数,或者重复时间超过预定门限时,则报错退出。
步骤511,根据接收到的查询结果更新本地服务执行历史表。
在本步骤中,根据查询结果得到的子服务调用请求的成功状态、失败状态更新本地服务执行历史表中对应子服务调用请求的状态。
步骤512,判断本地服务执行历史表中子服务调用请求的状态是否为成功状态,如果为成功状态则服务调用结束,否则返回步骤502。
本文实施例的业务数据一致性处理方法中还包括可以与上述步骤505至步骤512同时进行的步骤513,读取本地服务执行历史表中状态为超时状态或者失败状态的子服务调用请求。
在本步骤中,成功状态的子服务调用请求不必再处理,仅需要对超时状态和失败状态的子服务调用请求继续处理。读取本地服务执行历史表中超时状态或者失败状态的子服务调用请求可以由服务调用系统的消息管理单元实时进行,也可以通过上述步骤512中判断为失败状态的子服务调用请求后,向消息管理单元发出通知而进行本步骤。
步骤514,消息管理单元将读取出来的子服务调用请求发送到消息队列中。
在本步骤中,消息管理单元将读取出来的子服务调用请求转换为kafka消息形式,并将转换行时候的消息发送到kafka消息队列。
步骤515,子服务提供系统的消息中间件监实时监听消息队列。
在本步骤中,子服务提供系统的消息中间件坚挺到kafka消息队列中出现新的子服务调用请求后,读取该子服务调用请求。
步骤516,在服务执行状态表中查询对应子服务调用请求的状态。
步骤517,如果消息队列中的子服务调用请求为超时状态进行相应处理。
在本步骤中,如果由于网络等原因造成服务调用系统中服务执行历史表中的子服务调用请求的状态为超时状态,而查询服务执行状态表中的子服务调用请求为成功状态,此时可以返回步骤504中的处理过程;如果服务执行状态表中的子服务调用请求为失败状态,此时可以返回步骤503中的处理过程。
步骤518,如果消息队列中的子服务调用请求为失败状态进行相应处理。
在本步骤中,如果服务调用系统中服务执行历史表中的子服务调用请求的状态为失败状态,则在子服务提供系统中返回步骤503的处理过程,再次执行该子服务调用请求。
在上述步骤517和步骤518中,当子服务提供系统再次执行完子服务调用请求后,会产生相应的服务执行结果,即子服务调用请求的状态可能发生改变,在子服务提供系统侧将会更新服务执行状态表中的子服务调用请求的状态,并且还将通过步骤504中的通信接口将子服务调用请求的状态反馈给服务调用系统。
本文实施例的业务数据一致性处理方法中还包括可以与上述步骤505至步骤518同时进行的步骤519,抽取本地服务执行历史表中处于超时状态和失败状态的子服务调用请求。
在本步骤中,文件处理系统604将服务调用系统的本地服务执行历史表中处于超时状态和失败状态的子服务调用请求抽取出来形成数据核对文件。
步骤520,通过文件传输通道将数据核对文件发送给子服务提供系统。
在本步骤中,在预定时间,例如每天中午12点以及夜间12点将特定状态的子服务调用请求从本地服务执行历史表中抽取出来后,将其形成数据核对文件,通过文件传输通道发送给子服务提供系统。
步骤521,子服务提供系统将数据核对文件与服务执行状态表中的子服务调用请求进行比较。
步骤522,如果数据核对文件中子服务调用请求的状态与服务执行状态表中的子服务调用请求状态不一致,则将服务执行状态表中的子服务调用请求状态反馈给服务调用系统。
在本步骤中,如果数据核对文件中子服务调用请求的状态为超时状态,所述子服务提供系统中服务执行状态表中的子服务调用请求为成功状态,则会通过步骤504中的通信接口反馈子服务调用请求的成功状态。
步骤523,如果数据核对文件中子服务调用请求的状态与服务执行状态表中的子服务调用请求状态都是失败状态,则重复执行该子服务调用请求。
在本步骤中,如果数据核对文件中子服务调用请求的状态为失败状态,所述子服务提供系统中服务执行状态表中的子服务调用请求为失败状态(或者服务执行状态表中没有该子服务调用请求),则进入步骤503在子服务提供系统中执行该子服务调用请求,并将服务执行结果,例如成功状态或失败状态,通过所述步骤504的通信接口反馈子服务调用请求的状态。
通过上述本文实施例的方法,通过将不同的一致性处理进行结合,可以进一步确保分布式系统中数据的一致性,并且提高了出现不一致问题时的处理速度;通过将多种业务数据一致性处理的手段同时进行,可以提高失败的子服务调用请求再次尝试在子服务提供系统中执行并获得成功的可能性。
如图7所示为本文实施例服务调用系统以及子服务提供系统的装置结构示意图,在本实施例中装置称为计算设备,计算设备702可以包括一个或多个处理设备704,诸如一个或多个中央处理单元(CPU),每个处理单元可以实现一个或多个硬件线程。计算设备702还可以包括任何存储资源706,其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的,比如,存储资源706可以包括以下任一项或多种组合:任何类型的RAM,任何类型的ROM,闪存设备,硬盘,光盘等。更一般地,任何存储资源都可以使用任何技术来存储信息。进一步地,任何存储资源可以提供信息的易失性或非易失性保留。进一步地,任何存储资源可以表示计算设备702的固定或可移除部件。在一种情况下,当处理设备704执行被存储在任何存储资源或存储资源的组合中的相关联的指令时,计算设备702可以执行相关联指令的任一操作。计算设备702还包括用于与任何存储资源交互的一个或多个驱动机构708,诸如硬盘驱动机构、光盘驱动机构等。
计算设备702还可以包括输入/输出模块710(I/O),其用于接收各种输入(经由输入设备712)和用于提供各种输出(经由输出设备714))。一个具体输出机构可以包括呈现设备716和相关联的图形用户接口718(GUI)。计算设备702还可以包括一个或多个网络接口720,其用于经由一个或多个通信链路722与其他设备交换数据。一个或多个通信总线724将上文所描述的部件耦合在一起。
通信链路722可以以任何方式实现,例如,通过局域网、广域网(例如,因特网)、点对点连接等、或其任何组合。通信链路722可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。
本文实施例还提供了一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如下步骤:
根据业务的需求,产生至少一个子服务调用请求发送给相应的子服务提供系统;
根据所述子服务提供系统反馈的服务执行结果进行第一一致性处理,并将所述第一一致性处理后所述子服务调用请求的状态记录于本地服务执行历史表中;
对所述本地服务执行历史表中经过所述第一一致性处理的处于第一特定状态的子服务调用请求进行第二一致性处理,并根据所述子服务提供系统的服务执行结果更新所述本地服务执行历史表中子服务调用请求的状态;
对所述本地服务执行历史表中处于第二特定状态的子服务调用请求进行第三一致性处理;
接收所述子服务提供系统根据所述第三一致性处理反馈的服务执行结果,返回所述第一一致性处理步骤。
本文实施例提供的计算机设备还可以实现如图2、图5中的方法。
对应于图2、图5中的方法,本文实施例还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述方法的步骤。
本文实施例还提供一种计算机可读指令,其中当处理器执行所述指令时,其中的程序使得处理器执行如图2、图5所示的方法。
应理解,在本文的各种实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本文实施例的实施过程构成任何限定。
还应理解,在本文实施例中,术语“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系。例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B这三种情况。另外,本文中字符“/”,一般表示前后关联对象是一种“或”的关系。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本文的范围。
所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本文所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接,也可以是电的,机械的或其它的形式连接。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的目的。
另外,在本文各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本文的技术方案本质上或者说对现有技术做出贡献的部分,或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本文中应用了具体实施例对本文的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本文的方法及其核心思想;同时,对于本领域的一般技术人员,依据本文的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本文的限制。
- 一种分布式系统业务数据一致性处理方法、装置
- 一种基于分布式系统的业务对象的处理方法和装置