一种事务一致性管理引擎及方法

技术领域

本发明涉及数据库技术领域，尤其涉及一种事务一致性管理引擎及方法。

背景技术

联机事务处理(On-Line Transaction Processing，OLTP)系统和联机分析处理(Online Analytical Processing，OLAP)系统是异构的两种数据库系统，它们适用于不同的使用场景，OLTP数据库适用于事务性操作的场景，而OLAP系统适用于分析性操作的场景。针对两种功能进行分别优化，既能满足OLTP的需求也能满足OLAP需求的系统，称为混合事务分析处理(Hybrid Transaction and Analysis Processing，HTAP)系统。OLTP的数据会定期同步导入OLAP系统中。

现有技术中，从OLTP系统到OLAP系统进行数据同步是基于变更日志进行的，其原理为：订阅OLTP库的变更日志，根据变更日志将数据变更应用到OLAP系统。这种方案不能很好地适应OLTP库是由多个分数据库组成的分布式数据库，每个分数据库产生独立的变更日志的场景。由于分布式系统的特点，对于同一事务涉及各分数据库产生的变更日志被应用到OLAP系统可能存在时间的先后，在仅有其中一条变更日志应用，另一条还未应用的阶段，从OLAP系统中读取数据可能会产生违背事务一致性的结果。

发明内容

本发明提供了一种事务一致性管理引擎及方法，以实现事务一致性，保证了事务分析的正确性。

第一方面，本实施例提供了一种事务一致性管理引擎，包括：事务处理系统、分析处理系统以及事务一致性管理系统；其中，

事务处理系统，包含至少一个分数据库，各所述分数据库对应一个日志缓冲区；

所述分数据库，用于根据接收的事务提交指令，生成包含日志类型的事务变更日志，并将所述事务变更日志缓存至相应的日志缓冲区；

事务一致性管理系统，用于根据各所述日志缓冲区中事务变更日志的日志类型，确定所述事务处理系统对应的目标增量数据，并将所述目标增量数据同步至所述分析处理系统。

第二方面，本实施例提供了一种事务一致性管理方法，由第一方面实施例所述的事务一致性管理引擎执行，所述事务一致性管理引擎包括事务处理系统、分析处理系统以及事务一致性管理系统，事务处理系统，包含至少一个分数据库，各所述分数据库对应一个日志缓冲区，所述方法包括：

通过所述分数据库根据接收的事务提交指令，生成包含日志类型的事务变更日志，并将所述事务变更日志缓存至相应的日志缓冲区；

通过所述事务一致性管理系统根据各所述日志缓冲区中事务变更日志的日志类型，确定所述事务处理系统对应的目标增量数据，并将所述目标增量数据同步至所述分析处理系统。

本发明实施例公开了一种事务一致性管理引擎及方法，该系统包括：事务处理系统、分析处理系统以及事务一致性管理系统；其中，事务处理系统，包含至少一个分数据库，各所述分数据库对应一个日志缓冲区；所述分数据库，用于根据接收的事务提交指令，生成包含日志类型的事务变更日志，并将所述事务变更日志缓存至相应的日志缓冲区；事务一致性管理系统，用于根据各所述日志缓冲区中事务变更日志的日志类型，确定所述事务处理系统对应的目标增量数据，并将所述目标增量数据同步至所述分析处理系统。利用该系统，对事务变更日志中增加了事务提交时间戳的内容，对于事务处理系统中包含多个分数据库的情况，保证同一事务涉及的事务变更日志均被应用后的增量数据作为目标增量数据，并同步给分析处理系统，实现了事务一致性，保证了事务分析的正确性。

应当理解，本部分所描述的内容并非旨在标识本发明的实施例的关键或重要特征，也不用于限制本发明的范围。本发明的其它特征将通过以下的说明书而变得容易理解。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一提供的一种事务一致性管理引擎的结构示意图；

图2为本发明实施例一提供的另一种事务一致性管理引擎的结构示意图；

图3为本发明实施例一提供的生成一阶段提交日志的交互过程示例图；

图4为本发明实施例一提供的事务处理系统发送二阶段指令过程的示例图；

图5为本发明实施例一提供的生成二阶段预提交日志的交互过程示例图；

图6为本发明实施例一提供的生成二阶段提交日志的交互过程示例图；

图7为本发明实施例一提供的生成二阶段回滚日志的交互过程示例图；

图8为本发明实施例一提供的另一种事务一致性管理引擎的结构示意图；

图9为本发明实施例一提供的安全时间戳的更新过程的示例图；

图10为本发明实施例一提供的增量数据确定过程的示例图；

图11为本发明实施例二提供的一种事务一致性管理方法的流程示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要知道的是，OLTP和OLAP是异构的两种数据库系统，它们适用于不同的使用场景，OLTP数据库适用于事务性操作，而OLAP系统(也称为数据仓库)适用于分析性操作的场景。将事务和分析功能都跑在同一个OLTP数据库或者OLAP系统上会导致性能不佳。针对两种功能进行分别优化，既能满足OLTP的需求也能满足OLAP的系统，称为HTAP系统。为了适应分析操作场景，OLTP的数据会定期同步导入OLAP系统中，通过访问OLAP系统可以进行分析操作。

考虑到现有技术中，基于变更日志从OLTP系统到OLAP系统进行数据同步的原理是：订阅OLTP库的变更日志，根据变更日志将数据变更应用到OLAP系统。这种方案不能很好地适应OLTP库是由多个分数据库组成的分布式数据库，每个分数据库产生独立的变更日志的场景，在这种场景下从OLAP系统中读取数据可能会产生违背事务一致性的结果。例如，在一个业务中，账户1和账户2分别存储在分数据库A和分数据库B中，某一次交易从账户1向账户2转账了100元，此时数据库A产生了“减100元”的日志，数据库B产生了“增100元”的日志，但是由于分布式系统的特点，两条日志被应用到OLAP系统可能存在时间的先后，在仅有其中一条日志应用，另一条还未应用的阶段，用户从OLAP系统中查询多个账户的总金额就会读到错误的结果。导致HTAP系统存在事务不一致性问题。

