基于日志解析同步的保障数据一致性的方法和同步系统

技术领域

本发明属于同步技术领域，更具体地，涉及一种基于日志解析同步的保障数据一致性的方法和同步系统。

背景技术

数据库数据实时同步是提高信息系统可用性，保证业务连续性的一种技术方案。通过数据实时同步，目标数据库和源数据库的业务数据保持实时一致，当源数据库出现故障中断服务后，应用系统可快速切换至目标数据库，保证业务连续性的要求。

基于日志分析的数据库数据实时复制技术，具有对源数据库的性能和数据模式影响小、支持异构操作系统和数据库平台、数据复制性能高等特点，在应急灾备、多业务中心、异构资源整合、数据迁移等领域得到广泛应用。这种技术通过源端的日志捕获进程捕获源数据库的在线日志或归档日志，然后分析出数据库的INSERT(插入)、UPDATE(更新)以及DELETE(删除)操作转换为内部特定格式的消息包，再将消息包通过TCP/IP(TransmissionControl Protocol/Internet Protocol，简写为TCP/IP)网络发送到复制系统的目的端，目的端接收消息包后，进行拆包处理，将源端的事务信息恢复成相应的SQL(StructuredQuery Language，简写为SQL)语句，通过本地数据库接口在目标数据库执行实时复制，以实现数据库数据同步。

为保证源数据库和目标数据库的数据一致性，基于日志分析的数据库数据复制技术通常以源数据库的事务为最小复制单位，严格按照源数据库事务顺序进行实时数据复制，保障目标数据库与源数据库的事务的完整性和一致性，确保目标数据库符合源数据库的事务逻辑。因此，在基于日志分析的数据库数据复制技术中，其技术关键在于如何保障源数据库和目标数据库的事务一致性，特别是在复制系统出现故障后，目标数据库能够按照事务完整性及一致性的要求进行正确的恢复。

目前，为了保证目标数据库与源数据库的复制事务的完整性及一致性，一般采用的方法如下：在目标数据库中创建一个提交事务表记录已完成同步的事务信息。复制系统出现故障进行恢复时，续传的待执行事务需要使用提交事务表中记录的事务信息来过滤掉故障前已经完成同步的事务，避免事务的重复执行，以此保障故障恢复后的事务一致性。

但是，上述基于提交事务表登记已同步事务的方案需要登记已同步的所有事务信息，这种方式在特定的应用场景下会拖慢同步的性能，例如存在大量小事务的同步场景(小事务指的是单个事务中操作的数量非常少，每个事务可能只有一两个操作)，在这种场景下每同步一个事务，事务提交表中就会记录一条事务信息，大量的小事务在同步时就会向提交事务表插入大量的事务信息，并且事务提交表中大量的事务信息在同步过程中还需要通过检查点的方式来清除，集中式的访问提交事务表就会造成数据库产生热点形成性能瓶颈，从而影响数据同步性能。

鉴于此，克服该现有技术产品所存在的不足是本技术领域亟待解决的问题。

发明内容

针对现有技术的以上缺陷或改进需求，本发明提供了一种基于日志解析同步的保障数据一致性的方法和同步系统，其目的在于，基于按表标识和事务的提交日志序列号来组织提交事务表中的信息，在数据同步运行过程中，每个表在提交事务表中只登记一行信息，这就大大缩减了提交事务表中的数据规模，可以有效的减少对提交事务表的访问次数，防止产生访问热点。

为实现上述目的，按照本发明的一个方面，提供了一种基于日志解析同步的保障数据一致性的方法，所述方法包括：

将提交事务表中的表标识和相应的日志序列号加载至过滤容器中，其中，所述提交事务表以表标识为主键，以日志序列号为附加列；

获取DML操作所属的事务标识和所述DML操作所涉及的表标识，以所述事务标识和所述表标识为组合键，对所述DML操作进行分类管理，以将一个事务分割为至少一个子事务；

获取提交操作的提交事务标识和提交日志序列号；

在经过分类管理的子事务中，获取事务标识与提交事务标识相同的目标子事务，依次提取所述目标子事务的表标识；

基于所述提交日志序列号、所述目标子事务的表标识和所述过滤容器对所述目标子事务进行过滤，以保障数据同步的一致性。

优选地，目的端数据同步系统中设置有一条待执行事务链表，所述待执行事务链表用于存放待执行入库的事务；

