本技术涉及计算机,具体涉及一种数据一致性检测方法、装置、电子设备、计算机可读存储介质及计算机程序产品。
背景技术:
1、在互联网应用中,应用服务的主要功能是处理服务请求,返回数据给客户端。通常服务请求处理并不是单一应用服务能够处理完成,不同应用服务之间由于划分功能不同,所提供的能力是不相同的。所以应用服务经常需要进行跨应用服务调用。
2、目前,常见的保障应用服务之间的数据一致性的方法主要包括以下几种:
3、一、两阶段提交(two-phase commit,2pc):两阶段提交为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种协议。通常,二阶段提交也被称为是一种协议(protocol)。在分布式系统中,每个节点虽然可以知晓自己的操作是成功还是失败,却无法知道其他节点的操作是成功还是失败。当一个事务跨越多个节点时,为了保证事务的acid的特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。
4、二、三阶段提交(three-phase commit,3pc):三阶段提交是为解决两阶段提交协议的缺点而设计的。与两阶段提交不同的是,三阶段提交是“非阻塞”协议。三阶段提交在两阶段提交的第一阶段与第二阶段之间插入了一个准备阶段,使得原先在两阶段提交中,参与者在投票之后,由于协调者发生崩溃或错误,而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。
5、三、补偿事务(try-confirm-cancel,tcc):针对每个操作,都需要有一个其对应的确认和取消操作。当操作成功时调用确认操作,当操作失败时调用取消操作,类似于二阶段提交,只不过是这里的提交和回滚是针对业务上的,所以基于tcc实现的分布式事务也可以看做是对业务的一种补偿机制。
6、但是,上述几种方法,2pc协议的问题是同步阻塞,在二阶段提交的执行过程中,所有参与该事务操作的逻辑都处于阻塞状态。另外,2pc协议还存在的问题是默认失败,在2pc中,只有协调者拥有超时机制,即如果在一定时间内没有收到参与者的消息则默认失败。3pc协议解决解决了2pc的同步阻塞问题,但是没有解决默认失败的问题。tcc增加了默认补偿机制,但是代码有非常高的侵入性和开发成本,维护非常困难。
7、并且,上述几种保障数据一致性的方法的都属于强代码耦合手段,一方面对于新的应用服务,需要开发人员在编写功能时就按照上述协议进行编写,应用服务的调用方和应用的服务的被调用方遵守该协议。另一方面对于老的应用服务就需要按照上述方式改造,成本较大,侵入性很高。并且对于数据一致性的情况,技术人员也很难进行整理把控。
8、即相关技术中,跨应用服务的调用失败会导致应用服务之间出现数据不一致的问题。
技术实现思路
1、本技术实施例提供一种数据一致性检测方法、装置、电子设备及存储介质,以保证跨应用服务之间的数据一致性。
2、本技术实施例的一方面提供一种数据一致性检测方法,包括:获取待检数据,所述待检数据包括来自第一应用服务的第一待检数据以及来自第二应用服务的第二待检数据,其中,所述第一应用服务和所述第二应用服务为用于执行同一服务请求的多个应用服务中的任意两个;若所述第一待检数据和所述第二待检数据不满足预设一致性规则,执行第一处理,以使执行同一服务请求的所述第一应用服务与所述第二应用服务产生的数据保持一致。
3、在一些实施例中,所述获取待检数据,包括:若当前时刻与所述服务请求的生成时刻之间的时间差大于或等于第一预设时间,获取所述待检数据。
4、在一些实施例中,所述获取所述待检数据,包括:获取所述第一待检数据中的第一确认数据,所述第一确认数据用于表征所述第一应用服务已向所述第二应用服务发送跨服调用请求;获取所述第二待检数据中的第二确认数据,所述第二确认数据用于表征所述第二应用服务已向所述第一应用服务发送针对所述跨服调用请求的第一处理结果;获取所述第一待检数据中的第三确认数据,所述第三确认数据用于表征所述第一应用服务已接收到所述第一处理结果。
5、在一些实施例中,所述若所述第一待检数据和所述第二待检数据不满足预设一致性规则,执行第一处理,包括:若在所述预设延迟时间内未获取到所述第一确认数据、所述第二确认数据或所述第三确认数据,执行第一处理;其中,所述预设延迟时间为获取到相邻两个数据之间的最大时间间隔。
6、在一些实施例中,所述第一待检数据包括与所述服务请求相关的第一业务数据;所述第二待检数据包括与所述服务请求相关的第二业务数据。
7、在一些实施例中,所述若所述第一待检数据和所述第二待检数据不满足预设一致性规则,执行第一处理,包括:若所述第一业务数据和所述第二业务数据不匹配,执行第一处理。
8、在一些实施例中,所述第一待检数据为通过受检日志开发工具包实时获取的所述第一应用服务的第一受检日志数据,所述第二待检数据为通过所述受检日志开发工具包实时获取的所述第二应用服务的第二受检日志数据。
9、在一些实施例中,所述获取待检数据,包括:基于第一数据库和第二数据库,获取多组所述待检数据,每组所述待检数据包括一个所述第一待检数据以及与所述第一待检数据相对应的所述第二待检数据;其中,所述第一待检数据存储于所述第一数据库,所述第二待检数据存储于所述第二数据库。
10、在一些实施例中,所述第一数据库用于存储所述第一应用服务的历史数据,所述第二数据库用于存储所述第二应用服务的历史数据;所述基于第一数据库和第二数据库,获取多组所述待检数据,包括:获取预设时间间隔内的所述第一数据库中的第一历史数据以及所述第二数据库中的第二历史数据;从所述第一历史数据中筛选出多个所述第一待检数据,并从所述第二历史数据中筛选出与所述多个第一待检数据分别对应的多个所述第二待检数据,以生成多组所述待检数据。
11、在一些实施例中,所述若所述第一待检数据和所述第二待检数据不满足预设一致性规则,执行第一处理,包括:检测每组所述待检数据中的所述第一待检数据和所述第二待检数据的一致性;若所述待检数据中的所述第一待检数据和所述第二待检数据不匹配,针对不匹配的所述待检数据执行第一处理。
12、在一些实施例中,所述第一数据库为用于存储所述第一应用服务的历史业务数据的第一业务数据库,所述第二数据库为用于存储所述第二应用服务的历史业务数据的第二业务数据库;或者,所述第一数据库为用于存储所述第一应用服务的历史受检日志数据的第一受检日志数据库,所述第二数据库为用于存储所述第二应用服务的历史受检日志数据的第二受检日志数据库;或者,所述第一数据库为用于对所述第一应用服务进行分析的第一数据仓库,所述第二数据库为用于对所述第二应用服务进行分析的第二数据仓库。
13、在一些实施例中,所述执行第一处理,包括:通过预设方式调用具有补偿功能的外部服务,以进行补偿处理。
14、在一些实施例中,所述方法还包括:若所述外部服务调用失败且所述外部服务的尝试调用次数大于或等于第一阈值,发送警告信息。
15、在一些实施例中,所述执行第一处理,包括:执行预设脚本;所述方法还包括:若所述预设脚本执行失败且所述预设脚本的尝试执行次数大于或等于第二阈值,发送警告信息。
16、本技术实施例的另一方面提供一种数据一致性检测装置,包括:获取单元,用于获取待检数据,所述待检数据包括来自第一应用服务的第一待检数据以及来自第二应用服务的第二待检数据,其中,所述第一应用服务和所述第二应用服务为用于执行同一服务请求的多个应用服务中的任意两个;执行单元,用于若所述第一待检数据和第二待检数据不满足预设一致性规则,执行第一处理。
17、本技术实施例的另一方面提供一种电子设备,包括:处理器;以及存储器,用于存储处理器的可执行指令;其中,处理器配置为经由执行可执行指令来执行如上任一实施例所述的方法。
18、本技术实施例的另一方面提供一种计算机可读存储介质,计算机可读存储介质存储有计算机程序,计算机程序被处理器执行时实现如上任一实施例所述的方法。
19、本技术实施例的另一方面提供一种计算机程序产品,包括计算机程序,其特征在于,计算机程序被处理器执行时实现如上任一实施例的方法。
20、本技术实施例提供的数据一致性检测方法、装置、电子设备及存储介质,通过包括:获取待检数据,待检数据包括来自第一应用服务的第一待检数据以及来自第二应用服务的第二待检数据,其中,第一应用服务和第二应用服务为用于执行同一服务请求的多个应用服务中的任意两个;若第一待检数据和第二待检数据不满足预设一致性规则,执行第一处理,以使执行同一服务请求的第一应用服务与第二应用服务产生的数据保持一致,从而可以检验应用服务之间的数据是否满足预设一致性规则,当不满足时,可以对相关应用服务进行第一处理,从而使得应用服务的数据保持一致,保障了跨服调用时的应用服务之间的数据一致性。