实施例一

图1为本发明实施例一提供的一种事务一致性管理引擎的结构示意图，本实施例适用于实现事务一致性的情况，该引擎可以由硬件和/或软件实现。该引擎包括：事务处理系统10、分析处理系统30以及事务一致性管理系统20；其中，事务处理系统10，包含至少一个分数据库11，各分数据库11对应一个日志缓冲区；分数据库11，用于根据接收的事务提交指令，生成包含日志类型的事务变更日志，并将事务变更日志缓存至相应的日志缓冲区；事务一致性管理系统20，用于根据各日志缓冲区中事务变更日志的日志类型，确定事务处理系统对应的目标增量数据，并将目标增量数据同步至分析处理系统。

本实施例提供的事务一致性管理引擎可以理解为HTAP系统的核心部分，用于支持HTAP系统实现事务一致性。该引擎包括事务处理系统10、分析处理系统30以及事务一致性管理系统20。其中，事务处理系统10是指OLTP系统，分析处理系统30是指OLAP系统。事务处理系统10，包含至少一个分数据库11，各分数据库11对应一个日志缓冲区。

可以知道的是，用户执行事务的过程包括：请求开启事务、执行数据操纵语言(Data Manipulation Language,DML)进行数据操作、请求提交事务，当用户执行这些操作后，这些操作会发给事务处理系统10。事务处理系统10接收这些操作，并根据这些操作执行相应的内容。

首先，当用户请求开启事务时，事务处理系统10生成当前事务的事务标识号(Identity document,ID)。此时“当前事务的分数据库集合”为空。然后，当用户执行DML进行每一条数据操作时，事务处理系统10先判断数据操作涉及哪一个分数据库，如果这个分数据库已经在“当前事务的分数据库集合”中，则直接在该分数据库上执行数据操作；如果这个分数据库还不在“当前事务的分数据库集合”中，则先在该分数据库上执行开启分事务请求，然后在该分数据库上执行数据操作。最后，在用户发起提交事务的请求时，事务处理系统10根据变更数据的分布向分数据库下达不同的事务提交指令，分数据库会产生不同类型的变更日志。

可以理解的是，若用户执行的事务只涉及一个数据库，则事务处理系统10只需要向该事务涉及的一个分数据库发送事务提交指令。若用户执行的事务涉及至少两个分数据库，则事务处理系统10需要向该事务涉及的每一个分数据库发送事务提交指令。另外，对于只涉及一个分数据库，或者涉及至少两个分数据库，其会对分数据库发送不同类型的事务提交指令。

分数据库11，用于根据接收的事务提交指令，生成包含日志类型的事务变更日志，并将事务变更日志缓存至相应的日志缓冲区。

在本实施例中，当分数据库11接收到事务处理系统10发送的事务提交请求后，分数据库11根据事务提交指令，生成对应类型的事务变更日志。其中，事务变更日志的格式可以表示为：[日志头部|日志负载]，日志头部可以包含事务ID、日志类型、日志负载的长度，日志负载可以包含事务执行的具体内容等。示例性的，事务变更日志的日志类型包括：一阶段提交、二阶段预提交、二阶段提交以及二阶段回滚。对于只涉及一个分数据库的事务，分数据库接收到的事务提交指令为一阶段提交，则分数据库会生成一阶段提交日志。对于涉及多个分数据库的事务，分数据库接收到的事务提交指令为二阶段提交。

在本实施例中，每个分数据库11对应一个日志缓冲区，分数据库11可以将事务变更日志缓存至相应的日志缓冲区中。其具体缓存过程可以表述为：每个分数据库分别对应不同的日志抽取线程，日志抽取线程可以负责不同分数据库中事务变更日志的读取，日志抽取线程不断读取所负责的分数据库写入的新的事务变更日志，将读取的日志放到对应的日志缓冲区的尾部。

事务一致性管理系统20，用于根据各日志缓冲区中事务变更日志的日志类型，确定事务处理系统10对应的目标增量数据，并将目标增量数据同步至分析处理系统。

本实施例中，事务一致性管理系统20作为事务一致性管理引擎的子系统，可以对日志缓冲区中的事务变更日志进行处理，根据事务变更日志确定出事务处理系统10对应的增量数据，本实施例中记为目标增量数据。事务一致性管理系统20将确定出的目标增量数据同步到分析处理系统30中。

考虑到现有技术中，由于同一事务的不同分数据库生成的事务变更日志应用时序可能存在不一致，当处于一部分日志先应用，另一部分日志还未应用的阶段，则导致只能根据先应用的日志确定出增量数据，进一步导致确定出的增量数据不是完整的增量数据。示例性的，在一个业务中，账户1和账户2分别存储在分数据库A和分数据库B中，某一次交易从账户1向账户2转账了100元，此时数据库A产生了“减100元”的日志，数据库B产生了“增100元”的日志，但是由于分布式系统的特点，两条日志被应用到分析处理系统可能存在时间的先后，在仅有其中一条日志应用，另一条还未应用的阶段，用户从分析处理系统30中查询多个账户的总金额就会读到错误的结果。

因此，为了保证同步到分析处理系统30中的增量数据是完整的，需要保证同一事务涉及的分数据库生成的日志均应用到分析处理系统30后，确定出最终增量数据，将该增量数据同步到分析处理系统30，从而避免用户从分析处理系统30中查询数据出现错误的结果。继续接上述示例进行描述，即需要将数据库A产生了“减100元”的日志，数据库B产生了“增100元”的日志都应用到分析处理系统30后，确定出最终增量数据，并将增量数据同步至分析处理系统30。

在本实施例中，事务变更日志可能是一阶段提交日志、二阶段预提交日志、二阶段提交日志以及二阶段回滚日志。可以理解的是，对于只涉及一个分数据库的执行事务来说，由于只涉及一个分数据库会产生事务变更日志，事务一致性管理系统20只需要获取该事务变更日志里的内容，就可以确定目标增量数据。本实施例中对于涉及一个分数据库的事务，采用一阶段提交，使分数据库在接收到一阶段提交指令时，生成一阶段提交日志。