基于所述提交日志序列号、所述目标子事务的表标识和所述过滤容器对所述目标子事务进行过滤，以保障数据同步的一致性包括：

判断所述目标子事务的表标识是否存在于所述过滤容器中；

若存在于所述过滤容器中，则获取所述目标子事务的表标识相对应的过滤日志序列号；

判断所述提交日志序列号是否大于所述过滤日志序列号；

若大于，则将所述目标子事务添加到所述待执行事务链表中；

若不大于，则丢弃所述目标子事务。

优选地，基于所述提交日志序列号、所述目标子事务的表标识和所述过滤容器对所述目标子事务进行过滤，以保障数据同步的一致性包括还包括：

若不存在于所述过滤容器中，则在所述提交事务表中登记所述目标子事务的表标识，并设置相应的日志序列号为0；

将所述目标子事务的表标识和日志序列号0加载到所述过滤容器中。

优选地，目的端数据同步系统中设置有一条待合并事务链表，所述待合并事务链表用于存放需要合并的事务；

所述方法还包括：

从所述待执行事务链表中取出一个待合并子事务，将所述待合并子事务添加到待合并事务链表；

根据所述待合并子事务的表标识，在所述待执行链表中取出表标识相同的待合并子事务，以得到多个待合并子事务，

按照所述待合并子事务对应的提交顺序，从先到后将所述待合并子事务添加到所述待合并事务链表中；

合并除了提交操作以外的所有操作；

对所述事务提交表完成更新后，再提交所述待合并事务链表中的事务。

优选地，所述对所述事务提交表完成更新后，再提交所述待合并事务链表中的事务包括：

获取所述待合并事务链表中最后一个待合并子事务的提交日志序列号；

以所述待合并子事务的表标识为主键，将所述提交事务表中的相应附加列的日志序列号更新为最后一个待合并子事务的提交日志序列号；

执行提交操作。

优选地，所述方法还包括：

在进行故障恢复时，通过更新后的事务提交表加载所述过滤容器，以更新所述过滤日志序列号。

优选地，所述方法还包括：

将所述待合并子事务添加到所述待合并事务链表后，将所述待合并子事务从所述待执行事务链表中删除。

优选地，所述将提交事务表中的表标识和相应的日志序列号加载至过滤容器中之前包括：

目的端数据同步系统判断在目的端数据库中是否存在提交事务表；

若存在提交事务表，则执行将提交事务表中的表标识和相应的日志序列号加载至过滤容器中的步骤；

若不存在，则以表标识为主键，以日志序列号为附加列创建提交事务表。

优选地，所述将提交事务表中的表标识和相应的日志序列号加载至过滤容器中之后包括：

接收来自与源端的日志记录，对所述日志记录进行解析得到相应的操作；

判断操作的类型；

若为DML操作，则执行所述获取DML操作所属的事务标识和所述DML操作所涉及的表标识，以所述事务标识和所述表标识为组合键，对所述DML操作进行分类管理，以将一个事务分割为至少一个子事务的步骤；

若为提交操作，则执行所述获取提交操作的提交事务标识和提交日志序列号的步骤。

为实现上述目的，按照本发明的另一个方面，提供了一种同步系统，所述同步系统包括至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被程序设置为执行本发明所述的保障事务一致性的方法。

总体而言，通过本发明所构思的以上技术方案与现有技术相比，具有如下有益效果：本发明提供一种基于日志解析同步的保障数据一致性的方法和同步系统，所述方法包括：将提交事务表中的表标识和相应的日志序列号加载至过滤容器中，其中，所述提交事务表以表标识为主键，以日志序列号为附加列；获取DML操作所属的事务标识和所述DML操作所涉及的表标识，以所述事务标识和所述表标识为组合键，对所述DML操作进行分类管理，以将一个事务分割为至少一个子事务；获取提交操作的提交事务标识和提交日志序列号；在经过分类管理的子事务中，获取事务标识与提交事务标识相同的目标子事务，依次提取所述目标子事务的表标识；基于所述提交日志序列号、所述目标子事务的表标识和所述过滤容器对所述目标子事务进行过滤，以保障数据同步的一致性。本发明中，基于按表标识和事务的提交日志序列号来组织提交事务表中的信息，在数据同步运行过程中，每个表在提交事务表中只登记一行信息，这就大大缩减了提交事务表中的数据规模，可以有效的减少对提交事务表的访问次数，防止产生访问热点。

