事务处理方法、装置、设备及计算机可读存储介质
技术领域
本发明实施例涉及计算机技术领域,尤其涉及一种事务处理方法、装置、设备及计算机可读存储介质。
背景技术
在现代系统中,分布式事务有着多种解决方案,包括两阶段提交(Two-phaseCommit,简称2PC),TCC(Try-Confirm-Cancel)分布式事务机制,以及基于消息队列(Message Queue,简称MQ)的最大努力通知等。
目前,基于MQ实现的分布式事务主要是基于定时任务的消息表扫描方案,主要步骤如下:开启本地事务,业务系统执行更新业务数据库,在同一数据库对应的MQ表插入一条记录,提交本地事务,定时任务扫描消息表将MQ发出。
在实现本发明过程中,发明人发现现有技术中至少存在如下问题:
基于定时任务的消息表扫描方案强依赖定时任务扫描消息表,扫描频率太快会对业务数据库本身造成压力,且定时任务的扫描存在较长的时间间隔,消息触达不及时,影响业务系统的性能。
发明内容
本发明实施例提供一种事务处理方法、装置、设备及计算机可读存储介质,用以解决基于定时任务的消息表扫描方案会对业务数据库本身造成压力,且存在较长的时间间隔,消息触达不及时,影响业务系统的性能的问题。
一方面,本发明实施例提供一种事务处理方法,包括:
在开启本地事务后,生成所述本地事务的消息记录,并将所述消息记录保存到对应的业务数据库中,所述消息记录至少包括所述本地事务对应的业务通用唯一标识、待发送的消息和消息状态;
注册Spring事务事件;
响应于监听到事务成功事件,进行事务提交,发送所述消息。
在一种可能的实施方式中,还包括:
若所述消息发送成功,则将所述消息记录中的消息状态由第一状态更新为第二状态,所述第一状态用于表示消息尚未发送,所述第二状态用于表示消息发送成功;若所述消息发送失败,则将所述消息记录中的消息状态由第一状态更新为第三状态,所述第三状态用于表示消息发送失败。
在一种可能的实施方式中,所述生成所述本地事务的消息记录之后,还包括:将所述消息记录同步到状态查询服务对应的中心数据库中;
将所述消息记录中的消息状态由第一状态更新为第二状态之后,还包括:同步更新所述中心数据库上的所述消息记录。
在一种可能的实施方式中,还包括:
接收所述状态查询服务的回调请求,所述回调请求为所述状态查询服务根据所述中心数据库内消息记录中的消息状态发出的;根据所述回调请求中的事务标识,查询所述业务数据库中的目标记录,所述目标记录为包含所述事务标识的消息记录;根据所述目标记录中的消息状态,进行对应的异常处理。
在一种可能的实施方式中,根据所述目标记录中的消息状态,进行对应的异常处理,包括:
若所述目标记录中的消息状态为第一状态或第三状态,则重新执行所述本地事务。
在一种可能的实施方式中,根据所述目标记录中的消息状态,进行对应的异常处理,包括:
若所述目标记录中的消息状态为第二状态,则同将所述状态查询服务上所述目标记录中的消息状态更新为第二状态。
在一种可能的实施方式中,所述消息记录保存在所述业务数据库中的本地事务表中。
在一种可能的实施方式中,在开启本地事务后,生成所述本地事务的消息记录之前,还包括:
获取对应数据源。
在一种可能的实施方式中,将所述消息记录保存到对应业务数据库中之后,还包括:
同步更新中心数据库上的所述消息记录。
另一方面,本发明实施例提供一种事务处理方法,应用于分布式事务系统中一个业务系统的消息组件,所述消息组件与用于执行本地事务的业务服务运行于同一进程中,所述方法包括:
在在开启本地事务后,生成所述本地事务的消息记录,并将所述消息记录保存到对应的业务数据库中,所述消息记录至少包括所述本地事务对应的业务通用唯一标识、待发送的消息和消息状态;
注册Spring事务事件;
响应于监听到事务成功事件,进行事务提交,发送所述消息。
另一方面,本发明实施例提供一种事务处理装置,包括:
消息记录模块,用于在开启本地事务后,生成所述本地事务的消息记录,并将所述消息记录保存到对应的业务数据库中,所述消息记录至少包括所述本地事务对应的业务通用唯一标识、待发送的消息和消息状态;
事务处理模块,用于:注册Spring事务事件;响应于监听到事务成功事件,进行事务提交,发送所述消息。
在一种可能的实施方式中,所述事务处理模块还用于:
若所述消息发送成功,则将所述消息记录中的消息状态由第一状态更新为第二状态,所述第一状态用于表示消息尚未发送,所述第二状态用于表示消息发送成功;若所述消息发送失败,则将所述消息记录中的消息状态由第一状态更新为第三状态,所述第三状态用于表示消息发送失败。
在一种可能的实施方式中,所述事务处理模块还用于:生成所述本地事务的消息记录之后,将所述消息记录同步到状态查询服务对应的中心数据库中;将所述消息记录中的消息状态由第一状态更新为第二状态之后,同步更新所述中心数据库上的所述消息记录。
在一种可能的实施方式中,所述事务处理模块还用于:
接收所述状态查询服务的回调请求,所述回调请求为所述状态查询服务根据所述中心数据库内消息记录中的消息状态发出的;根据所述回调请求中的事务标识,查询所述业务数据库中的目标记录,所述目标记录为包含所述事务标识的消息记录;根据所述目标记录中的消息状态,进行对应的异常处理。
在一种可能的实施方式中,所述事务处理模块还用于:
若所述目标记录中的消息状态为第一状态或第三状态,则重新执行所述本地事务。
在一种可能的实施方式中,所述事务处理模块还用于:
若所述目标记录中的消息状态为第二状态,则同将所述状态查询服务上所述目标记录中的消息状态更新为第二状态。
在一种可能的实施方式中,所述消息记录保存在所述业务数据库中的本地事务表中。
在一种可能的实施方式中,消息记录模块还用于:获取对应数据源。
在一种可能的实施方式中,所述事务处理模块还用于:
同步更新中心数据库上的所述消息记录。
本发明实施例提供的装置可以具体用于执行上述实施例二所提供的方法实施例,具体功能此处不再赘述。
另一方面,本发明实施例提供一种事务处理设备,包括:
处理器,存储器,以及存储在所述存储器上并可在所述处理器上运行的计算机程序;
其中,所述处理器运行所述计算机程序时实现上述所述的事务处理方法。
另一方面,本发明实施例提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机程序,所述计算机程序被处理器执行时实现上述所述的事务处理方法。
本发明实施例提供的事务处理方法、装置、设备及计算机可读存储介质,通过在开启本地事务后,生成本地事务的消息记录,并将消息记录持久化保存到对应的业务数据库中,进行事务的预提交,并没有真正发送消息;通过注册Spring事务事件;在监听到Spring发布的事务成功事件时进行事务提交,此时将消息发送出去,能够在事务提交成功后及时地发送消息,不用等待定时任务扫描业务数据库,既能够及时发送消息,又能减少业务数据库的压力,能够提高业务系统的性能。
附图说明
图1为本发明实施例一提供的事务处理方法流程图;
图2为本发明实施例一提供的本地事务表的创建语句的示例;
图3为本发明实施例二提供的事务处理方法流程图;
图4为本发明实施例二提供的配置对应的MQ的程序代码示例;
图5为本发明实施例二提供的消息发送的程序代码示例;
图6为本发明实施例三提供的事务处理装置的结构示意图;
图7为本发明实施例五提供的事务处理设备的结构示意图。
通过上述附图,已示出本发明明确的实施例,后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本发明构思的范围,而是通过参考特定实施例为本领域技术人员说明本发明的概念。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。
首先对本发明实施例所涉及的名词进行解释:
OpenMessaging:一种统一消息中间件实现通信规范。
JMQ:一使用发布订阅机制开发的消息中间件。
此外,术语“第一”、“第二”等仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中,“多个”的含义是两个以上,除非另有明确具体的限定。
本发明实施例具体应用于需要处理分布式事务的分布式系统。本实施例中,分布式系统包括多个业务系统、多个业务数据库和一个中心服务系统,每个业务数据库上创建有本地事务表,用于存储各业务系统的事务处理过程中产生的消息记录。业务系统提供消息组件,消息组件能够在本地事务执行过程中向对应业务数据库中的本地事务表存储消息记录,也即是预提交事务息,本地事务处理成功后,进行事务提交和消息的实际发送,并更新对应本地事务表中的消息记录,既能提高消息发送及时性,也能减少业务数据库的压力,提供业务系统的性能。另外,中心服务系统中同步存储有各个业务数据库的本地事务表,并提供状态查询服务(也即是check服务)。check服务根据预设策略查询消息记录,并根据消息记录的状态回调业务系统的消息组件,使得业务系统的消息组件查询对应的业务数据库中本地事务表中对应的消息记录,并根据消息记录的实际状态执行对应的异常处理。通常,通过业务系统在提交事务后发送消息,并进行对应消息记录状态的更新,对于大多数事务,都能够正常完成提交、消息发送和消息记录状态的修改,只有少部分可能会出现事务执行异常、消息发送异常或者记录状态修改异常,导致同步存储到状态查询服务对应中心数据库中的消息记录中所记录的状态异常,需要回调业务系统的消息组件。check服务不需要扫描业务数据库,可以减少业务数据库的压力。
下面以具体地实施例对本发明的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图,对本发明的实施例进行描述。
实施例一
图1为本发明实施例一提供的事务处理方法流程图。本发明实施例针对现有技术中基于定时任务的消息表扫描方案会对业务数据库本身造成压力,且存在较长的时间间隔,消息触达不及时,影响业务系统的性能的问题,提供了事务处理方法。本实施例中的方法应用于业务系统,可以是业务系统中的消息组件(或消息服务)。如图1所示,该方法具体步骤如下:
步骤S101、在开启本地事务后,生成本地事务的消息记录,并将消息记录保存到对应的业务数据库中,消息记录至少包括本地事务对应的业务通用唯一标识、待发送的消息和消息状态。
本实施例中,业务系统可以至少可以提供业务服务和消息组件,业务服务用于执行业务流程,消息组件用于向消息中心发送消息等。其中,业务服务和消息组件运行在同一进程中。
示例性地,业务数据库中包括用于存储消息记录的本地事务表,可以预先在各个业务数据库中创建本地事务表。例如,可以采用如图2所示的语句进行本地事务表(如图2中的tripods_task表)的创建。
其中,消息记录至少包括本地事务对应的业务通用唯一标识、待发送的消息和该消息的消息状态。另外,如图2中所示,消息记录还可以包括:自增主键、事务标识、消息主题、创建时间、更新时间、消息内容等等。
本地事务启动后,业务服务执行对应的业务流程。在事务处理过程中,业务数据库中业务表的操作和本地事务表的持久化必须在同一个事务中,在同一个事务中消息组件并将本地事务的消息记录持久化保存到对应业务数据库的本地事务表中,此时,消息对于监听方不可见,只是进行消息的记录。
其中,消息状态可以包括准备、进行中、发送成功、发送失败以及默认值等,当初始化是消息状态为准备,当消息记录存储到本地事务之后,消息状态更新为进行中,当消息发送成功时消息状态更新为发送成功,当消息发送失败时消息状态更新为发送失败。另外,消息状态可以根据实际应用场景进行设定和调整,本实施例此处不再赘述。
步骤S102、注册Spring事务事件。
步骤S103、响应于监听到事务成功事件,进行事务提交,发送消息。
本实施例中,通过向Spring注册事务事件,在事务成功后Spring通过用于发布事件的接口(如ApplicationEventPubulisher)自动发布事务成功事件,消息组件通过监听Spring发布的事务成功事件,及时地进行事务提交处理。
消息组件在监听到事务成功事件时,调用commit方法进行事务提交处理,此时将消息发送出去,能够在事务提交成功后及时地发送消息,提高了消息发送的及时性。
本发明实施例通过在开启本地事务后,生成本地事务的消息记录,并将消息记录持久化保存到对应的业务数据库中,进行事务的预提交,并没有真正发送消息;通过注册Spring事务事件;在监听到Spring发布的事务成功事件时进行事务提交,此时将消息发送出去,能够在事务提交成功后及时地发送消息,不用等待定时任务扫描业务数据库,既能够及时发送消息,又能减少业务数据库的压力,能够提高业务系统的性能。
图3为本发明实施例二提供的事务处理方法流程图。在上述实施例一的基础上,本实施例中,消息记录保存在业务数据库中的本地事务表中。在发送消息之后,更新业务数据库中消息记录的消息状态。在将消息记录持久化存储到业务数据库的同时,将消息记录同步到状态查询服务(也即是check服务)对应的中心数据库中,并且在业务数据库中的消息记录的消息状态更新时,同步更新中心数据库中的消息记录。check服务可以轮询对应中心数据库,并在发现消息状态异常时,回调对应业务系统的消息服务,使得消息服务进行对应的异常处理。如图2所示,该方法具体步骤如下:
步骤S201、开启本地事务。
本实施例中,业务系统可以至少可以提供业务服务和消息组件,业务服务用于执行业务流程,消息组件用于向消息中心发送消息等。其中,业务服务和消息组件运行在同一进程中。
业务服务可以开启Spring事务,然后由业务系统提供的业务服务执行对应的业务流程。
步骤S202、获取对应数据源。
示例性地,业务数据库中包括用于存储消息记录的本地事务表,可以预先在各个业务数据库中创建本地事务表。例如,可以采用如图2所示的语句进行本地事务表(如图2中的tripods_task表)的创建。
本实施例中,在事务处理过程中,业务数据库中业务表的操作和本地事务表的持久化必须在同一个事务中,在同一个事务中消息组件通过执行prepare方法,将本地事务的消息记录持久化保存到对应业务数据库的本地事务表中,此时,消息对于监听方不可见,只是进行消息的记录。
具体地,消息组件通过获取对应数据源的连接(connection),以通过数据源的connection保存消息记录到对应的业务数据库。例如,消息组件可以调用业务系统提供用于获取数据源的AutoTaskProducer接口实现数据源的获取。
步骤S203、生成本地事务的消息记录,并将消息记录保存到对应的业务数据库的本地事务表中。
消息组件生成当前事务的消息记录,并通过获取到的数据源的connection保存消息记录到业务数据库的本地事务表中。
其中,消息记录至少包括本地事务对应的业务通用唯一标识、待发送的消息和该消息的消息状态。另外,如图2中所示,消息记录还可以包括:自增主键、事务标识、消息主题、创建时间、更新时间、消息内容等等。
其中,消息状态可以包括准备、进行中、发送成功、发送失败以及默认值等,当初始化是消息状态为准备,当消息记录存储到本地事务之后,消息状态更新为进行中,当消息发送成功时消息状态更新为发送成功,当消息发送失败时消息状态更新为发送失败。另外,消息状态可以根据实际应用场景进行设定和调整,本实施例此处不再赘述。
示例性地,将消息记录保存到对应的业务数据库的本地事务表中时,消息记录中消息状态为第一状态。其中,第一状态用于表示消息尚未发送。可选地,第一状态可以为进行中。
步骤S204、将消息记录同步到check服务对应的中心数据库中。
本实施例中,在生成本地事务的消息记录之后,消息组件还将消息记录同步到check服务对应的中心数据库中。check服务可以轮询对应中心数据库中的消息记录,并在发现消息状态异常时,回调异常消息对应业务系统的消息服务,使得消息服务进行对应的异常处理。
步骤S205、调用prepare方法,进行事务预提交。
消息组件通过用prepare方法,进行事务预提交的处理,此时,消息对于监听方不可见,只是进行消息的记录。
本实施例中,调用prepare方法,进行事务预提交的实现方式与现有的2PC实现方案的第一阶段的处理类似,但是不发送消息,本实施例此处不再赘述。
步骤S206、向Spring注册事务事件。
步骤S207、响应于监听到Spring发布的事务成功事件,进行事务提交,发送消息。
本实施例中,通过向Spring注册事务事件,在事务成功后Spring通过用于发布事件的接口(如ApplicationEventPubulisher)自动发布事务成功事件,消息组件通过监听Spring发布的事务成功事件,及时地进行事务提交处理。
示例性地,如图3中所示,Spring事务可以向消息组件提交事务成功的异步消息,消息组件接收到该异步消息时,确认监听到事务成功事件。
消息组件在监听到事务成功事件时,调用commit方法进行事务提交处理,此时将消息发送出去,能够在事务提交成功后及时地发送消息,提高了消息发送的及时性。
本实施例中,调用commit方法进行事务提交处理与现有的2PC实现方案的第二阶段的处理过程类似,本实施例此处不再赘述。
步骤S208、更新本地事务表中对应消息记录的消息状态。
本实施例中,在发送消息后,更新本地事务表中对应消息记录的消息状态。
具体地,更新本地事务表中对应消息记录的消息状态至少包括:若消息发送成功,则将消息记录中的消息状态由第一状态更新为第二状态;若消息发送失败,则将消息记录中的消息状态由第一状态更新为第三状态。
示例性地,所述第一状态用于表示消息尚未发送,所述第二状态用于表示消息发送成功,所述第三状态用于表示消息发送失败。例如,第一状态可以为进行中,第二状态可以为发送成功,第三状态为发送失败。
步骤S209、同步更新中心数据库上的消息记录。
本实施例中,在业务数据库的本地事务表中的消息记录有更新时,需要同步更新中心数据库上对应的消息记录,以保持中心数据库上的消息记录的准确性。
步骤S210、接收check服务的回调请求,回调请求为check服务根据中心数据库内消息记录中的消息状态发出的。
本实施例中,check服务轮询中心数据库中的消息记录时,如果确定消息记录的消息状态为消息异常状态,则根据消息记录中的事务标识,向对应的消息组件发送回调请求。回调请求中包括该事务标识。
示例性地,若消息记录的状态为第一状态,且消息状态保持为第一状态的时长大于设定时间阈值,确定消息状态异常。
可选的,若消息记录的状态为准备或者进行中,且根据消息记录的更新时间,若确定消息状态保持在当前状态的时长大于设定时间阈值,则确定消息状态异常。
步骤S211、根据回调请求中的事务标识,查询业务数据库中的目标记录,目标记录为包含事务标识的消息记录。
在接收到check服务的回调请求后,消息组件根据回调请求中的事务标识,查询对应的本地事务表中包含事务标识的目标记录。
步骤S212、根据目标记录中的消息状态,进行对应的异常处理。
在找到与回调请求对应的目标记录之后,根据目标记录中的消息状态,进行对应的异常处理。
具体地,根据目标记录中的消息状态,进行对应的异常处理,至少包括以下几种情况:
第一种情况是:目标记录中的消息状态为第一状态,也即是消息状态为进行中,则说明事务在规定的时间内没有完成事务正常提交,此时重新执行本地事务。
第二种情况是:目标记录中的消息状态为第三状态,也即是消息状态为发送失败,则说明没有完成事务的正常提交,此时则重新执行本地事务。
第三种情况是:目标记录中的消息状态为第二状态,即是消息状态为发送成功,则说明已经完成事务的正常提交,此时可以确定是消息记录没有完成向中心数据库的同步,则同将check服务上目标记录中的消息状态更新为第二状态。
另外,本实施例中,当消息记录中的消息状态异常时,可能还需要进行事务的回滚等处理,具体处理过程可以采用现有技术中的方式实现,此处不再赘述。
示例性地,本实施例中的消息组件可以以插件的方式实现,能够快速接入系统以实现同业务系统之间的分布式事务,可以实现消息毫秒级别快速触达,同时分布式事务稳定可靠,易于使用和维护。
本实施例中,业务表的操作和本地事务表的持久化必须在同一个事务中,在同一个事务中执行prepare方法,此时消息对于监听方不可见,只是进行消息记录,事务成功提交后Spring通过用于发布事件的接口ApplicationEventPubulisher发布事务成功事件(Event),消息组件监听到事务成功事件自动调用commit方法进行事务提交,此时消息对外可见,消息组件将实时发送消息。如果没有收到commit消息,本地事务表中消息记录状态为准备或者进行中的状态,check机制触发回调,通过回调查询本地事务表中的记录来决定最终是commit(发送消息)还是rollback(取消发送)。
本消息组件的实现基于业务数据库中的本地事务表,将分布式事务拆分为本地事务,基于数据库中事务的ACID特性实现硬性事务,保证数据的一致性。通过事务消息的2PC机制进行实现,支持JMQ,实现了OpenMesssaging事务规范。
本发明实施例中的消息组件,基于本地事务表和2PC,使用CHECK机制作为消息发送异常的检查和补偿机制,实现事务的最终一致性。另外,本方案实现对客户端的屏蔽,对已有业务没有侵入。
本实施例的一种实施方式中,系统可以分为以下模块:核心接口模块(也可以称为tripods-core),消息中间件模块(也可以称为tripods-manoeuvre)和事务规则模块(也可以称为tripods-oms)三个模块。其中,tripods-core模块是核心接口的定义,支持SPI的自定义实现,有默认实现,定义了一组高度可扩展的规则。tripods-manoeuvre则是为了支持没有事务消息的消息中间件,比如JMQ2,提供了check机制的实现。Tripods-oms则是基于OpenMessaging事务规则的通用实现,包括两阶段提交以及check机制。
其中,本实施例提供的消息组件(也就是消息中间件模块tripods-manoeuvre)是一个通过2PC和check机制实现的At Leaset One应用,主要由客户端(Client)端和服务(server)端构成,实现了2PC和check机制,可以支持JMQ。tripods-oms模块使用了OpenMessaging的事务消息,符合此规范的消息中间件都被tripods-oms所支持。
在进行部署时,首先需要接入应用,在对应的业务数据库中建立本地事务表,例如,可以采用如2所示的语句创建本地事务表。其次在工程中引入消息组件相关jar包,并配置对应的MQ。例如,可以通过图4所示的代码实现JMQ的配置。示例性地,可以使用XML或YML进行配置。
进一步地,可以通过自定义的静态方法实现消息的发送。例如,如图5中所示的自定义TripodsProducer里面的send静态方法。其中,send静态方法中的第一个参数为消息的主题(Topic),第二个参数是消息内容,第三个参数用于防重,可以是如图2中所示的“业务主键,UUID”,第四个参数是切分键值(单库忽略),在分库分表中,用于找到对应数据源的数据库。
本发明实施例通过将本地事务表同步存储到check服务对应的中心数据库中,check服务不再反复扫描业务数据库,而是轮询中心数据库中的消息记录,并在发现消息状态异常时,向消息组件发送回调请求,由消息组件查询对应业务数据库中的本地事务表,能够大大减少业务数据库的访问次数,减少业务数据库的访问压力,同时业务系统无需向check提供业务查询接口,提高了业务数据库的安全性,能够提高业务系统的性能。
图6为本发明实施例三提供的事务处理装置的结构示意图。本发明实施例提供的事务处理装置可以执行事务处理方法实施例提供的处理流程。如图6所示,该事务处理装置30包括:消息记录模块301和事务处理模块302。
具体地,消息记录模块301用于在开启本地事务后,生成本地事务的消息记录,并将消息记录保存到对应的业务数据库中,消息记录至少包括本地事务对应的业务通用唯一标识、待发送的消息和消息状态。
事务处理模块302用于:注册Spring事务事件;响应于监听到事务成功事件,进行事务提交,发送消息。
本发明实施例提供的装置可以具体用于执行上述实施例一所提供的方法实施例,具体功能此处不再赘述。
本发明实施例通过在开启本地事务后,生成本地事务的消息记录,并将消息记录持久化保存到对应的业务数据库中,进行事务的预提交,并没有真正发送消息;通过注册Spring事务事件;在监听到Spring发布的事务成功事件时进行事务提交,此时将消息发送出去,能够在事务提交成功后及时地发送消息,不用等待定时任务扫描业务数据库,既能够及时发送消息,又能减少业务数据库的压力,能够提高业务系统的性能。
在上述实施例三的基础上,本实施例中,事务处理模块还用于:
若消息发送成功,则将消息记录中的消息状态由第一状态更新为第二状态;若消息发送失败,则将消息记录中的消息状态由第一状态更新为第三状态。
在一种可能的实施方式中,事务处理模块还用于:生成本地事务的消息记录之后,将消息记录同步到状态查询服务对应的中心数据库中;将消息记录中的消息状态由第一状态更新为第二状态之后,同步更新中心数据库上的消息记录。
在一种可能的实施方式中,事务处理模块还用于:
接收状态查询服务的回调请求,回调请求为状态查询服务根据中心数据库内消息记录中的消息状态发出的;根据回调请求中的事务标识,查询业务数据库中的目标记录,目标记录为包含事务标识的消息记录;根据目标记录中的消息状态,进行对应的异常处理。
在一种可能的实施方式中,事务处理模块还用于:
若目标记录中的消息状态为第一状态或第三状态,则重新执行本地事务。
在一种可能的实施方式中,事务处理模块还用于:
若目标记录中的消息状态为第二状态,则同将状态查询服务上目标记录中的消息状态更新为第二状态。
在一种可能的实施方式中,消息记录保存在业务数据库中的本地事务表中。
在一种可能的实施方式中,消息记录模块还用于:获取对应数据源。
在一种可能的实施方式中,事务处理模块还用于:
同步更新中心数据库上的消息记录。
本发明实施例提供的装置可以具体用于执行上述实施例二所提供的方法实施例,具体功能此处不再赘述。
本发明实施例通过将本地事务表同步存储到check服务对应的中心数据库中,check服务不再反复扫描业务数据库,而是轮询中心数据库中的消息记录,并在发现消息状态异常时,向消息组件发送回调请求,由消息组件查询对应业务数据库中的本地事务表,能够大大减少业务数据库的访问次数,减少业务数据库的访问压力,同时业务系统无需向check提供业务查询接口,提高了业务数据库的安全性,能够提高业务系统的性能。
图7为本发明实施例五提供的事务处理设备的结构示意图。如图7所示,该事务处理设备100包括:处理器1001,存储器1002,以及存储在存储器1002上并可在处理器1001上运行的计算机程序。
其中,处理器1001运行计算机程序时实现上述任一方法实施例提供的事务处理方法。
本发明实施例通过在开启本地事务后,生成本地事务的消息记录,并将消息记录持久化保存到对应的业务数据库中,进行事务的预提交,并没有真正发送消息;通过注册Spring事务事件;在监听到Spring发布的事务成功事件时进行事务提交,此时将消息发送出去,能够在事务提交成功后及时地发送消息,不用等待定时任务扫描业务数据库,既能够及时发送消息,又能减少业务数据库的压力,能够提高业务系统的性能。
另外,本发明实施例还提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机程序,计算机程序被处理器执行时实现上述任一方法实施例提供的事务处理方法。
本领域技术人员可以清楚地了解到,为描述的方便和简洁,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本发明的其它实施方案。本发明旨在涵盖本发明的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本发明的真正范围和精神由下面的权利要求书指出。
应当理解的是,本发明并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求书来限制。