而对于涉及两个或者两个以上分数据库的事务来说，其涉及到各分数据库中的事务变更日志应用到分析处理系统的时间顺序。为了解决该问题，本实施例中对于涉及多分数据库的事务，采用二阶段提交，使各分数据库在接收到二阶段提交的不同指令时，生成不同类型的事务变更日志。其中，二阶段提交对应的事务变更日志包括二阶段预提交日志、二阶段提交日志、二阶段回滚日志。

在本实施例中，在二阶段提交日志中添加事务提交时间戳，其中，事务提交时间戳可以理解为事务最终提交的时间。不同的日志缓冲区中包含不同分数据库产生的事务变更日志。事务一致性管理系统20会反复对日志缓冲区中涉及的数据进行批量合并，然后生成目标增量数据。

在本实施例中，事务一致性管理系统20可以针对每个日志缓冲区确定出增量数据，再将各缓冲区涉及的增量数据进行合并，确定为目标增量数据。为了保证确定出的目标增量数据是完整的，需要保证解析出的事务执行涉及的各分数据库的事务变更日志是完整的。因此，本实施例中需要确定出一个时间节点，在该时间节点之前可以保证事务的完整的，也就是各分数据库中的对应该事务的事务变更日志已均被应用。

为了确定出该时间节点，可以针对每个日志缓冲区，按顺序依次获取日志缓冲区中的事务变更日志，根据事务变更日志的类型，确定该日志缓冲区对应的时间节点。可以理解的是，对于一阶段提交日志，不涉及事务提交时间戳，所以一阶段提交日志对时间节点无影响，可忽略。对二阶段提交产生的各类型日志中，二阶段提交日志表征事务最终提交，且二阶段提交日志中包含事务提交时间戳，因此，可以根据获取的二阶段提交日志确定各日志缓冲区的时间节点。

进一步，当确定出各日志缓冲区中的时间节点后，可以从各时间节点中选出能够表征在时间点前，各分数据库涉及的事务变更日志为完整的事务的时间节点。基于该时间节点，可以确定出该时间节点前的事务变更日志确定的增量数据包含事务涉及各分数据库的增量数据，从而可以保证事务一致性。可以理解的是，随着分数据库中不断生成事务变更日志，事务变更日志不断缓存至日志缓冲区中，确定的时间节点是会变化的，进一步使日志缓冲区中的事务变更日志被不断解析，确定出目标增量数据。

当确定出目标增量数据后，可以将目标增量数据同步至分析处理系统30。随着事务的执行，会不断确定出新的目标增量数据，并将目标增量数据同步至分析处理系统30中。分析处理系统30中采用了一种常用的存储方式：增量存储。原始版本的数据存储在基础文件中，每一次事务一致性管理系统20进行一次批量合并后，都会生成一个新的版本存储在一个增量文件里。分析处理系统30在处理用户的分析类请求时，先读取每一个基础文件和增量文件的所有内容。然后根据用户的查询请求生成的过滤条件对结果进行过滤，过滤不满足过滤条件的数据，生成用户需要的结果。

本发明实施例公开了一种事务一致性管理引擎，该系统包括：事务处理系统、分析处理系统以及事务一致性管理系统；其中，事务处理系统，包含至少一个分数据库，各所述分数据库对应一个日志缓冲区；所述分数据库，用于根据接收的事务提交指令，生成包含日志类型的事务变更日志，并将所述事务变更日志缓存至相应的日志缓冲区；事务一致性管理系统，用于根据各所述日志缓冲区中事务变更日志的日志类型，确定所述事务处理系统对应的目标增量数据，并将所述目标增量数据同步至所述分析处理系统。利用该系统，对事务变更日志中增加了事务提交时间戳的内容，对于事务处理系统中包含多个分数据库的情况，保证同一事务涉及的事务变更日志均被应用后的增量数据作为目标增量数据，并同步给分析处理系统，实现了事务一致性，保证了事务分析的正确性。

图2为本发明实施例一提供的另一种事务一致性管理引擎的结构示意图，本可选实施例以上述实施例一为基础进行优化，在本实施例中，事务处理系统10还包括处理服务进程12，处理服务进程12包括：第一子进程121，用于根据接收的事务提交请求，生成事务提交指令；第二子进程122，用于根据接收的各分数据库发送的响应成功消息，生成事务提交指令；发送子进程123，用于将事务提交指令发送至各分数据库。

在本可选实施例中，事务处理系统10还包括处理服务进程12，处理服务进程12可以用来处理接收到的各类请求或者生成指令，并将指令发送到涉及的分数据库中。其中事务处理系统10包括第一子进程121、第二子进程122以及发送子进程123。

第一子进程121，用于根据接收的事务提交请求，生成事务提交指令。其中，用户执行事务的过程包括请求开启事务、执行DML进行数据操作、请求提交事务，这些操作都先发给事务处理系统。当用户通过点击提交等操作，请求提交事务时，会生成事务提交请求并将事务提交请求发送至事务处理系统10中的处理服务进程12上。处理服务进程12接收到事务提交请求后，可以对事务提交请求进行解析，分析事务提交请求中包含的事务分别涉及哪几个分数据库，并根据事务提交请求，生成对应的事务提交指令。事务提交指令用于发送至涉及的各分数据库中，以使各分数据库产生相应的事务变更日志。

第二子进程122，用于根据接收的各分数据库发送的响应成功消息，生成事务提交指令。当分数据库接收到事务提交指令后，生成响应成功消息，并将响应成功消息发送至第二子进程122上。第二子进程122接收到各分数据库发送的响应成功消息后，生成事务提交指令。

发送子进程123，用于将事务提交指令发送至各分数据库。具体的，发送子进程123将事务提交指令发送至各分数据库，以使各分数据库生成与事务提交指令相应的事务变更日志。