附图说明

图1是本发明实施例提供的一种基于日志解析同步的保障数据一致性的方法的流程示意图；

图2是本发明实施例提供的图1中步骤105的流程示意图；

图3是本发明实施例提供的一种同步系统的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

在本发明的描述中，术语“内”、“外”、“纵向”、“横向”、“上”、“下”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作，因此不应当理解为对本发明的限制。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

实施例1：

提交事务表用来登记事务信息，主要是为了防止数据同步发生故障(同步程序异常、数据库服务异常、操作系统异常或硬件故障)恢复后出现同步数据不一致的情况，例如，当同步服务在目的端数据库执行完事务提交时，提交命令成功发送给数据库服务但是还没有接收到数据库服务返回执行结果的情况下同步服务异常崩溃，由于同步服务和数据库是两个独立的个体，虽然同步服务异常了，但是数据库可能还是会成功的提交同步服务发送的提交命令，这种情况下，同步服务恢复后无法直接从数据库中获取上次故障前发送的提交命令执行的成功与否，只能通过事务信息查询提交事务表中是否登记了上次执行的事务信息来判断上次的提交是否成功。

目前，同步服务是按事务为单位来组织提交事务表中的记录，但这种方式并不适用所有的应用场景，在存在大规模小事务的同步场景下就会造成提交事务表的访问热点。

为解决前述问题，本实施例提供了一种基于日志解析同步的保障数据一致性的方法，参阅图1，所述方法包括如下步骤：

步骤101：将提交事务表中的表标识和相应的日志序列号加载至过滤容器中，其中，所述提交事务表以表标识为主键，以日志序列号为附加列。

其中，表标识指的是某一个表的ID。

其中，每个表标识对应的日志序列号作为过滤日志序列号，对涉及该表标识的事务进行过滤，以判断该事务是否在故障前已经同步过。

其中，日志序列号为提交操作对应的日志序列号。在实际使用中，一个事务中包括多个DML操作(例如，插入操作、删除操作和更新操作)，每个操作所涉及的表可能不同，每一事务对应一个提交操作，采用该提交操作对应的提交日志序列号更新附加列的日志序列号。

在实际应用场景下，目的端数据同步系统判断在目的端数据库中是否存在提交事务表；若存在提交事务表，则执行步骤101；若不存在，则以表标识为主键，以日志序列号为附加列创建提交事务表。

其中，建表语句为：CREATE TABLE TX(TABLE_ID INT PRIMARYKEY,LSN NUMBER)。

步骤102：获取DML操作所属的事务标识和所述DML操作所涉及的表标识，以所述事务标识和所述表标识为组合键，对所述DML操作进行分类管理，以将一个事务分割为至少一个子事务。

在本实施例中，在源端数据库及目的端数据库部署同步系统，源端数据同步系统从源端数据库读取日志，而目的端数据同步系统则是负责把源端发过来的同步操作应用到目的端数据库。

目的端数据同步系统接收来自于源端的日志记录，对所述日志记录进行解析得到相应的操作，判断操作的类型，若为DML操作，则获取DML操作所属的事务标识和所述DML操作所涉及的表标识，以所述事务标识和所述表标识为组合键，对所述DML操作进行分类管理，以将一个事务分割为至少一个子事务。

例如，事务A(事务标识为ID1)包括操作1、操作2、操作3、操作4和操作5，其中，操作1和操作2所涉及的表标识为id1，操作3和操作4所涉及的表标识为id2，操作5所涉及的表标识为id3，则操作1和操作2的组合键(ID1，id1)相同，操作1和操作2被划分到一个子事务B中，操作3和操作4的组合键(ID1，id2)相同，操作3和操作4被划分到另一个子事务C中，操作5的组合键(ID1，id3)，操作5被划分到又一个子事务D中。

若为提交操作，则获取提交操作的提交事务标识和提交日志序列号。

步骤103：获取提交操作的提交事务标识和提交日志序列号。

步骤104：在经过分类管理的子事务中，获取事务标识与提交事务标识相同的目标子事务，依次提取所述目标子事务的表标识。

例如，提交操作的提交事务标识为ID1，说明在源端事务A被提交。则在经过分类管理的子事务中，根据子事务的组合键获取事务标识与提交事务标识ID1相同的目标子事务，则获取到子事务B、子事务C和子事务D，依次提取所述目标子事务的表标识，得到表标识id1、id2和id3。

