发明内容
针对现有技术的以上缺陷或改进需求,本发明提供了一种基于日志解析的异构数据库的双向同步方法和同步装置,其目的在于,通过采用专属用户来区分产生操作日志的用户对象,无需创建辅助表,避免了对端执行到增量数据的末尾才识别出数据来源进而确定是否需要同步的情况,相较于辅助表的方式,同步效率更高,而且可以避免数据库的侵入风险。另外,本发明的方法适用于广泛的关系型数据库***,不论何种类型的数据库均实现DDL操作和DML操作的双向同步,避免同步操作陷入死循环。
为实现上述目的,按照本发明的一个方面,提供了一种基于日志解析的异构数据库的双向同步方法,所述双向同步方法应用于双向同步***,所述双向同步***包括两个数据同步***,所述数据同步***包括数据同步服务和数据库,两个数据同步***互为本端数据同步***和对端数据同步***,所述双向同步方法包括:
分别为所述双向同步***中的两个数据同步***创建专属用户;
在数据同步服务初始启动时,设置同步事务的过滤用户为本数据同步***中创建的专属用户;
在进行增量数据同步时,位于所述本端数据同步***的数据同步服务获取操作日志,对所述操作日志进行解析得到所述操作日志所属的用户对象;
判断所述操作日志所属的用户对象是否为过滤用户;
若是,则丢弃所述操作日志;
若不是,则将所述操作日志发送至所述对端数据同步***,所述对端数据同步***使用其上的专属用户创建的数据库连接执行数据同步。
优选地,所述分别为所述本端数据同步***和所述对端数据同步***创建专属用户包括:
使用创建用户语句,分别为所述本端数据同步***和所述对端数据同步***创建专属用户;
设置所述专属用户只用于数据同步服务,并为所述专属用户设置数据库权限,其中,所述数据库权限包括创建数据库连接、执行SQL语句和操作待同步表。
优选地,所述数据同步服务包括日志捕获模块、日志传输模块和同步执行模块;
所述日志捕获模块捕获数据库***的归档日志文件或在线日志文件中的操作日志;
对所述操作日志进行解析得到所述操作日志所属的用户对象,当所述操作日志所属的用户对象不为过滤用户时,将所述操作日志转换为同步服务***内部统一格式的消息包,传递给所述日志传输模块;
所述日志传输模块将经过格式转换的所述操作日志发送到对端的数据同步服务,还接收对端发送过来的操作日志;
所述同步执行模块接收对端发过来的操作日志,根据操作日志所属的事务进行分类,并使用其上的专属用户创建的数据库连接执行本次同步操作。
优选地,所述方法还包括:
在数据同步服务初始启动时,通过配置文件形式读取配置的过滤用户的名称,以根据过滤用户的名称对同步过程中事务的进行控制和过滤。
优选地,所述双向同步方法还包括:
数据同步的实现过程包括:
在本地内存中建立关联列的结果集;
在接收到同步表的操作日志后,基于所述结果集对所述操作日志进行过滤,以选择性对所述操作日志进行同步。
优选地,所述在接收到同步表的操作日志后,基于所述结果集对所述操作日志进行过滤,以选择性对所述操作日志进行同步包括:
在接收到同步表的操作日志,对所述同步表的操作日志进行解析,得到所述同步表的关联列的列值;
判断所述同步表的关联列的列值是否存在于所述结果集中;
若存在,则将当前操作日志添加至所述同步表的待执行操作队列中,以进行数据同步;
若不存在,则丢弃当前操作日志。
优选地,所述在本地内存中建立关联列的结果集包括:
读取结果集缓存配置文件,提取引用表的表名、关联列名和过滤条件;
根据所述引用表的表名、关联列名和过滤条件构建查询语句;
基于数据库连接,通过所述查询语句查询出满足所述过滤条件的目标列值;
在目标端内存中构建哈希缓存结构,以所述目标列值为哈希搜索键值,建立基于哈希结构的结果集。
优选地,接收所述引用表的操作日志,根据所述引用表的操作日志动态更新所述结果集;
其中,动态更新的过程包括:
判断所述引用表的操作日志的操作类型;
若为DML操作,则判断所述操作日志是否满足所述过滤条件;
若满足,则提取所述引用表的关联列的目标列值,并根据所述DML操作的操作类型策略性更新所述结果集。
优选地,所述根据所述DML操作的操作类型策略性更新所述结果集包括:
当所述DML操作为INSERT操作时,判断INSERT操作对应的目标列值是否存在于所述结果集中;
若存在,则不更新所述结果集;
若不存在,则将INSERT操作对应的目标列值进行哈希缓存,以更新所述结果集。
为实现上述目的,按照本发明的另一个方面,提供了一种同步装置,所述同步装置包括至少一个处理器;以及,与所述至少一个处理器通信连接的存储器;其中,所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被程序设置为执行本发明所述的双向同步方法。
总体而言,通过本发明所构思的以上技术方案与现有技术相比,具有如下有益效果:提供一种基于日志解析的异构数据库的双向同步方法和同步装置,双向同步方法包括:分别为双向同步***中的两个数据同步***创建专属用户;在数据同步服务初始启动时,设置同步事务的过滤用户为本数据同步***中创建的专属用户;在进行增量数据同步时,位于本端数据同步***的数据同步服务获取操作日志,对操作日志进行解析得到操作日志所属的用户对象;判断操作日志所属的用户对象是否为过滤用户;若是,则丢弃操作日志;若不是,则将操作日志发送至对端数据同步***,对端数据同步***使用其上的专属用户创建的数据库连接执行数据同步。
在本发明中,通过采用专属用户来区分产生操作日志的用户对象,无需创建辅助表,而且在对操作日志进行解析得到操作日志所属的用户对象后,即可确定该操作日志是否需要同步,将不需要同步的日志丢弃,只将需要同步的日志发送到对端,避免了对端执行到增量数据的末尾才识别出数据来源进而确定是否需要同步的情况,相较于辅助表的方式,同步效率更高,而且可以避免数据库的侵入风险。另外,本发明的方法适用于广泛的关系型数据库***,不论何种类型的数据库均实现DDL操作和DML操作的双向同步,避免同步操作陷入死循环。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
在本发明的描述中,术语“内”、“外”、“纵向”、“横向”、“上”、“下”、“顶”、“底”等指示的方位或位置关系为基于附图所示的方位或位置关系,仅是为了便于描述本发明而不是要求本发明必须以特定的方位构造和操作,因此不应当理解为对本发明的限制。
此外,下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。
实施例1:
本发明提供一种基于日志解析的异构数据库的双向同步方法,所述双向同步方法应用于双向同步***,所述双向同步***包括两个数据同步***,所述数据同步***包括数据同步服务和数据库,两个数据同步***互为本端数据同步***和对端数据同步***。
参阅图1,所述双向同步方法包括:
步骤101:分别为所述双向同步***中的两个数据同步***创建专属用户。
在本实施例中,使用创建用户语句(create user),分别为所述本端数据同步***和所述对端数据同步***创建专属用户,其中,专属用户为普通的数据库用户对象,且仅供数据同步服务所使用,不提供给其他应用使用。
然后,设置所述专属用户只用于数据同步服务,并为所述专属用户设置数据库权限,其中,所述数据库权限包括创建数据库连接、执行SQL语句和操作待同步表。
步骤102:在数据同步服务初始启动时,设置同步事务的过滤用户为本数据同步***中创建的专属用户。
在本实施例中,在数据同步服务初始启动时,通过配置文件形式读取配置的过滤用户的名称,以根据过滤用户的名称对同步过程中事务的进行控制和过滤。
步骤103:在进行增量数据同步时,位于所述本端数据同步***的数据同步服务获取操作日志,对所述操作日志进行解析得到所述操作日志所属的用户对象。
步骤104:判断所述操作日志所属的用户对象是否为过滤用户。
若为过滤用户,则说明该操作日志是由本端数据同步***产生的,该操作日志无需同步至对端,则执行步骤105;若不为过滤用户,则说明该操作日志不是由本端数据同步***产生的,该操作日志需要同步至对端,则执行步骤106。
步骤105:若是,则丢弃所述操作日志。
步骤106:若不是,则将所述操作日志发送至所述对端数据同步***,所述对端数据同步***使用其上的专属用户创建的数据库连接执行数据同步。
具体而言,结合图2,所述数据同步服务包括日志捕获模块、日志传输模块和同步执行模块。
所述日志捕获模块捕获数据库***的归档日志文件或在线日志文件中的操作日志;对所述操作日志进行解析得到所述操作日志所属的用户对象,当所述操作日志所属的用户对象不为过滤用户时,将所述操作日志转换为同步服务***内部统一格式的消息包,传递给所述日志传输模块。
所述日志传输模块将经过格式转换的所述操作日志通过TCP/IP网络发送到对端的数据同步服务,还接收对端发送过来的操作日志。
所述同步执行模块接收对端发过来的操作日志,根据操作日志所属的事务进行分类,并使用其上的专属用户创建的数据库连接执行本次同步操作。
为了便于理解本实施例的方案,下面进行举例说明明。首先,分别假定数据双向同步的两个数据同步***为数据同步***A和数据同步***B,下面给出数据同步***A向数据同步***B进行增量数据同步的一个具体实施方式:
在数据同步***A中创建一个专属用户USERA,在数据同步***B中创建一个专属用户USERB。
分别在A端的数据同步服务的配置文件中加入过滤用户参数USERA,在B端的数据同步服务的配置文件中加入过滤用户参数USERB;两端的数据同步服务初始启动时,读取配置文件中的过滤用户参数,用于设置过滤用户。
增量数据同步时,A端数据同步服务的日志捕获模块工作步骤为:实时读取A数据库的日志文件,捕获出增量的操作日志。根据捕获到的操作日志,读取出操作日志所属的用户对象,如果是过滤用户USERA,则丢弃该操作日志,否则,解析该操作日志内容,转换为特定的消息格式,传递给日志传输模块。
增量数据同步时,A端数据同步服务的日志传输模块,将操作日志发送至对端,同时也接收对端发送过来的操作日志。
增量数据同步时,A端数据同步服务的同步执行模块工作步骤为:接收对端数据同步服务(B端)发送过来的事务消息数据;解析消息数据,根据事务操作、表对象、表数据等生成相对应的SQL语句;使用USERA用户创建的数据库连接,执行相应的SQL语句,完成数据的实时同步。
在此,需要说明的,是B端向A端同时进行增量数据同步的过程与A到B的同步流程基本相同,只是上述步骤中的过滤用户与执行用户均为USERB。
在实施例中,通过采用专属用户来区分产生操作日志的用户对象,无需创建辅助表,而且在对操作日志进行解析得到操作日志所属的用户对象后,即可确定该操作日志是否需要同步,将不需要同步的日志丢弃,只将需要同步的日志发送到对端,避免了对端执行到增量数据的末尾才识别出数据来源进而确定是否需要同步的情况,相较于辅助表的方式,同步效率更高,而且可以避免数据库的侵入风险。另外,本实施例的方法适用于广泛的关系型数据库***,不论何种类型的数据库均实现DDL操作和DML操作的双向同步,避免同步操作陷入死循环。
实施例2:
在一实际应用场景下,在异构数据库数据实时同步中,通常都会基于业务需求对同步数据表实施相应的数据过滤策略,以达到仅同步所需要的部分数据的目的。对于这样一种数据同步规则:源数据库表A与表B通过相对应字段进行关联,同步表A需要引用源端数据库中的表B中的数据,以实现同步数据过滤,也即是表A中同步的数据需要满足这样的查询条件,select*from A where A.field in(select B.field from B where condition),不满足这种条件的数据则不进行同步。对于这种通过表字段进行关联的数据过滤条件,为了实现数据的过滤,同步工具在同步表A中的每一行数据时,都需要根据关联字段(field)在表B中进行select查询操作,对于满足查询条件的行记录,则实施数据同步,否则进行过滤。显然,频繁的select查询会影响源端数据库的性能且会对表B的使用造成影响,另一方面,当表B的数据量较大时,select查询耗时较大,会影响表A同步的性能。
为了解决前述问题,对端数据库***在接收到来自本端的数据后,可以按照下述方式进行数据同步:在本地内存中建立关联列的结果集;在接收到同步表的操作日志后,基于所述结果集对所述操作日志进行过滤,以选择性对所述操作日志进行同步。
具体的实现步骤参阅图3:
步骤201:在本地内存中建立关联列的结果集。
在本实施例中,首先,读取数据源配置文件,提取数据源连接信息,根据所述数据源连接信息创建数据库连接,其中,所述数据源连接信息包括数据库地址、数据库连接用户名、密码和连接端口。
在本地内存中建立关联列的结果集的过程为:读取结果集缓存配置文件,提取引用表的表名、关联列名和过滤条件;根据所述引用表的表名、关联列名和过滤条件构建查询语句;基于数据库连接,通过所述查询语句查询出满足所述过滤条件的目标列值;在本地内存中构建哈希缓存结构,以所述目标列值为哈希搜索键值,建立基于哈希结构的结果集。
在本实施例中,结果集的获取主要分为初始建立过程和动态更新过程。
初始建立过程为:目的端与源端建立数据库连接,通过查询语句查询出满足过滤条件的目标列值;在目标端内存中构建哈希缓存结构,以所述目标列值为哈希搜索键值,建立基于哈希结构的结果集。
动态更新过程为:根据引用表的操作日志的操作类型和过滤条件动态更新关联列的结果集。具体详见下文描述。
步骤202:接收同步表的操作日志,对所述同步表的操作日志进行解析,得到所述同步表的关联列的列值。
步骤203:判断所述同步表的关联列的列值是否存在于所述结果集中。
步骤204:若存在,则将当前操作日志添加至所述同步表的待执行操作队列中。
在本实施例中,以本端为源端,对端为目标端为例进行解释说明,在异构数据同步源端,数据同步服务基于日志捕获解析技术,捕获并解析源端数据库中同步表和引用表的事务操作日志,在操作日志经过过滤用户过滤后,将操作日志经过内部消息转换后发送给目标端的数据同步服务。
在异构数据同步目标端,数据同步服务完成上述步骤201的初始化准备操作后,等待接收源端发送过来的事务操作日志。当接收到同步表的事务操作日志时,同步执行步骤为:解析源端发送过来的事务消息,从中提取出同步表的关联列的列值;以关联列的列值为哈希搜索键值,在上述步骤201中构建的哈希缓存结构中进行哈希搜索,判断所述同步表的关联列的列值是否存在于所述结果集中,若不存在,则丢弃本次事务操作日志;若存在,则将当前操作日志添加至所述同步表的待执行操作队列中,等待接收到事务的提交操作(commit)后,唤醒日志执行模块进行同步执行。
举例而言,对源端数据库***中的同步表约定为表A,其中,表A在同步过程中需要进行部分数据的过滤,过滤规则为:
表A中的某列数据需要引用源端数据库中其他表B(引用表)的关联列数据,为方便描述,约定表A中关联列为CA列,表B中关联列为CB列。
表A中的数据同步时,需要满足过滤条件:select*from A where A.CA in(selectB.CB from B where condition),其中,过滤条件condition可根据实际业务需要选取,以得到满足特定条件的CB列值集合。
当表A中的CA列值不满足上述规则中时,则进行过滤,无需数据同步。也即表A中CA列值不存在于表B中满足特定查询条件的CB列值集合中时,则无需数据同步。
在实际应用场景下,目标端接收源端所发送的引用表的操作日志,根据引用表的操作日志动态更新结果集,动态更新的过程包括如下步骤:接收所述引用表的操作日志,判断所述引用表的操作日志的操作类型,若为DML操作,接收所述引用表的操作日志,根据关联列名提取关联列的目标列值,判断目标列值是否满足所述过滤条件。若满足过滤条件,则提取所述引用表的关联列的目标列值,并根据所述DML操作的操作类型策略性更新所述结果集。若不满足过滤条件,则忽略所述操作日志,接收一下操作日志,以更新结果集。
策略性更新所述结果集的过程为:在本实施例中,当所述DML操作为INSERT操作时,判断INSERT操作是否满足配置文件中设定的过滤条件,若不满足,则不更新所述结果集;若满足,则判断INSERT操作对应的目标列值是否存在于所述结果集中;若存在,则不更新所述结果集;若不存在,则将INSERT操作对应的目标列值进行哈希缓存,以更新所述结果集。
当所述DML操作为UPDATE操作时,则根据过滤条件来决定释放所述结果集中UPDATE操作的旧值;和/或将UPDATE操作的新值进行哈希缓存,以更新所述结果集。
在实际应用场景下,针对UPDATE,要先判断它是否存在于结果集中,如果存在,要接着判断它是否满足过滤条件,因为有了过滤条件的限制,有可能原本可以缓存在结果集中的目标列由于更新了某个列值变得不满足过滤条件,那么这时候要把它从结果集中删除;相反,当原本不存在于缓存结果集中的行由于更新了某个列值,这时候变得满足了过滤条件,这种情况下要把它加入到结果集中。
具体实现过程为:当所述DML操作为UPDATE操作时,判断UPDATE操作更新前的目标列值是否存在于所述结果集中;若存在,则判断UPDATE操作是否满足配置文件中设定的过滤条件;若满足,则释放所述结果集中UPDATE操作的旧值(更新前的目标列值),将UPDATE操作的新值(更新后的目标列值)进行哈希缓存,以更新所述结果集;若不满足,则释放所述结果集中UPDATE操作的旧值,以更新所述结果集;若不存在,则判断UPDATE操作是否满足配置文件中设定的过滤条件;若满足,则将UPDATE操作更新后的目标列值进行哈希缓存,以更新所述结果集;若不满足,则不更新结果集。
当所述DML操作为DELETE操作时,释放所述结果集中DELETE操作的列值。
若为TRUNCATE操作或DROP操作,则释放所述结果集的哈希结构,并重置为未初始化状态。
在本实施例中,在内存中构建哈希结构,缓存引用表的关联列的列值得到结果集,并基于日志捕获解析的技术实现结果集的动态实时更新。在对同步表中的数据进行同步时,只需要根据关联字段(关联列的列值),在哈希结构中进行直接搜索,而无需进行源表的select查询操作即能实现数据的过滤,且哈希搜索效率较高,提升了同步表的数据实时同步的性能。另一方面,通过查询条件能够实现仅哈希缓存所需要的关联数据,缩小了数据缓存的规模,无需select查询整个数据表。
实施例3:
在一实际应用场景下,源端数据库上并发执行的各个事务中可能存在大量批量执行的操作,数据库***都会根据并发控制机制去执行,把相冲突的事务操作互斥执行,并且在日志文件中顺序的记录下各个事务的操作日志,数据同步时应该尽可能还原出源端的批量操作以提升同步性能。如果目的端数据复制软件严格按照源端日志流中的事务提交顺序进行串行执行,对事务中相同的操作合并后批量执行则能够保证数据复制的一致性,但是串行执行效率将会非常低,所以在目的端同步执行事务时往往会采取多线程并行执行的策略。在并行执行的环境下,单个事务在执行时同样需要采用相同操作合并后,批量执行的方式来提升同步性能,然而并行执行则需要考虑到正在执行的事务之间是否存在数据关联性的问题,事务在执行时不能无规则的合并相同的操作。因此,在如何保证数据复制一致性的前提下来合并事务内的操作,提高目的端数据复制的并行执行效率,就成为业界亟待解决的重要技术问题。
在本实施例中,同步执行模块配套设置有一个日志接收线程、一组事务执行线程和一个执行线程链表,其中,日志接收线程负责接收和管理从源端数据同步***发过来的事务;事务执行线程则负责事务的执行入库,多个事务执行线程可以并行执行;执行线程链表则是用来登记执行事务线程中待执行事务在源端的提交顺序,按照事务的提交日志序列号的大小进行顺序排列。
在本实施例中,以本端为源端,对端为目标端为例进行解释说明。
结合前述实施例2,在步骤204中,同步执行模块获取当前操作日志的事务标识号,依据所述事务标识号将当前待执行操作添加至相应的待执行事务中,在接收到相应事务的提交操作后,将待执行事务分发至相对应的事务执行线程进行数据同步。
在本实施例中,操作日志的类型包括DML操作和提交操作,进行数据同步的具体过程如下:
(1)日志接收线程在接收到提交操作后,按照顺序为所述提交操作设置提交编号,并将所述提交操作所属的待执行事务分发至相对应的事务执行线程。
其中,在分发待执行事务到事务执行线程时,需要按事务的提交操作的日志序列号的大小顺序进行分发,提交日志序列号小的事务代表该事务在源端先提交,那么在目的端执行时,该事务就需要先被分发到事务执行线程,由此确保事务执行线程能够先开始执行在先提交的事务。
(2)日志接收线程在接收到DML操作后,获取发生于所述DML操作之前,且最接近于所述DML操作的提交操作的目标提交编号,采用所述目标提交编号标记所述DML操作。
在实际应用场景下,数据库日志在把数据库中的操作写入日志时采用的是串行方式,也就是说,数据库内部并行执行的事务操作产生的日志,会交替的写入到日志文件中,鉴于上述原因,假如只有一个活动事务对某个表做批量的UPDATE操作,那么数据库日志中将会连续的记录这个表的UPDATE日志;假如有两个活动事务分别针对同一个表做UPDATE操作,那么数据库日志中将会交替的记录这个表上两个事务的UPDATE日志。因此,可以在每一个DML操作中追加前一个提交操作的提交编号,以此确定单个事务中相邻的两个操作之间是否存在其它冲突事务。
在本实施例中,日志接收线程在接收到源端的操作以后,对操作进行解析得到操作的类型,当接收到DML操作时,所述日志接收线程发生于所述DML操作之前,且最接近于所述DML操作的提交操作的目标提交编号,采用所述目标提交编号标记所述DML操作。
在实际应用场景下,当接收到DML操作时,所述日志接收线程还对所述DML操作进行解析,得到所述DML操作所涉及的对象信息、所述DML操作的操作类型以及所述DML操作所属的事务标识号,其中,对象信息包括表信息、视图信息或索引信息,所述DML操作的操作类型包括删除操作、***操作和更新操作。
然后,依据所述DML操作所属的事务标识号将所述DML操作归类至相应的事务中;将所述DML操作所涉及的对象信息和所述DML操作的操作类型添加到对应的事务中,当接收到提交操作后,将所述提交操作所属的待执行事务分发至相对应的事务执行线程。
在实际应用场景下,所述DML操作所涉及的对象信息用于在进行同步时,判断其他待执行事务中是否存在与所述DML操作涉及相同对象的操作,以确定是否可以合并操作;所述DML操作的操作类型用于在进行数据同步时,当其他待执行事务中存在与所述DML操作涉及相同对象的操作时,判断该操作与所述DML操作的相容性,以确定是否可以合并操作。
(3)所述事务执行线程从待执行事务中取出当前待执行操作。
其中,每个事务执行线程在启动以后还需要初始化一条待执行操作队列,用来收集相同类型的操作,以便合并实现批量执行。
在本实施例中,多个事务执行线程可以并行执行,每个事务执行线程从其所负责的待执行事务中取出一个待执行操作,判断当前待执行操作的类型,若当前待执行操作为DML操作时,判断所述当前待执行操作的操作类型与所述待执行操作队列中已有的操作的操作类型是否相同。若操作类型相同,则执行下述步骤(4),进而确定是否可以进行操作合并的步骤;若操作类型不相同,则执行并清空所述待执行操作队列中已有的操作,再执行下述步骤(4)。
(4)根据所述当前待执行操作所携带的目标提交编号,确定所述当前待执行操作与其他待执行事务的相容性,进而确定是否可以进行操作合并。
在本实施例中,根据所述当前待执行操作所携带的目标提交编号,确定所述当前待执行操作与其他待执行事务的相容性,进而确定是否可以进行操作合并。
在本实施例中,确定相容性的方式为:在其他待执行事务中,根据所述当前待执行操作所携带的目标提交编号确定与所述当前待执行操作存在冲突的冲突事务,其中,所述冲突事务指的是在日志流中,本事务的两个相邻操作之间还夹杂着提交操作,该提交操作所属的待执行事务为冲突事务。在确定了冲突事务后,判断冲突事务中是否存在与所述当前待执行操作相关联的关联对象,若不存在,则所述当前待执行操作与所述冲突事务相容;若存在,则进一步判断冲突事务对关联对象所进行的操作与所述当前待执行操作是否相容,若相容,则将所述当前待执行操作添加至待执行操作队列的尾端;若不相容,则等待冲突事务提交后,再将所述当前待执行操作添加至待执行操作队列的尾端。
在本实施例中,数据库的日志流中记录的操作先后顺序可以直接反映出各个事务的操作在数据库内部执行的先后顺序,而以日志流中的提交操作作为分界线则反映出各个事务操作在数据内部执行的并行度。通过判断单个事务中两个操作之间是否存在其它事务的提交操作为条件来合并操作,并且在夹杂有提交操作时通过判断操作和提交操作对应的事务中涉及的表和操作相容性等策略来尽可能的合并操作,最大限度的合并操作可以有效的提升同步的性能。
下面具体说明步骤(4)的具体实现过程:
步骤4-1:判断所述当前待执行操作所携带的目标提交编号与所述待执行操作队列中最后一个操作所携带的目标提交编号是否相同。
其中,若二者的提交编号相同,则说明二者可以合并执行,执行步骤4-2;若二者的提交编号不相同,则说明二者有可能不能合并执行,执行步骤4-3。
步骤4-2:若提交编号相同,则将所述当前待执行操作添加在所述待执行操作队列的尾部。
在优选的实施例中,将当前待执行操作添加到待执行操作队列后,判断待执行操作队列中已有的操作的数目是否已经达到设定值,若达到设定值,则将待执行操作队列中已有的操作批量入库,以清空待执行操作队列,防止待执行操作队列缓存太多的操作,从而影响到内存的占用。
步骤4-3:若提交编号不相同,则依次提取两个目标提交编号中的冲突事务。
在本实施例中,若二者的提交编号不相同,则说明二者有可能不能合并执行,需要继续判断当前待执行操作与两个操作之间的冲突事务是否相容。因此,需要先确定两个操作之间的冲突事务,具体方式为依次提取两个目标提交编号中的冲突事务,其中,两个目标提交编号可能只相差1,则只存在一个冲突事务,两个目标提交编号可能相差2、3或更大值,则相应的存在2个、3个或更多个冲突事务,需要获取全部的冲突事务,然后,依次判断当前待执行操作与冲突事务是否相容。
在本实施例中,在执行线程链表中登记有提交操作的日志序列号和提交操作的提交编号,获取位于两个目标提交编号中之间的冲突事务的提交编号,基于获取到的冲突事务的提交编号,从所述执行线程链表中获取冲突事务的提交操作的日志序列号,进而确定冲突事务。
在本实施例中,一个事务在日志流中任意两个操作之间涉及的冲突事务,如果冲突事务所涉及的对象和当前待执行操作所涉及的对象不冲突的情况下,这两个操作就可以合并。由于提交编号是采用顺序递增方式来进行的,那么通过计算出两个操作中的提交编号中间间隔的全部提交编号便可以找到对应的事务。
步骤4-4:判断在所述冲突事务中是否存在与所述当前待执行操作相关联的关联对象。
在获取到冲突事务后,获取所述冲突事务所包含的全部操作的操作对象,判断所述当前待执行操作所涉及的对象与前述获取到的操作对象是否存在关联,以判断在所述冲突事务中是否存在与所述当前待执行操作相关联的关联对象。
若不存在关联对象,则执行步骤4-5;若存在关联对象,则执行步骤4-6。
步骤4-5:若不存在关联对象,则将所述当前待执行操作添加在所述待执行操作队列的尾部。
步骤4-6:若存在关联对象,则判断所述冲突事务对所述关联对象所进行的操作,与所述当前待执行操作是否相容,以确定是否可以进行操作合并。
在本实施例中,若存在关联对象,则需要结合当前待执行操作和冲突事务对关联对象所进行的操作的类型,判断所述冲突事务与所述当前待执行操作是否相容。具体的规则,如下述步骤4-7和步骤4-9。
步骤4-7:若所述冲突事务和所述当前待执行操作对所述关联对象均进行***操作或删除操作,则所述冲突事务和所述当前待执行操作相容。
步骤4-8:将所述当前待执行操作添加在所述待执行操作队列的尾部。
步骤4-9:若所述冲突事务和所述当前待执行操作对所述关联对象均进行更新操作,或,所述冲突事务对所述关联对象进行的操作的操作类型与所述当前待执行操作的操作类型不同,则所述冲突事务和所述当前待执行操作不相容。
其中,在本步骤中,操作类型包括:***操作、删除操作和更新操作,例如,其中一个对关联对象进行***操作,而另一个对关联对象进行删除操作或更新操作,那么二者不相容;其中一个对关联对象进行删除操作,而另一个对关联对象进行***操作或更新操作,那么二者不相容。
步骤4-10:以批量执行的方式清空所述待执行操作队列中已有的操作。
步骤4-11:等待所述冲突事务提交后,将所述当前待执行操作添加在所述待执行操作队列的尾部。
在本实施例中,当冲突事务与当前待执行操作不相容时,当前待执行操作与待执行操作队列中已有的操作不能一起合并执行,需要以批量执行的方式清空所述待执行操作队列中已有的操作。
然后,等待所述冲突事务提交后,将所述当前待执行操作添加在所述待执行操作队列的尾部。
将该当前待执行操作添加到待执行操作队列后,再从待执行事务中取出下一个待执行操作,按照前述方式进行操作合并执行。
在本发明中,操作合并的原理主要是:通过判断需要合并的两个相同的操作在日志流所处位置的中间是否夹杂有提交操作,如果没有则合并;如果有再进一步判断当前操作涉及的表是否和两个操作中间提交的事务中涉及的表相冲突,如果存在冲突,则利用操作相容的规则来判定这两个操作是否可以合并执行。
实施例4:
请参阅图4,图4是本发明实施例提供的一种同步装置的结构示意图。本实施例的同步装置包括一个或多个处理器41以及存储器42。其中,图4中以一个处理器41为例。
处理器41和存储器42可以通过总线或者其他方式连接,图4中以通过总线连接为例。
存储器42作为一种基于双向同步方法的非易失性计算机可读存储介质,可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块,上述实施例的方法以及对应的程序指令。处理器41通过运行存储在存储器42中的非易失性软件程序、指令以及模块,从而执行各种功能应用以及数据处理,实现前述实施例的方法。
其中,存储器42可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中,存储器42可选包括相对于处理器41远程设置的存储器,这些远程存储器可以通过网络连接至处理器41。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
值得说明的是,上述装置和***内的模块、单元之间的信息交互、执行过程等内容,由于与本发明的处理方法实施例基于同一构思,具体内容可参见本发明方法实施例中的叙述,此处不再赘述。
本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:只读存储器(Read Only Memory,简写为ROM)、随机存取存储器(RandomAccessMemory,简写为RAM)、磁盘或光盘等。
本领域的技术人员容易理解,以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等,均应包含在本发明的保护范围之内。