进一步地，第一子进程121，具体用于：

a1、根据接收的事务提交请求，确定事务提交请求关联的分数据库。

具体的，当第一子进程121接收到事务提交请求时，通过对事务提交请求进行解析，确定出事务提交请求关联的分数据库，即确定事务提交请求中包括的事务执行时涉及哪些分数据库。可以理解的是，根据事务提交请求中的事务标识号可以确定与该事务关联的分数据库的集合。该事务提交请求关联的分数据库的数量为一个或者为至少两个。

b1、若分数据库为一个，则生成一阶段提交指令作为事务提交指令。

具体的，若分数据库为一个，则为一阶段提交，生成一阶段提交指令，并将一阶段提交指令作为事务提交指令。

c1、若分数据库为至少两个，则生成二阶段预提交指令作为事务提交指令。

具体的，若分数据库为至少两个，则执行二阶段提交，生成二阶段预提交指令，将二阶段预提交指令作为事务提交指令。

d1、将事务提交指令发送至分数据库。

具体的，将所述提交指令发送至事务提交请求中事务所涉及的分数据库。

进一步地，第二子进程122，具体用于：

a2、接收各分数据库发送的对二阶段预提交指令的响应成功消息。

其中，第二子进程122在涉及到分数据库为至少两个，执行二阶段提交时工作。当二阶段预提交指令发送至涉及各分数据库后，分数据库成功接收到二阶段预提交指令后会生成响应成功消息，并将响应成功消息发送至第二子进程122。第二子进程接收各分数据库发送的对二阶段预提交指令的响应成功消息。

b2、判断是否在设定时间内接收到各分数据库的响应成功消息。

具体的，判断是否在设定时间内接收到各分数据库的响应成功消息。其中，设定时间可以由历史经验值确定。

c2、若是，则获取当前时间戳作为事务提交时间戳，并根据事务提交时间戳生成二阶段提交指令作为事务提交指令。

本步骤中，若在设定时间内接收到所有关联分数据库的响应成功消息，则可以从授时中心获取当前时间戳作为事务提交时间戳，并将事务提交时间戳作为一部分内容生成二阶段提交指令，并将二阶段提交指令作为事务提交指令。

可以理解的是，当在设定时间内接收到所有关联分数据库的响应成功消息时，才会获取事务提交时间戳并生成二阶段提交指令。也可以理解为，该事务提交时间戳表示在这之前，各分数据库均已成功响应。

d2、否则，生成二阶段回滚指令作为事务提交指令。

本步骤中，若在设定时间内未接收到所有关联分数据库的响应成功消息，则生成二阶段回滚指令作为事务提交指令。

作为本发明实施例的可选实施例，本可选实施例以上述实施例一为基础进行优化，分数据库11，具体用于：

a3、接收事务处理系统发送的事务提交指令。

具体的，接收事务处理系统10发送的事务提交指令。其中，事务提交指令可能为一阶段提交指令、二阶段预提交指令、二阶段提交指令或者二阶段回滚指令。

b3、若事务提交指令为一阶段提交指令，则生成事务提交指令对应的一阶段提交日志作为事务变更日志。

具体的，若事务提交指令为一阶段提交指令，表明该事务执行时只涉及一个分数据库，则解析事务提交指令可以获得事务ID、变更数据等信息。根据获得的信息，可以生成一阶段提交日志。需要说明的是，本实施例中，事务变更日志的格式可以表示为：[日志头部|日志负载]，日志头部可以包含事务ID、日志类型、日志负载的长度，日志负载可以包含事务执行的具体内容等。而对于不同类型的事务变更日志，其日志负载内容也不相同。其中，一阶段提交日志的日志负载包含内容为事务的数据变更。并将一阶段提交日志作为事务变更日志。

示例性的，图3为本发明实施例一提供的生成一阶段提交日志的交互过程示例图。当事务处理系统发送一阶段提交指令后，涉及的分数据库生成一阶段提交日志。

c3、若事务提交指令为二阶段预提交指令，则生成事务提交指令对应的二阶段预提交日志作为事务变更日志。

具体的，若事务提交指令为二阶段预提交指令，表明该事务执行时只涉及多个分数据库，则解析事务提交指令可以获得事务ID、变更数据等信息。根据获得的信息，可以生成二阶段预提交日志。此处二阶段预提交指令的格式不再赘述。其中，二阶段预提交日志的日志负载包含内容为事务在该分数据库的数据变更。

示例性的，为了更清楚的表达事务处理系统10与分数据库11之间的交互关系，图4为本发明实施例一提供的事务处理系统发送二阶段指令过程的示例图。其过程可以表述为：

S11、事务处理系统向所有当前事务中有数据变更的分数据库发送二阶段预提交指令。

S12、事务处理系统等待所有涉及的分数据库返回“响应成功消息”直到达到预设超时。

S13、判断是否在预设超时内接收到所有涉及的分数据库的响应成功消息，若是，则执行步骤S14-S15，若否，则执行步骤S16。

S14、事务处理系统从授时中心获取当前时间戳，作为事务提交时间戳。

S15、事务处理系统向所有当前事务中有数据变更的分数据库发送二阶段提交指令。

S16、事务处理系统向所有当前事务中有数据变更的分数据库发送二阶段回滚指令。

示例性的，图5为本发明实施例一提供的生成二阶段预提交日志的交互过程示例图。当事务处理系统10向所涉及分数据库11发送二阶段预提交指令，涉及的分数据库11生成二阶段预提交日志。

d3、若事务提交指令为二阶段提交指令，则生成事务提交指令对应的二阶段提交日志作为事务变更日志。

需要说明的是，二阶段提交指令是在涉及的各分数据库11将响应成功消息均发送至事务处理系统10后，事务处理系统10再向涉及各分数据库发送二阶段提交指令。

具体的，若事务提交指令为二阶段提交指令，表明该事务执行时涉及多个分数据库，则解析事务提交指令可以获得事务ID、变更数据等信息。根据获得的信息，可以生成二阶段提交日志。此处二阶段提交日志的格式不再赘述。其中，二阶段提交日志的日志负载包含内容为事务提交时间戳。