步骤105：基于所述提交日志序列号、所述目标子事务的表标识和所述过滤容器对所述目标子事务进行过滤，以保障数据同步的一致性。

具体地，在通过所述过滤容器进行过滤时，根据目标子事务的表标识确定过滤日志序列号，将提交日志序列号与过滤日志序列号进行对比，以确定目标子事务是否在故障前已经同步过，若同步过，则丢弃该目标子事务，若没有同步过，则根据目标子事务的提交日志序列号对应在提交事务表和过滤容器中更新相应的过滤日志序列号，然后执行目标子事务的同步操作。

本发明中，基于按表标识和事务的提交日志序列号来组织提交事务表中的信息，在数据同步运行过程中，每个表在提交事务表中只登记一行信息，这就大大缩减了提交事务表中的数据规模；并且在执行事务操作时，按表来分类各个事务中的操作，将一个大事务分割为至少一个小事务(子事务)，把多个小事务中相同表的操作合并成一个事务执行，N个小事务合并成一个大事务执行以后可以有效的减少对提交事务表的访问次数，防止产生访问热点。

此外，表与表之间的操作并行入库时，每个表的事务信息采用更新的方式来维护提交事务表中不同的行，也能有效的防止入库线程之间的冲突。

在实际应用场景下，为了提高同步的效率，也为了避免提交事务表被频繁访问，在优选的实施例中，将针对相同表的不同子事务进行合并之后，再执行同步操作，具体的实现过程如下：

目的端数据同步系统中设置有一条待执行事务链表，所述待执行事务链表用于存放待执行入库的事务，目的端数据同步系统中设置有一条待合并事务链表，所述待合并事务链表用于存放需要合并的事务。其中，在待执行事务链表和待合并事务链表中，事务顺序都按事务的提交先后顺序存放(也就是按照提交操作LSN的大小顺序)。

结合图2，在步骤105中，具体包括如下步骤：

步骤1051：判断所述目标子事务的表标识是否存在于所述过滤容器中。

若存在于所述过滤容器中，则执行步骤1052；若不存在于所述过滤容器中，则执行步骤1056。

步骤1052：若存在于所述过滤容器中，则获取所述目标子事务的表标识相对应的过滤日志序列号。

步骤1053：判断所述提交日志序列号是否大于所述过滤日志序列号。

若大于，执行步骤1054；若不大于，执行步骤1055。

步骤1054：若大于，则将所述目标子事务添加到所述待执行事务链表中。

在本实施例中，由于采取了事务ID和表ID的组合键来管理事务，源端数据库中涉及多个表操作的事务在这里就会被打散成多个小事务，当接收到该事务提交操作时就需要找出所有被打散的小事务，把这些小事务都添加到待执行事务链表中去等待执行。

步骤1055：若不大于，则丢弃所述目标子事务。

步骤1056：若不存在于所述过滤容器中，则在所述提交事务表中登记所述目标子事务的表标识，并设置相应的日志序列号为0，将所述目标子事务的表标识和日志序列号0加载到所述过滤容器中。

在本实施例中，在把小事务添加到待执行事务链表之前，就需要通过事务的提交LSN和对应的过滤容器中的LSN进行对比，如果事务对应的表ID在容器中找不到，则说明这个表没有同步过，除了需要在过滤容器中补充登记以外，还需要在提交事务表中插入一行该表的信息，LSN列的值设置为0。由于日志中的提交LSN是递增的，所以当前事务提交LSN大于过滤LSN时，说明该事务是新事务，需要执行。

步骤1057：从所述待执行事务链表中取出一个待合并子事务，将所述待合并子事务添加到待合并事务链表。

步骤1058：根据所述待合并子事务的表标识，在所述待执行链表中取出表标识相同的待合并子事务，以得到多个待合并子事务。

在本实施例中，将所述待合并子事务添加到所述待合并事务链表后，将所述待合并子事务从所述待执行事务链表中删除。

负责事务入库的执行线程先从待执行事务链表中提取一个待合并子事务添加到待合并事务链表，然后根据该事务的表ID在待执行事务链表中选择表ID相同的事务并把这些事务也添加进待合并事务链表，而且选中的事务要从待执行事务链表中移出，这样下次再选择合并事务时上次未能合并的事务就可以继续这个动作。

