基于日志解析同步的操作合并执行方法和数据同步系统
技术领域
本发明属于数据同步技术领域,更具体地,涉及一种基于日志解析同步的操作合并执行方法和数据同步系统。
背景技术
传统的基于数据库自身的主备机制实现数据库数据的实时复制,是进行数据容灾备份,保障数据安全的重要的解决方案。目前,例如ORACLE公司的DataGuard和达梦数据库的DM7主备产品都是实现这种解决方案的成熟的商业化产品。数据库主备机制下,一般备机作为备份节点,通常只提供只读访问,可以在备机上做一些报表分析、数据挖掘等只读访问的应用,而不能像主机一样提供读写访问。另外,数据库主备机制要求备机数据库系统和主机一致,对于异构数据库系统环境,则不能利用数据库自身的主备机制实现有效的数据实时复制。
针对数据库主备机制实现数据复制的不足,目前基于软件的异构数据库复制技术应用广泛。这种技术在源端捕获出数据库的增量数据,然后发送到目的端,在目的端通过通用的数据库访问接口,将增量数据应用到目的端数据库,实现数据复制。这种技术因为使用到通用数据库接口,因此支持异构数据库系统复制,支持异构操作系统环境,并且目的端备机数据库系统可读写,是一种“双活”系统。
有多种技术方式实现获取源端数据库的增量数据,其中基于数据库日志捕获分析的数据实时同步技术,因其对源数据库侵入性小,捕获分析性能高,得到较大发展及研究。这种技术通过分析源数据库归档或联机日志,捕获出数据库的INSERT、UPDATE、DELETE操作日志,然后发送到目的端,目的端对日志信息进行逆向生成,恢复成SQL语句方式,然后使用数据库通用接口,应用到目的端数据库,实现数据复制。因此,在数据库实时复制过程中,目的端的执行效率是影响数据同步性能的重要因素。
源端数据库上并发执行的各个事务中可能存在大量批量执行的操作,数据库系统都会根据并发控制机制去执行,把相冲突的事务操作互斥执行,并且在日志文件中顺序的记录下各个事务的操作日志,数据同步时应该尽可能还原出源端的批量操作以提升同步性能。如果目的端数据复制软件严格按照源端日志流中的事务提交顺序进行串行执行,对事务中相同的操作合并后批量执行则能够保证数据复制的一致性,但是串行执行效率将会非常低,所以在目的端同步执行事务时往往会采取多线程并行执行的策略。在并行执行的环境下,单个事务在执行时同样需要采用相同操作合并后,批量执行的方式来提升同步性能,然而并行执行则需要考虑到正在执行的事务之间是否存在数据关联性的问题,事务在执行时不能无规则的合并相同的操作。因此,在如何保证数据复制一致性的前提下来合并事务内的操作,提高目的端数据复制的并行执行效率,就成为业界亟待解决的重要技术问题。
鉴于此,克服该现有技术产品所存在的不足是本技术领域亟待解决的问题。
发明内容
针对现有技术的以上缺陷或改进需求,本发明提供了一种基于日志解析同步的操作合并执行方法和数据同步系统,其目的在于,在本发明中,数据库的日志流中记录的操作先后顺序可以直接反映出各个事务的操作在数据库内部执行的先后顺序,而以日志流中的提交操作作为分界线则反映出各个事务操作在数据内部执行的并行度,最大限度的合并操作可以有效的提升同步的性能。
为实现上述目的,按照本发明的一个方面,提供了一种基于日志解析同步的操作合并执行方法,所述操作合并执行方法包括:
日志接收线程在接收到提交操作后,按照顺序为所述提交操作设置提交编号,并将所述提交操作所属的待执行事务分发至相对应的事务执行线程;
日志接收线程在接收到DML操作后,获取发生于所述DML操作之前,且最接近于所述DML操作的提交操作的目标提交编号,采用所述目标提交编号标记所述DML操作;
所述事务执行线程从待执行事务中取出当前待执行操作;
根据所述当前待执行操作所携带的目标提交编号,确定所述当前待执行操作与其他待执行事务的相容性,进而确定是否可以进行操作合并。
优选地,每一所述事务执行线程配套有一待执行操作链表;
所述根据所述当前待执行操作所携带的目标提交编号,确定所述当前待执行操作与其他待执行事务的相容性,进而确定是否可以进行操作合并之前还包括:
判断所述当前待执行操作的操作类型与所述待执行操作链表中已有的操作的操作类型是否相同;
若操作类型相同,则执行所述根据所述当前待执行操作所携带的目标提交编号,确定所述当前待执行操作与其他待执行事务的相容性,进而确定是否可以进行操作合并的步骤;
若操作类型不相同,则执行并清空所述待执行操作链表中已有的操作。
优选地,所述根据所述当前待执行操作所携带的目标提交编号,确定所述当前待执行操作与其他待执行事务的相容性,进而确定是否可以进行操作合并包括:
判断所述当前待执行操作所携带的目标提交编号与所述待执行操作链表中最后一个操作所携带的目标提交编号是否相同;
若提交编号相同,则将所述当前待执行操作添加在所述待执行操作链表的尾部。
优选地,所述判断所述当前待执行操作所携带的目标提交编号与所述待执行操作链表中最后一个操作所携带的目标提交编号是否相同之后还包括:
若提交编号不相同,则依次提取两个目标提交编号中的冲突事务;
判断在所述冲突事务中是否存在与所述当前待执行操作相关联的关联对象;
若存在关联对象,则判断所述冲突事务对所述关联对象所进行的操作,与所述当前待执行操作是否相容,以确定是否可以进行操作合并;
若不存在关联对象,则将所述当前待执行操作添加在所述待执行操作链表的尾部。
优选地,所述判断所述冲突事务对所述关联对象所进行的操作,与所述当前待执行操作是否相容包括:
若所述冲突事务和所述当前待执行操作对所述关联对象均进行插入操作或删除操作,则所述冲突事务和所述当前待执行操作相容;
将所述当前待执行操作添加在所述待执行操作链表的尾部。
优选地,所述判断所述冲突事务对所述关联对象所进行的操作,与所述当前待执行操作是否相容包括:
若所述冲突事务和所述当前待执行操作对所述关联对象均进行更新操作,或,所述冲突事务对所述关联对象进行的操作的操作类型与所述当前待执行操作的操作类型不同,则所述冲突事务和所述当前待执行操作不相容;
以批量执行的方式清空所述待执行操作链表中已有的操作;
等待所述冲突事务提交后,将所述当前待执行操作添加在所述待执行操作链表的尾部。
优选地,所述将所述当前待执行操作添加在所述待执行操作链表的尾部之后还包括:
判断所述待执行操作链表中已有的操作的数目是否已经达到设定值;
若达到设定值,则将所述待执行操作链表中已有的操作批量入库,以清空所述待执行操作链表。
优选地,所述操作合并执行方法还包括:
所述日志接收线程对所述DML操作进行解析,得到所述DML操作所涉及的对象信息、所述DML操作的操作类型以及所述DML操作所属的事务标识号;
依据所述DML操作所属的事务标识号将所述DML操作归类至相应的事务中;
将所述DML操作所涉及的对象信息和所述DML操作的操作类型添加到对应的事务中。
优选地,所述事务执行线程从待执行事务中取出当前待执行操作之后还包括:
判断所述当前待执行操作的操作类型;
若所述当前待执行操作为DML操作,则执行所述根据所述当前待执行操作所携带的目标提交编号,确定所述当前待执行操作与其他待执行事务的相容性,进而确定是否可以进行操作合并的步骤;
若所述当前待执行操作为DML操作,则清空待执行操作链表中的操作,并完成事务提交。
为实现上述目的,按照本发明的另一个方面,提供了一种数据同步系统,所述数据同步系统包括至少一个处理器;以及,与所述至少一个处理器通信连接的存储器;其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被程序设置为执行本发明所述的操作合并执行方法。
总体而言,通过本发明所构思的以上技术方案与现有技术相比,具有如下有益效果:本发明提供一种基于日志解析同步的操作合并执行方法和数据同步系统,所述操作合并执行方法包括:日志接收线程在接收到提交操作后,按照顺序为所述提交操作设置提交编号,并将所述提交操作所属的待执行事务分发至相对应的事务执行线程;日志接收线程在接收到DML操作后,获取发生于所述DML操作之前,且最接近于所述DML操作的提交操作的目标提交编号,采用所述目标提交编号标记所述DML操作;所述事务执行线程从待执行事务中取出当前待执行操作;根据所述当前待执行操作所携带的目标提交编号,确定所述当前待执行操作与其他待执行事务的相容性,进而确定是否可以进行操作合并。
在本发明中,数据库的日志流中记录的操作先后顺序可以直接反映出各个事务的操作在数据库内部执行的先后顺序,而以日志流中的提交操作作为分界线则反映出各个事务操作在数据内部执行的并行度。在本发明中,通过判断单个事务中两个操作之间是否存在其它事务的提交操作为条件来合并操作,并且在夹杂有提交操作时,通过判断操作和提交操作对应的事务和操作相容性等策略来尽可能的合并操作,最大限度的合并操作可以有效的提升同步的性能。
附图说明
图1是本发明实施例提供的一种基于日志解析同步的操作合并执行方法的流程示意图;
图2是本发明实施例提供的图1中步骤104的流程示意图;
图3是本发明实施例提供的另一种基于日志解析同步的操作合并执行方法的流程示意图;
图4是本发明实施例提供的一种数据同步系统的结构示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
在本发明的描述中,术语“内”、“外”、“纵向”、“横向”、“上”、“下”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系,仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作,因此不应当理解为对本发明的限制。
此外,下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
实施例1:
在数据同步中,在源端数据库及目的端数据库部署同步系统,源端数据同步系统从源端数据库读取日志,而目的端数据同步系统则是负责把源端发过来的同步操作应用到目的端数据库。
数据同步在目的端数据库同步事务时,应该本着尽量减少和数据库交互的次数来执行同步操作,因为每次和数据库交互都会带来额外的开销,批量执行一千行插入操作所花费的时间远比执行一千次每次只插入一行花费的时间少,因此操作合并是数据同步中一项非常重要的技术。
数据库日志在把数据库中的操作写入日志时采用的是串行方式,也就是说,数据库内部并行执行的事务操作产生的日志,会交替的写入到日志文件中,鉴于上述原因,假如只有一个活动事务对某个表做批量的UPDATE操作,那么数据库日志中将会连续的记录这个表的UPDATE日志;假如有两个活动事务分别针对同一个表做UPDATE操作,那么数据库日志中将会交替的记录这个表上两个事务的UPDATE日志。数据同步在目的端数据库同步这两个事务时,如果采取并行执行的策略来并行同步这两个事务,那就需要制定出一套单个事务内部操作合并的策略,由于这两个事务更新的是同一张表,那么就很有可能这两个事务更新的行存在冲突,源数据库在运行时,如果事务之间存在冲突,那么针对冲突行后发起执行的事务就会被阻塞,只有等到先发起的事务提交完成以后才能继续执行。在上述例子中,两个事务都是UPDATE操作,所以单个事务内都是相同的操作,如果两个事务执行时都采用合并批量一次执行的方式,那么就无法保证这两个事务操作的执行先后顺序和源数据库保持一致,会导致存在冲突的行本该后执行的事务,却先执行的后果,最终导致同步数据的不一致。本发明针对这种现像,通过判断单个事务中两个操作之间是否存在其它事务的提交操作为条件来合并操作,并且在夹杂有提交操作时通过判断操作和提交操作对应的事务中涉及的表和操作相容性等策略来尽可能的合并操作,最大限度的合并操作可以有效的提升同步的性能。
下面参阅图1,具体说明本实施例的基于日志解析同步的操作合并执行方法的实现过程,所述操作合并执行方法包括如下步骤:
步骤101:日志接收线程在接收到提交操作后,按照顺序为所述提交操作设置提交编号,并将所述提交操作所属的待执行事务分发至相对应的事务执行线程。
在本实施例中,目的端数据同步系统启动后需要初始化一个日志接收线程、一组事务执行线程和一条执行线程链表,其中,事务执行线程的具体数目依据实际情况而定,在此,不做具体限定。
其中,日志接收线程负责接收和管理从源端数据同步系统发过来的事务;事务执行线程则负责事务的执行入库,多个事务执行线程可以并行执行;执行线程链表则是用来登记执行事务线程中待执行事务在源端的提交顺序,按照事务的提交日志序列号的大小进行顺序排列。
日志接收线程接收到操作后,对操作进行解析得到操作的类型,在接收到提交操作后,按照顺序为所述提交操作设置提交编号,在完成对提交操作的编号后,并将所述提交操作所属的待执行事务分发至相对应的事务执行线程。
其中,在分发待执行事务到事务执行线程时,需要按事务的提交操作的日志序列号的大小顺序进行分发,提交日志序列号小的事务代表该事务在源端先提交,那么在目的端执行时,该事务就需要先被分发到事务执行线程,由此确保事务执行线程能够先开始执行在先提交的事务。
步骤102:日志接收线程在接收到DML操作后,获取发生于所述DML操作之前,且最接近于所述DML操作的提交操作的目标提交编号,采用所述目标提交编号标记所述DML操作。
在实际应用场景下,数据库日志在把数据库中的操作写入日志时采用的是串行方式,也就是说,数据库内部并行执行的事务操作产生的日志,会交替的写入到日志文件中,鉴于上述原因,假如只有一个活动事务对某个表做批量的UPDATE操作,那么数据库日志中将会连续的记录这个表的UPDATE日志;假如有两个活动事务分别针对同一个表做UPDATE操作,那么数据库日志中将会交替的记录这个表上两个事务的UPDATE日志。因此,可以在每一个DML(Data Manipulation Language,简写为DML)操作中追加前一个提交操作的提交编号,以此确定单个事务中相邻的两个操作之间是否存在其它冲突事务。
在本实施例中,日志接收线程在接收到源端的操作以后,对操作进行解析得到操作的类型,当接收到DML操作时,所述日志接收线程发生于所述DML操作之前,且最接近于所述DML操作的提交操作的目标提交编号,采用所述目标提交编号标记所述DML操作。
在实际应用场景下,当接收到DML操作时,所述日志接收线程还对所述DML操作进行解析,得到所述DML操作所涉及的对象信息、所述DML操作的操作类型以及所述DML操作所属的事务标识号,其中,对象信息包括表信息、视图信息或索引信息,所述DML操作的操作类型包括删除操作、插入操作和更新操作。
然后,依据所述DML操作所属的事务标识号将所述DML操作归类至相应的事务中;将所述DML操作所涉及的对象信息和所述DML操作的操作类型添加到对应的事务中,当接收到提交操作后,将所述提交操作所属的待执行事务分发至相对应的事务执行线程。
在实际应用场景下,所述DML操作所涉及的对象信息用于在进行同步时,判断其他待执行事务中是否存在与所述DML操作涉及相同对象的操作,以确定是否可以合并操作;所述DML操作的操作类型用于在进行数据同步时,当其他待执行事务中存在与所述DML操作涉及相同对象的操作时,判断该操作与所述DML操作的相容性,以确定是否可以合并操作。
步骤103:所述事务执行线程从待执行事务中取出当前待执行操作。
其中,每个事务执行线程在启动以后还需要初始化一条待执行操作链表,用来收集相同类型的操作,以便合并实现批量执行。
在本实施例中,多个事务执行线程可以并行执行,每个事务执行线程从其所负责的待执行事务中取出一个待执行操作,判断当前待执行操作的类型,若当前待执行操作为DML操作时,判断所述当前待执行操作的操作类型与所述待执行操作链表中已有的操作的操作类型是否相同。若操作类型相同,则执行步骤104,进而确定是否可以进行操作合并的步骤;若操作类型不相同,则执行并清空所述待执行操作链表中已有的操作,再执行步骤104。
步骤104:根据所述当前待执行操作所携带的目标提交编号,确定所述当前待执行操作与其他待执行事务的相容性,进而确定是否可以进行操作合并。
在本实施例中,根据所述当前待执行操作所携带的目标提交编号,确定所述当前待执行操作与其他待执行事务的相容性,进而确定是否可以进行操作合并。
结合图3,其中,图3仅简略说明每一步骤,不过图3基本展示了并行执行方法的整个流程支路,主要便于理解本方案,确定相容性的方式为:在其他待执行事务中,根据所述当前待执行操作所携带的目标提交编号确定与所述当前待执行操作存在冲突的冲突事务,其中,所述冲突事务指的是在日志流中,本事务的两个相邻操作之间还夹杂着提交操作,该提交操作所属的待执行事务为冲突事务。在确定了冲突事务后,判断冲突事务中是否存在与所述当前待执行操作相关联的关联对象,若不存在,则所述当前待执行操作与所述冲突事务相容;若存在,则进一步判断冲突事务对关联对象所进行的操作与所述当前待执行操作是否相容,若相容,则将所述当前待执行操作添加至待执行操作链表的尾端;若不相容,则等待冲突事务提交后,再将所述当前待执行操作添加至待执行操作链表的尾端。
在本实施例中,数据库的日志流中记录的操作先后顺序可以直接反映出各个事务的操作在数据库内部执行的先后顺序,而以日志流中的提交操作作为分界线则反映出各个事务操作在数据内部执行的并行度。通过判断单个事务中两个操作之间是否存在其它事务的提交操作为条件来合并操作,并且在夹杂有提交操作时通过判断操作和提交操作对应的事务中涉及的表和操作相容性等策略来尽可能的合并操作,最大限度的合并操作可以有效的提升同步的性能。
参阅图2和图3,其中,图3仅简略说明每一步骤,不过图3基本展示了并行执行方法的整个流程支路,主要便于理解本方案具体说明步骤104的实现过程,
步骤1041:判断所述当前待执行操作所携带的目标提交编号与所述待执行操作链表中最后一个操作所携带的目标提交编号是否相同。
其中,若二者的提交编号相同,则说明二者可以合并执行,执行步骤1042;若二者的提交编号不相同,则说明二者有可能不能合并执行,执行步骤1043。
在本实施例中,如果当前待执行操作和待执行操作链表中最后一个操作的提交编号一致,那么就说明该操作在源数据库执行时它和上一个操作是可以合并执行的,因为这两个操作中间没有参杂其它事务的提交操作在里面;如果这两个操作之间夹杂有提交操作,那么就有可能该操作在源数据库执行时被其它事务阻塞,导致它和本事务上一个操作不能合并执行。
步骤1042:若提交编号相同,则将所述当前待执行操作添加在所述待执行操作链表的尾部。
在优选的实施例中,将当前待执行操作添加到待执行操作链表后,判断待执行操作链表中已有的操作的数目是否已经达到设定值,若达到设定值,则将待执行操作链表中已有的操作批量入库,以清空待执行操作链表,防止待执行操作链表缓存太多的操作,从而影响到内存的占用。
在本实施例中,采用链表缓存的方式先缓存相同的操作,积累到一定数量以后再批量执行入库可以减少和数据库交互的次数,从而提升执行性能。
步骤1043:若提交编号不相同,则依次提取两个目标提交编号中的冲突事务。
在本实施例中,若二者的提交编号不相同,则说明二者有可能不能合并执行,需要继续判断当前待执行操作与两个操作之间的冲突事务是否相容。因此,需要先确定两个操作之间的冲突事务,具体方式为依次提取两个目标提交编号中的冲突事务,其中,两个目标提交编号可能只相差1,则只存在一个冲突事务,两个目标提交编号可能相差2、3或更大值,则相应的存在2个、3个或更多个冲突事务,需要获取全部的冲突事务,然后,依次判断当前待执行操作与冲突事务是否相容。
在本实施例中,在执行线程链表中登记有提交操作的日志序列号和提交操作的提交编号,获取位于两个目标提交编号中之间的冲突事务的提交编号,基于获取到的冲突事务的提交编号,从所述执行线程链表中获取冲突事务的提交操作的日志序列号,进而确定冲突事务。
在本实施例中,一个事务在日志流中任意两个操作之间涉及的冲突事务,如果冲突事务所涉及的对象和当前待执行操作所涉及的对象不冲突的情况下,这两个操作就可以合并。由于提交编号是采用顺序递增方式来进行的,那么通过计算出两个操作中的提交编号中间间隔的全部提交编号便可以找到对应的事务。
步骤1044:判断在所述冲突事务中是否存在与所述当前待执行操作相关联的关联对象。
在获取到冲突事务后,获取所述冲突事务所包含的全部操作的操作对象,判断所述当前待执行操作所涉及的对象与前述获取到的操作对象是否存在关联,以判断在所述冲突事务中是否存在与所述当前待执行操作相关联的关联对象。
若不存在关联对象,则执行步骤1045;若存在关联对象,则执行步骤1046。
步骤1045:若不存在关联对象,则将所述当前待执行操作添加在所述待执行操作链表的尾部。
步骤1046:若存在关联对象,则判断所述冲突事务对所述关联对象所进行的操作,与所述当前待执行操作是否相容,以确定是否可以进行操作合并。
在本实施例中,若存在关联对象,则需要结合当前待执行操作和冲突事务对关联对象所进行的操作的类型,判断所述冲突事务与所述当前待执行操作是否相容。具体的规则,如下述步骤1047和步骤1049。
步骤1047:若所述冲突事务和所述当前待执行操作对所述关联对象均进行插入操作或删除操作,则所述冲突事务和所述当前待执行操作相容。
步骤1048:将所述当前待执行操作添加在所述待执行操作链表的尾部。
步骤1049:若所述冲突事务和所述当前待执行操作对所述关联对象均进行更新操作,或,所述冲突事务对所述关联对象进行的操作的操作类型与所述当前待执行操作的操作类型不同,则所述冲突事务和所述当前待执行操作不相容。
其中,在本步骤中,操作类型包括:插入操作、删除操作和更新操作,例如,其中一个对关联对象进行插入操作,而另一个对关联对象进行删除操作或更新操作,那么二者不相容;其中一个对关联对象进行删除操作,而另一个对关联对象进行插入操作或更新操作,那么二者不相容。
步骤1050:以批量执行的方式清空所述待执行操作链表中已有的操作。步骤1051:等待所述冲突事务提交后,将所述当前待执行操作添加在所述待执行操作链表的尾部。
在本实施例中,当冲突事务与当前待执行操作不相容时,当前待执行操作与待执行操作链表中已有的操作不能一起合并执行,需要以批量执行的方式清空所述待执行操作链表中已有的操作。
然后,等待所述冲突事务提交后,将所述当前待执行操作添加在所述待执行操作链表的尾部。
将该当前待执行操作添加到待执行操作链表后,再从待执行事务中取出下一个待执行操作,按照前述方式进行操作合并执行。
在本发明中,操作合并的原理主要是:通过判断需要合并的两个相同的操作在日志流所处位置的中间是否夹杂有提交操作,如果没有则合并;如果有再进一步判断当前操作涉及的表是否和两个操作中间提交的事务中涉及的表相冲突,如果存在冲突,则利用操作相容的规则来判定这两个操作是否可以合并执行。
本发明的基本步骤,可以解释如下:首先,数据库的日志流中记录的操作先后顺序可以直接反映出各个事务的操作在数据库内部执行的先后顺序,而以日志流中的提交操作作为分界线则反映出各个事务操作在数据内部执行的并行度,两个事务的操作在日志流中以第一个事务的提交操作为界,前面重合的那部分操作可以表示在源数据库中是并行执行的,而后面单个事务的操作在源数据库运行时可能会访问到前面一个事务的数据。那么后提交的事务在合并操作时,就应该以前面一个事务在日志流中的提交操作为界来判断界后的操作是否能够和界前面的操作合并执行。
其次,在以提交操作日志为界来判断能否合并时,还可以考虑这两个事务操作的对像是否有交集,如果两个事务完全访问不相关的表,那界前界后的操作理所当然是可以合并的;即便两个事务操作的是相同的表,还可以进一步的通过事务操作的相容性来进一步提升操作合并的机率,这样即可以保证执行时数据的一致性,又可以最大限度的提升执行性能。
在实际应用场景下,在进行操作合并执行之前还包括如下过程:
在本实施例中,判断当前待执行操作与其他待执行事务是否存在冲突,其中,冲突类型包括在先事务也对当前待执行操作所针对的对象进行DML操作,则需要等待在先事务在目的端提交之后,再对当前待执行操作进行处理,其中,在先事务指的是提交日志序列号小于当前待执行操作所属的事务的提交日志序列号的事务。冲突类型还包括在先事务的行锁没有构造完成,则需要等待在先事务的行锁构造完成后,再对当前待执行操作进行处理。
若当前待执行操作与其他待执行事务存在冲突,则将当前待执行操作所属的事务执行线程添加至冲突事务的唤醒链表中,在冲突解除后执行日志入库处理。
在本实施例中,若当前待执行操作与其他待执行事务不存在冲突,则说明当前待执行操作可以与其他待执行事务并行执行,执行前述步骤104,若当前待执行操作与其他待执行事务存在冲突,则当前待执行操作可以与其他待执行事务串行执行,即,需要解除冲突后,再执行日志入库处理。
其中,每个事务执行线程启动后初始化一条行锁唤醒链表和一条提交唤醒链表,行锁唤醒链表则用来存放等待本事务操作的行锁构造完成以后需要唤醒的事务执行线程;提交唤醒链表则用来存放等待本事务提交完成以后需要唤醒的事务执行线程。
若当前待执行操作为提交操作,则唤醒行锁唤醒链表中的事务执行线程,然后,执行清空待执行操作链表中的操作并提交,完成提交后,唤醒提交唤醒链表中的事务执行线程。
在本实施例中,主要是通过冲突检测的机制,把本该在其它事务提交之后才能开始执行的操作提前执行,尽可能的把不冲突的事务操作提前执行,减少等待其它事务的提交次数,从而增加了并行度,在保证数据复制一致性的前提下,提高目的端数据复制的执行效率。在实际应用场景下,
具体地,在进行冲突检测之前,对当前待执行操作构造行锁,每一事务执行线程还配套设置有行锁哈希表和待执行操作链表,所述行锁哈希表用于存放操作的行锁信息,所述待执行操作链表用于缓存待执行操作。
在本实施例中,若当前待执行操作为DML操作,根据当前待执行操作的ROWID信息构造当前待执行操作的行锁,将当前待执行操作的行锁添加至相应的行锁哈希表中。在进行冲突检测时,根据当前待执行操作的基于ROWID信息构成的行锁,判断当前待执行操作与在先事务是否存在行锁冲突,若在先事务中存在相同的行锁,则当前待执行操作与在先事务存在行锁冲突。
其中,ROWID用于定位数据库中一条记录的一个相对唯一地址值,通常情况下,该值在该行数据插入到数据库表时即被确定且唯一,ROWID是根据每一行数据的物理地址信息编码而成的一个伪列,所以根据一行数据的ROWID能找到一行数据的物理地址信息,从而快速地定位到数据行。
在本实施例中,主要是通过ROWID检测冲突的方式,把本该在其它事务提交之后才能开始执行的操作提前执行,尽可能的把不冲突的事务操作提前执行,减少等待其它事务的提交次数,从而增加了并行度。行锁唤醒链表结合执行线程链表保确保ROWID行锁构造的先后顺序,提交唤醒链表结事执行线程链表来确保冲突的事务执行顺序,执行线程链表则用来确保事务的提交顺序。
实施例2:
源端数据库和目的端数据库现都有表T(ID INT PRIMARY KEY,C1 INT),源端应用有三个事务对表T进行如下操作:
TRX1:INSERT INTO T(ID,C1)VALUES(1,1);
TRX2:INSERT INTO T(ID,C1)VALUES(10,10);
TRX1:INSERT INTO T(ID,C1)VALUES(2,2);
TRX1:COMMIT;
TRX2:INSERT INTO T(ID,C1)VALUES(20,20);
TRX3:UPDATE T SET C1=1WHERE ID=1;
TRX2:UPDATE T SET C1=2WHERE ID=2;
TRX2:COMMIT;
TRX3:UPDATE T SET C1=10WHERE ID=10;
TRX3:COMMIT;
上述操作的顺序代表这些操作在日志流中的顺序,日志接收线程在接收到上述操作后给提交操作按顺序编号,DML操作则设置它上一个提交操作的提交编号,假设提交操作编号从0开始,就会形成如下编号表格:
事务ID |
操作 |
提交操作编号 |
TRX1 |
INSERT INTO T(ID,C1)VALUES(1,1); |
0 |
TRX2 |
INSERT INTO T(ID,C1)VALUES(10,10); |
0 |
TRX1 |
INSERT INTO T(ID,C1)VALUES(2,2); |
0 |
TRX1 |
COMMIT; |
1 |
TRX2 |
INSERT INTO T(ID,C1)VALUES(20,20); |
1 |
TRX3 |
UPDATE T SET C1=1WHERE ID=1; |
1 |
TRX2 |
UPDATE T SET C1=2WHERE ID=2; |
1 |
TRX2 |
COMMIT; |
2 |
TRX3 |
UPDATE T SET C1=10WHERE ID=10; |
2 |
TRX3 |
COMMIT; |
3 |
假设目的端同步系统初始化了三个事务执行线程,分别为EXEC1、EXEC2和EXEC3。执行过程如下:日志接收线程接收到上述三个事务,按事务提交顺序把TRX1、TRX2和TRX3分派给三个执行线程。
三个执行线程并行执行过程如下:
从上面的执行流程可以看出,TRX1的两个INSERT操作它们的提交操作编号相同,所以可以合并执行;TRX2的两个INSERT操作中间虽然夹杂有TRX1的提交操作,但是这两个INSERT操作按照规则是可以合并执行的,而TRX3的两个UPDATE操作,这两个UPDATE操作中间夹杂有TRX2的提交操作,但是这两个UPDATE操作按照规则就不能合并,只能分开先执行UPDATE(ID=1),等待TRX2提交以后再执行UPDATE(ID=10)才能保证TRX2和TRX3并行执行时操作的执行顺序和源端数据库保持一致。
实施例3:
请参阅图4,图4是本发明实施例提供的一种数据同步系统的结构示意图。本实施例的数据同步系统包括一个或多个处理器41以及存储器42。其中,图4中以一个处理器41为例。
处理器41和存储器42可以通过总线或者其他方式连接,图4中以通过总线连接为例。
存储器42作为一种基于日志解析同步的操作合并执行方法的非易失性计算机可读存储介质,可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块,上述实施例的方法以及对应的程序指令。处理器41通过运行存储在存储器42中的非易失性软件程序、指令以及模块,从而执行各种功能应用以及数据处理,实现前述实施例的方法。
其中,存储器42可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中,存储器42可选包括相对于处理器41远程设置的存储器,这些远程存储器可以通过网络连接至处理器41。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
值得说明的是,上述装置和系统内的模块、单元之间的信息交互、执行过程等内容,由于与本发明的处理方法实施例基于同一构思,具体内容可参见本发明方法实施例中的叙述,此处不再赘述。
本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:只读存储器(Read Only Memory,简写为ROM)、随机存取存储器(RandomAccessMemory,简写为RAM)、磁盘或光盘等。
本领域的技术人员容易理解,以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。