示例性的，图6为本发明实施例一提供的生成二阶段提交日志的交互过程示例图。当事务处理系统10从授时中心40获取当前时间戳作为事务提交时间戳，然后向所涉及分数据库发送二阶段提交指令，涉及的分数据库生成二阶段提交日志。

e3、若事务提交指令为二阶段回滚指令，则生成事务提交指令对应的二阶段回滚日志作为事务变更日志。

具体的，若事务提交指令为二阶段回滚指令，表明该事务执行时涉及多个分数据库，则解析事务提交指令可以获得事务ID、变更数据等信息。根据获得的信息，可以生成二阶段回滚日志。

示例性的，图7为本发明实施例一提供的生成二阶段回滚日志的交互过程示例图。当事务处理系统10向所涉及分数据库发送二阶段回滚指令后，涉及的分数据库生成二阶段回滚日志。

f3、将事务变更日志缓存至相应的日志缓存区。

分数据库11可以将事务变更日志缓存至相应的日志缓冲区中。其具体缓存过程可以表述为：每个分数据库分别对应不同的日志抽取线程，日志抽取线程可以负责不同的分数据库中事务变更日志的读取，日志抽取线程不断读取所负责的分数据库写入的新的事务变更日志，放到对应的日志缓冲区的尾部。

图8为本发明实施例一提供的另一种事务一致性管理引擎的结构示意图，本可选实施例以上述实施例一为基础进行优化，事务一致性管理系统20，包括：第一确定模块21，用于根据各日志缓冲区中事务变更日志的日志类型，确定目标安全时间戳；第二确定模块22，用于根据各日志缓冲区中事务变更日志的日志类型，结合目标安全时间戳，确定事务处理系统对应的目标增量数据，并将目标增量数据同步至分析处理系统。

本可选实施例中，事务一致性管理系统20包括第一确定模块21和第二确定模块22。第一确定模块21和第二确定模块22可以认为是本实施例中提供的引擎中的关键模块，该关键模块用于对事务变更日志进行处理，数据合并，从而使增量数据为完整事务的增量数据。

其中，目标安全时间戳可以理解为在该时间之前的事务变更日志包含一个或多个完整事务的日志，也就是根据目标安全时间戳之前的各日志缓冲区中的事务变更日志，可以确定出一个或多个完整事务的增量数据。目标增量数据是指根据涉及的各分数据库11确定出的完整事务的增量数据。

本可选实施例中，从各日志缓冲区中依次获取事务变更日志，根据获取的事务变更日志的日志类型，可以判断该事务变更日志是否可以更新安全时间戳。可以理解的是，事务变更日志中只有二阶段提交日志包含提交时间戳，可以用来更新目标安全时间戳。

本可选实施例中，在第一确定模块21确定出目标安全时间戳后，第二确定模块22，从各日志缓冲区中依次获取事务变更日志，根据获取的事务变更日志的日志类型，结合目标安全时间戳，确定事务处理系统对应的目标增量数据，并将目标增量数据同步至分析处理系统。

可以理解的是，只涉及一个分数据库的一阶段提交日志，可以直接根据一阶段提交日志确定目标增量数据。对于涉及多个分数据库的二阶段各类型日志，需要确定目标安全时间戳之前的日志为完整事务日志，对各涉及分数据库的日志进行解析获取目标增量数据。

进一步地，继续参考图8，第一确定模块21，包括：第一确定单元211，用于针对每个日志缓冲区，根据日志缓冲区中事务变更日志的日志类型，确定日志缓冲区对应的安全时间戳；第二确定单元212，确定各安全时间戳中数值最小的安全时间戳为目标安全时间戳。

其中，第一确定模块21包含第一确定单元211和第二确定单元212。本可选实施例中，需要针对每个日志缓冲区，获取日志缓冲区中事务变更日志，根据事务变更日志中的二阶段提交日志包含的事务提交时间戳，确定日志缓冲区对应的安全时间戳。在确定出各日志缓冲区对应的安全时间戳之后，第二确定单元212确定各安全时间戳中数值最小的安全时间戳为目标安全时间戳。可以理解的是，在目标安全时间戳之前的各日志缓冲区中的事务变更日志为完整事务的日志。

进一步地，第一确定单元211，具体用于：

a4、针对每个日志缓冲区，获取日志缓冲区中当前变更日志的日志类型。

具体的，第一确定单元211需要确定出每个日志缓冲区对应的当前安全时间戳，即，需要针对每个日志缓冲区，执行步骤a4)-g4)。将读取指针指向每个日志缓冲区的头部，读取指针所指的当前变更日志，获取当前变更日志的日志类型。可以理解的是，当前变更日志的日志类型可能为一阶段提交、二阶段预提交、二阶段提交以及二阶段回滚。

b4、若当前变更日志为一阶段提交日志或者二阶段回滚日志，则不更新安全时间戳。

具体的，若当前变更日志为一阶段提交日志，则表明该当前变更日志中关联的事务只涉及一个分数据库，不需要确定安全时间戳，则不更新安全时间戳。若当前变更日志为二阶段回滚日志，其表明在设定时间内未接收到事务涉及的分数据库反馈的响应成功消息，也可以理解为有的分数据库还未对二阶段预提交指令响应，另外，一阶段提交日志和二阶段回滚日志中均不包含时间内容，因此，不更新安全时间戳。

c4、若当前变更日志为二阶段提交日志，则将当前变更日志中包含的事务提交时间戳与安全时间戳中的较大值作为新的安全时间戳。

具体的，若当前变更日志为二阶段提交日志，二阶段提交日志中包含事务提交时间戳。二阶段提交日志表示事务提交完成，因此，可以获取二阶段提交日志中包含的事务提交时间戳。