在本实施例中，在选择合并的事务个数时，可以根据设定的合并事务的规模值来决定，假如设定合并以后的操作个数为N，那么在选择事务时就可以统计合并事务的操作数，当操作数达到或超过N时，停止选择。N设置得过小时会影响操作合并的效果，而设置得过大则会影响执行线程之间的并行度，需要根据同步环境来决定N值。

步骤1059：按照所述待合并子事务对应的提交顺序，从先到后将所述待合并子事务添加到所述待合并事务链表中。

步骤1060：合并除了提交操作以外的所有操作。

执行线程在选择出合并的事务以后，执行合并除了提交操作以外的所有操作。

步骤1061：对所述事务提交表完成更新后，再提交所述待合并事务链表中的事务。

具体地，获取所述待合并事务链表中最后一个待合并子事务的提交日志序列号；以所述待合并子事务的表标识为主键，将所述提交事务表中的相应附加列的日志序列号更新为最后一个待合并子事务的提交日志序列号；执行提交操作，完成相应事务的同步。

上述方案待合并链表中的事务的排序是按每个事务的提交LSN大小排的，最后一个事务的提交LSN最大，所以使用该LSN来更新提交事务表，就可以明确的表明对应的表在同步时，所有小于等于该LSN的事务都已经完成了同步，在故障恢复时就可以使用该LSN来过滤对应表上的同步事务。

另外，待合并链表中N个事务信息统一使用最后一个事务信息登记到提交事务表中，可以有效减轻提交事务表的访问压力，缩减提交事务表中的记录规模。采用该优化方案，提交事务表记录数的规模只跟同步表的个数相关，从而跟整个同步过程中同步的事务数量无关，表的数据量在同步一段时间以后就会恒定下来。

在实际使用中，在进行故障恢复时，通过更新后的事务提交表加载所述过滤容器，以更新所述过滤日志序列号，从而对事务进行过滤，保障数据同步的一致性。

在本实施例中，通过按照表ID来打散存在多个表操作的事务，然后按表ID来选择相同表ID的事务进行合并，N个小事务合并成一个大事务执行，在执行完成后，更新提交事务表中的事务信息后再执行提交操作。当同步故障恢复时，每个表根据提交事务表中相应的信息来识别已同步的事务，保证恢复时数据的一致性。

上述实施例的基本步骤，可以解释如下：

首先，数据库的日志流中LSN有连续递增的特性，在事务按表ID来分类以后，把大事务分割为至少一个小事务，然后将经过过滤容器的小事务添加到待执行事务链表中，在进行同步时，把N个相同表ID的小事务合成一个大事务来执行，那么在登记提交事务表时采用最后一个事务的提交LSN就可以当作界限来很明确的区分开已经同步和未同步的事务。

其次，采用更新(UPDATE)的方式来操作提交事务表，相对于现有采取插入(INSERT)的方式更有性能上的优势。因为在同步过程中，事务数量是一直会增长的，插入的方式来登记已同步的事务会造成提交事务表不断的彭胀，所以必需定期做检查点来清空提交事务表以便维护它的数据规模。此外，频繁的插入和删除对数据库的IO都会造成一定影响。而采用本方案更新的方式，在运行稳定以后提交事务表中的数据规模将会稳定下来(表的种类基本上可以趋于恒定)，同步事务提交时只需要在这些固定的行中做更新，代价要比使用插入的方案小得多，间接的提升了同步的性能。

实施例2：

为了便于理解前述实施例的方案，下面进行举例说明。

上述方案举例如下：源数据库和目的端数据库现都有表T1(IDVARCHAR)，源端应用有三个事务对表T1进行如下操作：

TRX1:INSERT INTO T1(ID)VALUES('TRX1_T1_1')；

TRX2:INSERT INTO T1(ID)VALUES('TRX2_T1_10')；

TRX3:INSERT INTO T1(ID)VALUES('TRX3_T1_30')；

TRX1:COMMIT；

TRX2:COMMIT；

TRX3:COMMIT；

上述操作的顺序在日志接收线程在接收到后会形成下面编号表格中的情况：

事务同步恢复过程如下：

目的端同步系统启动，开始接收日志前，判断在目的端数据库上是否存在提交事务表，首次接收时提交事务表不存在，故创建提交事务表：

CREATE TABLE TX(TABLE_ID INT PRIMARY KEY,LSN NUMBER)

创建完成以后从提交事务表中构造过滤容器，当前是个空的容器。