需要说明的是，在对每个日志缓冲区进行更新安全时间戳之前，需要将安全时间戳初始化为零，随着根据当前变更日志的判断，更新安全时间戳。更新安全时间戳的方式为，根据获取的事务提交时间戳与安全时间戳进行比较，将其中较大值作为新的安全时间戳。可以理解为，针对于该日志缓冲区，在新的安全时间戳之前，可以认为事务已提交。

d4、若当前变更日志为二阶段预提交日志，则判断日志缓冲区中是否包含与当前变更日志属于同一事务的二阶段提交日志或者二阶段回滚日志。

本步骤中，若当前变更日志为二阶段预提交日志，则还需要判断该日志缓冲区中是否包含与当前变更日志同属同一事务的二阶段提交日志或者二阶段回滚日志，以进一步判断是否更新安全时间戳。

e4、若包含二阶段提交日志，则不更新安全时间戳。

具体的，若该日志缓冲区中包含与当前变更日志属于同一事务的二阶段提交日志，则不更新安全时间戳，需要继续返回读取日志缓冲区中的事务变更日志，以便当读取到同一事务的二阶段提交日志时，根据二阶段提交日志中的事务提交时间戳更新安全时间戳。

f4、若包含二阶段回滚日志，则不更新安全时间戳并结束处理。

具体的，若该日志缓冲区中包含与当前变更日志属于同一事务的二阶段回滚日志，则不更新安全时间戳。且二阶段回滚日志表示在设定时间内未接收到事务涉及的分数据库反馈的响应成功消息，也可以理解为有的分数据库还未对二阶段预提交指令响应，因此，该事务还未完成提交，则不更新安全时间戳并结束处理。

g4、将日志缓冲区中的下一事务变更日志作为新的当前变更日志，返回继续执行日志缓冲区对应的安全时间戳的更新步骤，直至日志缓冲区中的事务变更日志均被遍历完结束处理。

具体的，当对当前变更日志处理完毕后，则需要移动指针将日志缓冲区中的下一事务变更日志作为新的当前变更日志，返回继续执行安全时间戳的更新步骤，直至日志缓冲区中的事务变更日志均被遍历完，则结束处理。可以理解的是，每个日志缓冲区都会确定其对应的安全时间戳，以进一步用于确定目标安全时间戳。

示例性的，为了更清楚的表述安全时间戳的更新过程，图9为本发明实施例一提供的安全时间戳的更新过程的示例图。其过程可以表述为：

S21、初始化安全时间戳。

S22、针对每个日志缓冲区，获取日志缓冲区中当前变更日志，若当前变更日志为一阶段提交日志，则执行步骤S25；若当前变更日志为二阶段回滚日志，则执行步骤S25；若当前变更日志为二阶段提交日志，则执行步骤S23；若当前变更日志为二阶段预提交日志，则执行步骤S24。

S23、将当前变更日志中包含的事务提交时间戳与安全时间戳中的较大值作为新的安全时间戳。

S24、判断日志缓冲区中是否有同一事务的二阶段提交日志或者二阶段回滚日志，若是，则执行步骤S25，若否，则执行步骤S27。

S25、判断日志缓冲区中是否还有未遍历事务变更日志，若是，则执行步骤S26，若否，则执行步骤S27。

S26、将日志缓冲区中的下一事务变更日志作为新的当前变更日志。

S27、结束处理。

继续参考图8，进一步地，第二确定模块22，包括：第三确定单元221，用于针对每个日志缓冲区，根据日志缓冲区中事务变更日志的日志类型，结合目标安全时间戳，确定日志缓冲区对应的新增数据；第四确定单元222，用于汇总各新增数据作为事务处理系统10对应的目标增量数据，并将目标增量数据同步至分析数据库11。

其中，第二确定模块22包含第三确定单元221和第四确定单元222。本可选实施例中，可以分配一个临时空间。需要针对每个日志缓冲区中的各事务变更日志，确定当前日志缓冲区对应的新增数据，并将新增数据存储至临时空间中。在确定出各日志缓冲区对应的新增数据之后，第四确定单元222汇总临时空间中的所有新增数据为目标增量数据。可以理解的是，由于根据日志缓冲区中事务变更日志的日志类型，结合目标安全时间戳，确定出新增数据。可以理解为在目标安全时间戳之前确定出各日志缓冲区对应的增量数据，是可以保证事务一致性的，也可以理解为目标增量数据是关于事务的完整变更数据。

进一步地，第三确定单元221，具体用于：

a5、针对每个日志缓冲区，获取日志缓冲区中当前变更日志的日志类型。

具体的，第三确定单元221需要确定出每个日志缓冲区对应的增量数据，即，需要针对每个日志缓冲区，执行步骤a5)-e5)。将读取指针指向每个日志缓冲区的头部，读取指针所指的当前变更日志，获取当前变更日志的日志类型。可以理解的是，当前变更日志的日志类型可能为一阶段提交、二阶段预提交、二阶段提交以及二阶段回滚。

b5、若当前变更日志为一阶段提交日志，则根据当前变更日志包含的内容，确定当前变更日志对应的增量数据。

具体的，若当前变更日志为一阶段提交日志，则表明该当前变更日志中关联的事务只涉及一个分数据库，一阶段提交日志中包含数据变更，可以根据当前变更日志包含的内容确定出该日志对应的增量数据。

c5、若当前变更日志为二阶段提交日志或者二阶段回滚日志，则确定当前变更日志无对应新增数据。

具体的，若当前变更日志为二阶段提交日志，二阶段提交日志包含的内容为事务提交时间戳，则确定当前变更日志无对应新增数据。若当前变更日志为二阶段回滚日志，则确定当前变更日志无对应新增数据。

d5、若当前变更日志为二阶段预提交日志，则根据缓冲区中包含的其他事务变更日志的日志类型，结合目标安全时间戳，确定当前变更日志对应的增量数据。

具体的，若当前变更日志为二阶段预提交日志，则需要继续判断缓冲区中包含的其他事物变更日志的日志类型，判断其他事务变更日志为二阶段回滚日志或者二阶段提交日志，并进一步结合目标安全时间戳，确定当前变更日志对应的增量数据。

e5、将所述当前变更日志从日志缓冲区中移除，并将日志缓冲区中的下一事务变更日志作为新的当前变更日志，返回继续执行当前变更日志对应的新增数据的确定步骤，直至日志缓冲区中无事务变更日志结束处理。

具体的，当对当前变更日志处理完毕后，则将所述当前变更日志从日志缓冲区中移除，并需要移动指针将日志缓冲区中的下一事务变更日志作为新的当前变更日志，返回继续执行新增数据的确定步骤，直至日志缓冲区中无事务变更日志，则结束处理。可以理解的是，每个日志缓冲区都会确定其对应的新增数据，以进一步用于确定目标新增数据。

进一步地，第三确定单元221用于执行根据缓冲区中包含的其他事务变更日志的日志类型，确定当前变更日志对应的增量数据的步骤，包括：

a6、获取日志缓冲区中包含的其他事务变更日志。

b6、判断其他事务变更日志是与当前变更日志属于同一事务的二阶段提交日志还是二阶段回滚日志。

具体的，获取其他事务变更日志的日志类型，判断其他事务变更日志是与当前变更日志属于同一事务的二阶段提交日志还是二阶段回滚日志。

c6、若是二阶段回滚日志，则确定当前变更日志无对应新增数据。

具体的，若存在其他事务变更日志是与当前变更日志属于同一事务的二阶段回滚日志，则表明该事务还未完成最终提交，则确定当前变更日志无对应新增数据。

d6、若是二阶段提交日志，则判断二阶段提交日志中包含的事务提交时间戳是否小于或者等于目标安全时间戳。

具体的，若存在其他事务变更日志是与当前变更日志属于同一事务的二阶段提交日志，则需要获取二阶段提交日志中包含的事务提交时间戳，并将事务提交时间戳与目标安全时间戳比较。

e6、若是，则根据当前变更日志中包含的内容，确定当前变更日志对应的增量数据。

具体的，由于目标安全时间戳表示事务涉及的各分数据库均已完成数据变更，因此，若事务提交时间戳小于或者等于目标安全时间戳，表示该二阶段提交日志为已完成提交的事务的日志，进一步根据当前变更日志中包含的内容，确定当前变更日志对应的增量数据。

f6、否则，结束处理。

具体的，若事务提交时间戳大于目标安全时间戳，表示该事务涉及的各分数据库还未完全提交，则结束本次处理。可以理解的是，随着事务的执行，会有新的事务变更日志存储至日志缓冲区中，以进行下一次目标增量数据确定。

示例性的，为了更清楚的表述增量数据的确定过程，图10为本发明实施例一提供的增量数据确定过程的示例图。其过程可以表述为：

S31、针对每个日志缓冲区，获取日志缓冲区中当前变更日志。若当前变更日志为二阶段提交日志，则执行步骤S36；若当前变更日志为二阶段回滚日志，则执行步骤S36；若当前变更日志为一阶段提交日志，则执行步骤S32；若当前变更日志为二阶段预提交日志，则执行步骤S33。

S32、将当前变更日志中包含的增量数据放入临时空间。

S33、判断日志缓冲区中是否有同一事务的二阶段提交日志或者二阶段回滚日志，若为二阶段提交，则执行步骤S34，若为二阶段回滚，则执行步骤S36。

S34、对应的事务提交时间戳是否小于或等于目标安全时间戳，若是，则执行步骤S35，若否，则执行步骤S39。

S35、将当前变更日志中包含的增量数据放入临时空间。

S36、将当前变更日志从日志缓冲区中移除。

S37、判断日志缓冲区中是否还有事务变更日志，若是，则执行步骤S38，若否，则执行步骤S39。

S38、将日志缓冲区中的下一事务变更日志作为新的当前变更日志。

S39、结束处理。

本可选实施例，基于目标安全时间戳，将事务变更日志转换成增量数据，可以保证每个增量存储文件里保存的都是一个或多个完整的事务包含的变更，从而分析处理系统只要读取完整完整的增量文件，即可保证分析处理系统也具有事务一致性。

实施例二

图11为本发明实施例二提供的一种事务一致性管理方法的流程示意图，该方法适用于实现事务一致性的情况。该方法可以由上述实施例提供的事务一致性管理引擎执行，该引擎可以由硬件和/或软件实现。该事务一致性管理引擎包括事务处理系统、分析处理系统以及事务一致性管理系统，事务处理系统，包含至少一个分数据库，各所述分数据库对应一个日志缓冲区。如图11所示，本实施例二提供的一种事务一致性管理方法，具体包括如下步骤：

S410、通过分数据库根据接收的事务提交指令，生成包含日志类型的事务变更日志，并将事务变更日志缓存至相应的日志缓冲区。

可以知道的是，用户执行事务的过程包括：请求开启事务、DML数据操作、请求提交事务，当用户执行这些操作后，这些操作会发给事务处理系统。事务处理系统接收这些操作，并根据这些操作执行相应的内容。

首先，当用户请求开启事务时，事务处理系统生成当前事务的事务ID。此时“当前事务的分数据库集合”为空。然后，当用户执行DML进行每一条数据操作时，事务处理系统先判断数据操作涉及哪一个分数据库，如果这个分数据库已经在“当前事务的分数据库集合”中，则直接在该分数据库上执行数据操作；如果这个分数据库还不在“当前事务的分数据库集合”中，则先在该分数据库上执行开启分事务请求，然后在该分数据库上执行数据操作。最后，在用户发起提交事务的请求时，事务处理系统根据变更数据的分布向分数据库下达不同的事务提交指令，分数据库会产生不同类型的变更日志。

可以理解的是，若用户执行的事务只涉及一个数据库，则事务处理系统只需要向该事务涉及的一个分数据库发送事务提交指令。若用户执行的事务涉及至少两个分数据库，则事务处理系统需要向该事务涉及的每一个分数据库发送事务提交指令。另外，对于只涉及一个分数据库，或者涉及至少两个分数据库，其会对分数据库发送不同类型的事务提交指令。