然后，开始接收源端操作，依次接收到三个事务中针对T1表的INSERT操作，把该操作使用事务ID和表ID来分类管理。

接收到事务TRX1的提交操作(LSN＝4)，假设T1表的ID为1，从容器中获取表ID为1的过滤LSN，由于是空容器，获取不到，所使用表ID作为KEY，过滤LSN为0插入到容器中，并且在提交事务表中登记该表的过滤LSN，执行：

INSERT INTO TX(TABLE_ID,LSN)VALUES(1,0)；

上述操完成以后，找到TRX1的事务，把它添加到待执行事务链表。

接收到事务TRX2的提交操作(LSN＝5)，从过滤容器中取出表T1的过滤LSN(LSN＝0)，比对LSN，由于提交操作LSN大于过滤LSN，找到TRX2的事务，把它添加到待执行事务链表。

接收到事务TRX3的提交操作(LSN＝6)，从过滤容器中取出表T1的过滤LSN(LSN＝0)，比对LSN，由于提交操作LSN大于过滤LSN，找到TRX3的事务，把它添加到待执行事务链表。

数据入库时，从待执行事务链表中选择合并的事务，假设就选择TRX1和TRX2两个事务进行合并执行，在执行完成以后，使用最后一个事务TRX2的提交LSN(LSN＝5)来更新提交事务表中T1表的过滤LSN，执行：

UPDATE TX SET LSN＝5WHERE TABLE_ID＝1；

执行提交，假设在这提交完成以后程序故障。

下一步重启同步系统来恢复数据同步。

目的端同步系统启动，开始接收前判断提交事务表是否存在，提交事务表存在，加载提交事务表中的数据来构造过滤容器，当前是容器中T1表的过滤LSN为5。

开始接收源端操作，重新依次接收到三个事务中针对T1表的INSERT操作，把该操作使用事务ID和表ID来分类管理。

接收到事务TRX1的提交操作(LSN＝4)，从过滤容器中获取表T1的过滤LSN(LSN＝5)，比对LSN，由于提交操作LSN小于过滤LSN，找到TRX1的事务，把它直接释放掉，不用执行，因故障前它已经执行过了；

接收到事务TRX2的提交操作(LSN＝5)，从过滤容器中取出表T1的过滤LSN(LSN＝5)，比对LSN，由于提交操作LSN等于过滤LSN，找到TRX2的事务，把它直接释放掉，不用执行，因故障前它已经执行过了。

接收到事务TRX3的提交操作(LSN＝6)，从过滤容器中取出表T1的过滤LSN(LSN＝5)，比对LSN，由于提交操作LSN大于过滤LSN，找到TRX3的事务，把它添加到待执行事务链表。

数据入库时，从待执行队列中选择合并的事务，这时待执行事务链表中只有TRX3事务，在执行完成以后，使用事务TRX3的提交LSN(LSN＝6)来更新提交事务表中T1表的过滤LSN，执行：

UPDATE TX SET LSN＝6WHERE TABLE_ID＝1；

执行提交。

从前述过程可以看出，在故障恢复时，源端会有一部分重复的操作发送到目的端，这里就需要依赖提交事务表中登记的已完成同步的事务信息来过滤这些已经同步的事务，本方案采用按表为单位，把N个事务的事务信息合并成一行来减轻对提交事务表的访问压力，防止数据库在提交事务表上生成热点，提升了同步性能。

实施例3：

请参阅图3，图3是本发明实施例提供的一种同步系统的结构示意图。本实施例的同步系统包括一个或多个处理器31以及存储器32。其中，图3中以一个处理器31为例。

处理器31和存储器32可以通过总线或者其他方式连接，图3中以通过总线连接为例。

存储器32作为一种基于保障事务一致性的方法的非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，上述实施例的方法以及对应的程序指令。处理器31通过运行存储在存储器32中的非易失性软件程序、指令以及模块，从而执行各种功能应用以及数据处理，实现前述实施例的方法。

其中，存储器32可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器32可选包括相对于处理器31远程设置的存储器，这些远程存储器可以通过网络连接至处理器31。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

值得说明的是，上述装置和系统内的模块、单元之间的信息交互、执行过程等内容，由于与本发明的处理方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(Read Only Memory，简写为ROM)、随机存取存储器(RandomAccessMemory，简写为RAM)、磁盘或光盘等。

本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。