在本实施例中，当分数据库接收到事务处理系统发送的事务提交请求后，分数据库根据事务提交指令，生成对应类型的事务变更日志。其中，事务变更日志的格式可以表示为：[日志头部|日志负载]，日志头部可以包含事务ID、日志类型、日志负载的长度，日志负载可以包含事务执行的具体内容等。示例性的，事务变更日志的日志类型包括：一阶段提交、二阶段预提交、二阶段提交以及二阶段回滚。对于只涉及一个分数据库的事务，分数据库接收到的事务提交指令为一阶段提交，则分数据库会生成一阶段提交日志。对于涉及多个分数据库的事务，分数据库接收到的事务提交指令为二阶段提交。

在本实施例中，每个分数据库对应一个日志缓冲区，分数据库可以将事务变更日志缓存至相应的日志缓冲区中。其具体缓存过程可以表述为：每个分数据库分别对应不同的日志抽取线程，日志抽取线程可以负责不同的分数据库中事务变更日志的读取，日志抽取线程不断读取所负责的分数据库写入的新的事务变更日志，将读取的日志放到对应的日志缓冲区的尾部。

S420、通过事务一致性管理系统根据各日志缓冲区中事务变更日志的日志类型，确定事务处理系统对应的目标增量数据，并将目标增量数据同步至分析处理系统。

本实施例中，事务一致性管理系统作为事务一致性管理引擎的子系统，可以对日志缓冲区中的事务变更日志进行处理，根据事务变更日志确定出事务处理系统对应的增量数据，本实施例中记为目标增量数据。事务一致性管理系统将确定出的目标增量数据同步到分析处理系统中。

考虑到现有技术中，由于同一事务的不同分数据库生成的事务变更日志应用时序可能存在不一致，当处于一部分日志先应用，另一部分日志还未应用的阶段，则导致只能根据先应用的日志确定出增量数据，进一步导致确定出的增量数据不是完整的增量数据。因此，为了保证同步到分析处理系统中的增量数据是完整的，需要保证同一事务涉及的分数据库生成的日志均应用到分析处理系统后，确定出最终增量数据，将该增量数据同步到分析处理系统，从而避免用户从分析处理系统中查询数据出现错误的结果。

在本实施例中，事务变更日志可能是一阶段提交日志、二阶段预提交日志、二阶段提交日志以及二阶段回滚日志。可以理解的是，对于只涉及一个分数据库的执行事务来说，由于只涉及一个分数据库会产生事务变更日志，事务一致性管理系统只需要获取该事务变更日志里的内容，就可以确定目标增量数据。本实施例中对于涉及一个分数据库的事务，采用一阶段提交，使分数据库在接收到一阶段提交指令时，生成一阶段提交日志。

而对于涉及两个或者两个以上分数据库的事务来说，其涉及到各分数据库中的事务变更日志应用到分析处理系统的时间顺序。为了解决该问题，本实施例中对于涉及多分数据库的事务，采用二阶段提交，使各分数据库在接收到二阶段提交的不同指令时，生成不同类型的事务变更日志。其中，二阶段提交对应的事务变更日志包括二阶段预提交日志、二阶段提交日志、二阶段回滚日志。

在本实施例中，在二阶段提交日志中添加事务提交时间戳，其中，事务提交时间戳可以理解为事务最终提交的时间。不同的日志缓冲区中包含不同分数据库产生的事务变更日志。事务一致性管理系统会反复对日志缓冲区中涉及的数据进行批量合并，然后生成目标增量数据。

在本实施例中，事务一致性管理系统可以针对每个日志缓冲区确定出增量数据，再将各缓冲区涉及的增量数据进行合并，确定为目标增量数据。为了保证确定出的目标增量数据是完整的，需要保证解析出的事务执行涉及的各分数据库的事务变更日志是完整的。因此，本实施例中需要确定出一个时间节点，在该时间节点之前可以保证事务的完整的，也就是各分数据库中的对应该事务的事务变更日志已均被应用。

为了确定出该时间节点，可以针对每个日志缓冲区，按顺序依次获取日志缓冲区中的事务变更日志，根据事务变更日志的类型，确定该日志缓冲区对应的时间节点。可以理解的是，对于一阶段提交日志，不涉及事务提交时间戳，所以一阶段提交日志对时间节点无影响，可忽略。对二阶段提交产生的各类型日志中，二阶段提交日志表征事务最终提交，且二阶段提交日志中包含事务提交时间戳，因此，可以根据获取的二阶段提交日志确定各日志缓冲区的时间节点。

进一步，当确定出各日志缓冲区中的时间节点后，可以从各时间节点中选出能够表征在时间点前，各分数据库涉及的事务变更日志为完整的事务的时间节点。基于该时间节点，可以确定出该时间节点前的事务变更日志确定的增量数据包含事务涉及各分数据库的增量数据，从而可以保证事务一致性。可以理解的是，随着分数据库中不断生成事务变更日志，事务变更日志不断缓存至日志缓冲区中，确定的时间节点是会变化的，进一步使日志缓冲区中的事务变更日志被不断解析，确定出目标增量数据。

当确定出目标增量数据后，可以将目标增量数据同步至分析处理系统、。随着事务的执行，会不断确定出新的目标增量数据，并将目标增量数据同步至分析处理系统中。分析处理系统中采用了一种常用的存储方式：增量存储。原始版本的数据存储在基础文件中，每一次事务一致性管理系统进行一次批量合并后，都会生成一个新的版本存储在一个增量文件里。分析处理系统在处理用户的分析类请求时，先读取每一个基础文件和增量文件的所有内容。然后根据用户的查询请求生成的过滤条件对结果进行过滤，过滤不满足过滤条件的数据，生成用户需要的结果。

本发明实施例所提供的事务一致性管理方法可由本发明任意实施例所提供的事务一致性管理引擎执行，具备执行方法相应的功能模块和有益效果。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。