数据处理方法及装置转让专利

申请号 : CN201810800450.7

文献号 : CN109145060B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 吴夏潘安群雷海林

申请人 : 腾讯科技(深圳)有限公司

摘要 :

本发明涉及互联网技术领域,尤其涉及一种数据处理方法及装置,预先设置了生产者模块和表存储模块,从MySQL集群的从服务器中确定一冷备服务器,通过冷备服务器的生产者模块解析binlog文件获得binlog解析数据,通过分析binlog解析数据获取表结构信息,并存入表存储模块,在输出消息实体时,将binlog解析数据和表存储模块内对应的表结构信息一起封装成消息实体并输出。本发明方案以旁路方式获取及解析binlog文件,不增加MySQL集群负担,确保了数据的完整性,同时丰富了数据的内容。

权利要求 :

1.一种数据处理方法,其特征在于,包括:

根据MySQL集群的主服务器和从服务器中存储的数据,将与所述主服务器存储数据最接近的从服务器作为冷备服务器;

从所述冷备服务器获取二进制日志binlog文件,并对所述二进制日志binlog文件进行解析,获得binlog解析数据;

根据所述binlog解析数据获取所述二进制日志binlog文件的表结构信息,根据获取的表结构信息对表存储模块内存储的所述二进制日志binlog文件的表结构信息进行更新;

根据所述binlog解析数据和所述表存储模块中对应的表结构信息生成消息实体。

2.根据权利要求1所述的方法,其特征在于,所述根据所述binlog解析数据获取所述二进制日志binlog文件的表结构信息包括:判断所述binlog解析数据是否包含DDL语句;

如果所述binlog解析数据包含DDL语句,则根据所述DDL语句获取所述二进制日志binlog文件的表结构信息,并根据获取的表结构信息对表存储模块中存储的所述二进制日志binlog文件的表结构信息进行更新;

如果所述binlog解析数据不包括DDL语句,则判定所述二进制日志binlog文件的表结构信息与所述表存储模块中存储的所述二进制日志binlog文件的表结构信息相同。

3.根据权利要求2所述的方法,其特征在于,所述根据所述DDL语句获取所述二进制日志binlog文件的表结构信息包括:解析所述DDL语句获得库表名;

向结构信息库发送重放请求,所述重放请求包括库表名和DDL语句;

接收结构信息库返回的所述二进制日志binlog文件的表结构信息,所述表结构信息包括库表名和表结构数据。

4.根据权利要求1所述的方法,其特征在于,所述根据所述binlog解析数据和所述表存储模块中所述二进制日志binlog文件的表结构信息生成消息实体之后,还包括:将所述消息实体发送给消息集群,所述消息集群用于存储消息实体。

5.根据权利要求1所述的方法,其特征在于,所述对所述二进制日志binlog文件进行解析,获得binlog解析数据之前,还包括:根据获取的二进制日志binlog文件判断是否存在二进制日志binlog文件缺失;

如果存在二进制日志binlog文件缺失,则向分布式协调服务器集群发送补偿请求,所述补偿请求用于触发分布式协调服务器创建补偿节点,并在所述补偿节点中写入补偿信息;

判断所述补偿节点是否被处理;

如果所述补偿节点已被处理,则执行对所述二进制日志binlog文件进行解析,获得binlog解析数据的步骤。

6.根据权利要求5所述的方法,其特征在于,所述根据获取的二进制日志binlog文件判断是否存在二进制日志binlog文件缺失包括:提取本次获取的二进制日志binlog文件的事务ID;

判断本次获取的二进制日志binlog文件的事务ID与上次获取的二进制日志binlog文件的事务ID是否连续;

如果事务ID是连续的,则判定不存在二进制日志binlog文件缺失;

如果事务ID不连续,则判定存在二进制日志binlog文件缺失。

7.一种数据处理方法,其特征在于,包括:

获取分布式协调服务器集群上补偿节点中的补偿信息,所述补偿信息包括MySQL集群的识别码和IP地址;

根据所述IP地址判断是否存在与所述补偿信息对应的补偿任务;

如果存在补偿任务,则根据所述MySQL集群的识别码,从消息集群中获取与所述MySQL集群对应的最新的消息实体;

根据获取的所述消息实体,从主服务器获取二进制日志binlog文件;

对所述二进制日志binlog文件进行解析,获得binlog解析数据;

根据所述binlog解析数据获取所述二进制日志binlog文件的表结构信息,根据获取的表结构信息对表存储模块内存储的所述二进制日志binlog文件的表结构信息进行更新;

根据所述binlog解析数据和所述表存储模块中对应的表结构信息生成消息实体;

将处理获得的消息实体发送至消息集群,并向所述分布式协调服务器集群发送修改请求,所述修改请求用于触发分布式协调服务器集群删除所述补偿节点。

8.根据权利要求7所述的方法,其特征在于,所述根据所述IP地址判断是否存在与所述补偿信息对应的补偿任务包括:判断所述补偿信息中的IP地址与自身IP地址是否相同;

如果所述补偿信息中的IP地址与自身IP地址相同,则判定存在与所述补偿信息对应的补偿任务;

如果补偿信息中的IP地址与自身IP地址不相同,则判定不存在与所述补偿信息对应的补偿任务。

9.根据权利要求7所述的方法,其特征在于,所述根据获取的所述消息实体,从主服务器获取二进制日志binlog文件包括:对所述消息实体进行解析,获得事务ID和事务ID偏移量;

根据所述事务ID和事务ID偏移量,确定待获取二进制日志binlog文件的事务ID;

根据所述待获取二进制日志binlog文件的事务ID,从主服务器获取二进制日志binlog文件。

10.一种数据处理装置,其特征在于,包括:

冷备服务器确定单元,用于根据MySQL集群的主服务器和从服务器中存储的数据,将与所述主服务器存储数据最接近的从服务器作为冷备服务器;

binlog解析单元,用于从所述冷备服务器获取二进制日志binlog文件,并对所述二进制日志binlog文件进行解析,获得binlog解析数据;

表结构信息更新单元,用于根据所述binlog解析数据获取所述二进制日志binlog文件的表结构信息,根据获取的表结构信息对表存储模块内存储的所述二进制日志binlog文件的表结构信息进行更新;

消息实体生成单元,用于根据所述binlog解析数据和所述表存储模块中对应的表结构信息生成消息实体。

11.一种数据处理装置,其特征在于,包括:

第一获取单元,用于获取分布式协调服务器集群上补偿节点中的补偿信息,所述补偿信息包括MySQL集群的识别码和IP地址;

判断单元,用于根据所述IP地址判断是否存在与所述补偿信息对应的补偿任务;

第二获取单元,用于在存在补偿任务时,根据所述MySQL集群的识别码,从消息集群中获取与所述MySQL集群对应的最新的消息实体;

第三获取单元,用于根据获取的所述消息实体,从主服务器获取二进制日志binlog文件;

处理单元,用于对第三获取单元获取的所述二进制日志binlog文件进行处理,获得消息实体;还用于:对所述二进制日志binlog文件进行解析,获得binlog解析数据;根据所述binlog解析数据获取所述二进制日志binlog文件的表结构信息,根据获取的表结构信息对表存储模块内存储的所述二进制日志binlog文件的表结构信息进行更新;根据所述binlog解析数据和所述表存储模块中对应的表结构信息生成消息实体;

发送单元,用于将处理单元处理获得的消息实体发送至消息集群,并向所述分布式协调服务器集群发送修改请求,所述修改请求用于触发分布式协调服务器集群删除所述补偿节点。

12.一种存储介质,其特征在于,所述存储介质中存储有至少一条指令或者至少一段程序,所述至少一条指令或者至少一段程序由处理器加载并执行以实现如权利要求1-6中任意一项所述的一种数据处理方法或者权利要求7-9中任意一项所述的一种数据处理方法。

说明书 :

数据处理方法及装置

技术领域

[0001] 本发明涉及通信技术领域,尤其涉及一种数据处理方法及装置。

背景技术

[0002] MySQL是一个关系型数据库管理系统,通过将数据保存在不同的表中,而不是将所有数据放在一个大仓库内,加快了数据访问速度并提高了灵活性。为了实现服务器的负载均衡,以及增强数据库系统抵御灾难的能力,MySQL数据库系统,同其他流行的数据库系统一样,也采用了主从同步的架构方式,即:系统中包括一台主服务器和多台从服务器。采用上述架构方式的目的有以下两个方面。首先,可以在主服务器上只实现数据的更新操作,而将数据的查询请求全部发送给从服务器来执行,通过将数据更新与查询分别放在不同的服务器上执行,能够缩短对用户操作的响应时间、提高系统的性能。其次,在主服务器发生故障时,能够将数据库操作请求直接切换到从服务器继续提供服务,可以保证用户业务的稳定运行。
[0003] MySQL利用二进制日志binlog实现主、从服务器数据一致。MySQL系统本身实现了基于binlog-dump协议的二进制日志获取功能,其主要应用场景为MySQL集群内部主服务器与从服务器之间的数据复制,其通信过程如附图1所示,其实现方式具体为:主服务器将执行的数据更新动作写入二进制日志binlog中,在前期从服务器与主服务器通过相关协议握手完毕后,主服务器便会不停的将二进制日志binlog发送给从服务器,从服务器接收二进制日志binlog并应用。
[0004] 在数据订阅的应用中,主要思路也是通过binlog-dump协议来获取binlog事件数据,具体应用请参见图2,利用MySQL系统本身可实现基于binlog-dump协议的二进制日志获取功能这一特点,采用binlog-dump协议伪装成从服务器向MySQL发起请求来获取binlog事件数据,之后再解析处理成其本身业务场景可用的数据格式,将解析数据存储于订阅端供第三方订阅。然而,通过binlog-dump协议获取的binlog事件数据,无法获得表结构信息;并且,这种通过binlog-dump协议获取binlog的方式,需要MySQL向外发送数据,增加了MySQL的负担;此外,若MySQL执行了binlogpurge等删除binlog相关的操作,订阅端还会发生数据缺失的情况。

发明内容

[0005] 针对现有技术的上述问题,本发明的目的在于提供一种数据处理方法及装置。
[0006] 第一方面,本发明提供一种数据处理方法,包括:
[0007] 根据MySQL集群的主服务器和从服务器中存储的数据,将与所述主服务器存储数据最接近的从服务器作为冷备服务器;
[0008] 从所述冷备服务器获取二进制日志binlog文件,并对所述二进制日志binlog文件进行解析,获得binlog解析数据;
[0009] 根据所述binlog解析数据获取所述二进制日志binlog文件的表结构信息,根据获取的表结构信息对表存储模块内存储的所述二进制日志binlog文件的表结构信息进行更新;
[0010] 根据所述binlog解析数据和所述表存储模块中对应的表结构信息生成消息实体。
[0011] 第二方面,本发明提供一种数据处理方法,包括:
[0012] 获取分布式协调服务器集群上补偿节点中的补偿信息,所述补偿信息包括MySQL集群的识别码;
[0013] 判断是否存在与所述补偿信息对应的补偿任务;
[0014] 如果存在补偿任务,则根据所述MySQL集群的识别码,从消息集群中获取与所述MySQL集群对应的最新的消息实体;
[0015] 根据获取的所述消息实体,从主服务器获取二进制日志binlog文件;
[0016] 对所述二进制日志binlog文件进行处理,获得消息实体;
[0017] 将处理获得的消息实体发送至消息集群,并向所述分布式协调服务器集群发送修改请求,所述修改请求用于触发分布式协调服务器集群删除所述补偿节点。
[0018] 第三方面,本发明还提供一种数据处理装置,包括:
[0019] 冷备服务器确定单元,用于根据MySQL集群的主服务器和从服务器中存储的数据,将与所述主服务器存储数据最接近的从服务器作为冷备服务器;
[0020] binlog解析单元,用于从所述冷备服务器获取二进制日志binlog文件,并对所述二进制日志binlog文件进行解析,获得binlog解析数据;
[0021] 表结构信息更新单元,用于根据所述binlog解析数据获取所述二进制日志binlog文件的表结构信息,根据获取的表结构信息对表存储模块内存储的所述二进制日志binlog文件的表结构信息进行更新;
[0022] 消息实体生成单元,用于根据所述binlog解析数据和所述表存储模块中对应的表结构信息生成消息实体。
[0023] 第四方面,本发明还提供一种数据处理装置,包括:
[0024] 第一获取单元,用于获取分布式协调服务器集群上补偿节点中的补偿信息,所述补偿信息包括MySQL集群的识别码;
[0025] 判断单元,用于判断是否存在与所述补偿信息对应的补偿任务;
[0026] 第二获取单元,用于在存在补偿任务时,根据所述MySQL集群的识别码,从消息集群中获取与所述MySQL集群对应的最新的消息实体;
[0027] 第三获取单元,用于根据获取的所述消息实体,从主服务器获取二进制日志binlog文件;
[0028] 处理单元,用于对第三获取单元获取的所述二进制日志binlog文件进行处理,获得消息实体;
[0029] 发送单元,用于将处理单元处理获得的消息实体发送至消息集群,并向所述分布式协调服务器集群发送修改请求,所述修改请求用于触发分布式协调服务器集群删除所述补偿节点。
[0030] 第五方面,本发明还提供一种计算机可读存储介质,所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现上述第一方面所述的数据处理方法。
[0031] 第六方面,本发明还提供一种计算机可读存储介质,所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集,所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现上述第二方面所述的数据处理方法。
[0032] 本发明具有如下有益效果:
[0033] 本发明为MySQL集群的每个主服务器和从服务器配置一生产者模块,并设置表存储模块,从各个从服务器中确定一冷备服务器,通过冷备服务器的生产者模块解析binlog文件获得binlog解析数据,进而通过分析binlog解析数据获取表结构信息存入表存储模块内,在输出消息实体时,将binlog解析数据和表存储模块内对应的表结构信息一起封装成消息实体并输出。本发明方案以旁路方式获取及解析binlog文件,不增加MySQL集群负担,实现了对MySQL集群零侵入,确保了数据库本身在运行过程中其性能不受影响;通过分析binlog解析数据获得表结构信息,并设置表存储模块统一管理表结构信息,实现了binlog文件的表结构信息的准确可查,同时输出的消息实体增加了表结构信息,丰富了数据的内容。

附图说明

[0034] 为了更清楚地说明本发明实施例或现有技术中的技术方案和优点,下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它附图。
[0035] 图1是MySQL集群内部主服务器与从服务器之间数据通信的示意图;
[0036] 图2是现有技术中利用binlog-dump协议处理订阅数据的原理示意图;
[0037] 图3是本发明实施例提供的数据处理方法的拓扑图;
[0038] 图4是本发明实施例提供的一种数据处理方法的流程示意图;
[0039] 图5是本发明实施例提供的一种数据处理方法的流程示意图;
[0040] 图6是本发明实施例提供的一种数据处理方法中各装置交互的示意图;
[0041] 图7是本发明实施例提供的另一种数据处理方法的流程示意图;
[0042] 图8是本发明实施例提供的一种数据处理方法中各装置交互的示意图;
[0043] 图9是本发明实施例提供的一种数据处理装置的结构示意图;
[0044] 图10是本发明实施例提供的一种数据处理装置的结构示意图;
[0045] 图11是本发明实施例提供的一种服务器的结构示意图。

具体实施方式

[0046] 为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述。
[0047] 需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
[0048] 现有的基于MySQL集群的数据订阅技术中,一般是利用MySQL系统本身可实现的基于binlog-dump协议的二进制日志获取功能,采用binlog-dump协议伪装成从服务器向MySQL发起请求来获取binlog事件数据,然后将binlog事件数据解析成其本身业务场景可用的数据格式。但是这种方案存在如下缺陷:
[0049] (1)若MySQL执行了binlogpurge等删除binlog相关的操作,则订阅端会发生数据的缺失。
[0050] Binlogpurge操作的作用是删除部分binlog文件,由于订阅端的数据来源为binlog文件,因此删除binlog文件会造成订阅端的数据缺失,即便是订阅端感知到了binlog文件有缺失,也无法弥补缺失的数据,因为binlog-dump协议无法获取其他机器上的数据。
[0051] (2)从binlog-dump协议获取的binlog事件数据中无法获得表结构信息。
[0052] 根据binlog时间中的信息,无法获得该事件发生时,对应表的表结构信息。即便在以行格式(row)记录的binlog事件中包含描述表结构信息的table map event,但是由于时间差的关系以及该事件只能得到表名称信息的特点,在获取到该事件时,表结构也许已经发生了改变,因此无法得到正确的表结构信息。
[0053] (3)采用binlog-dump协议对MySQL本身有一定的侵入性。
[0054] 由于采用binlog-dump协议,最终是由MySQL本身向外界发送binlog数据,因此在一定程度上增加了MySQL本身的负担。
[0055] 针对现有技术的缺陷,本发明提供了一种数据处理方案,其预先为MySQL集群的每个主服务器和从服务器分别配置一生产者模块,并设置表存储模块,构建数据处理装置,然后从各个从服务器中确定一冷备服务器,通过冷备服务器的生产者模块解析binlog文件获得binlog解析数据,进而通过分析binlog解析数据获取表结构信息存入表存储模块内,在输出消息实体时,将binlog解析数据和表存储模块内对应的表结构信息一起封装成消息实体并输出。该方案以旁路方式获取及解析binlog文件,实现了对MySQL集群零侵入,确保了数据库本身在运行过程中其性能不受影响,其输出的消息实体增加了表结构信息,丰富了数据的内容。此外,在发现binlog文件缺失时,还可以借助主服务器的生产者模块获取及解析缺失的binlog文件,确保数据的完整性,并增强数据安全性。
[0056] 本发明实施例提供的数据处理方法涉及MySQL集群、数据处理装置、结构信息库、消息集群和分布式协调服务器集群。所述数据处理装置以旁路的形式围绕MySQL集群配置,包括生产者模块(binlogproductor)和表结构模块,所述生产者模块与MySQL集群中的主服务器和从服务器一一对应,即每个主服务器和从服务器各自对应一个生产者模块,所述表结构模块用于存储MySQL集群各实例的表结构信息。
[0057] 所述MySQL集群用于产生二进制日志binlog文件。MySQL集群的主服务器可以实现数据的更新操作,生成更新数据,然后将更新数据编译成二进制日志binlog文件同步给从服务器。本发明方案主要从从服务器获取二进制日志binlog文件,二进制日志binlog文件的事件ID按照连续递增方式设置,如果获取二进制日志binlog文件的事件ID不连续,则说明二进制日志binlog文件出现缺失,此情况下,需要从主服务器获取缺失的二进制日志binlog文件。
[0058] 请参见图6,所述数据处理装置用于:根据MySQL集群的主服务器和从服务器中存储的数据,将与主服务器存储数据最接近的从服务器作为冷备服务器;通过所述冷备服务器的生产者模块从所述冷备服务器获取二进制日志binlog文件,并对所述二进制日志binlog文件进行解析,获得binlog解析数据;判断所述二进制日志binlog文件是否包含DDL语句,如果包含所述DDL语句,则向结构信息库发送重放请求以获取表结构信息,并根据获取的表结构信息对所述表存储模块中对应的表结构信息进行更新,以及根据所述binlog解析数据和所述表存储模块中对应的表结构信息生成消息实体,将所述消息实体发送给消息集群。
[0059] 所述结构信息库用于:根据数据处理装置发送的重放请求重放DDL语句,获得表结构信息,并将所述表结构信息返回给数据处理装置;
[0060] 所述消息集群用于:存储数据处理装置发送的消息实例。
[0061] 请参见图8,所述数据处理装置还用于:在冷备服务器的生产者模块检测到二进制日志binlog文件缺失时,向所述分布式协调服务器集群发送补偿请求;以及通过主服务器的生产者模块读取所述分布式协调服务器集群上的补偿节点,并根据所述补偿节点中的补偿信息对缺失的所述二进制日志binlog文件进行处理;还用于当冷备服务器的生产者模块检测到缺失的所述二进制日志binlog文件处理完成时,通过冷备服务器的生产者模块继续执行处理二进制日志binlog文件的步骤;
[0062] 分布式协调服务器集群用于:根据冷备服务器的生产者模块发送的补偿请求,创建补偿节点,并向所述补偿节点写入补偿信息,所述补偿信息包括处理该补偿信息的主服务器的生产者模块的IP地址和该主服务器所属的MySQL集群的识别码。
[0063] 图3是本发明实施例提供的数据处理方法的拓扑图。请参见图3,生产者模块伴随MySQL进程部署,每个MySQL实例都有各自的独立的生产者进程。生产者模块通过对binlog的解析,将binlog事件转换成消息实体存储在消息集群(分布式消息队列Kafka集群)中供第三方订阅,其中消息的格式为JSON格式的字符串;所述分布式协调服务器集群(ZOOKEEPER集群)与生产者模块通信。
[0064] 以下对本说明书的数据处理方法进行具体说明。
[0065] 本发明实施例提供了一种数据处理方法,图4是本发明实施例提供的一种数据处理方法的流程示意图。本说明书提供了如实施例或流程图所述的方法操作步骤,但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式,不代表唯一的执行顺序。在实际中的系统或服务器产品执行时,可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图4所示,所述方法可以包括:
[0066] S301:根据MySQL集群的主服务器和从服务器中存储的数据,将与所述主服务器存储数据最接近的从服务器作为冷备服务器。
[0067] 在一个具体的实施例中,确定冷备服务器的方法可以包括:
[0068] 获取各从服务器从主服务器中同步的最新数据的第一时间戳;
[0069] 获取主服务器中最新数据的第二时间戳;
[0070] 比较所述第一时间戳和所述第二时间戳,将与第二时间戳最接近的第一时间戳所对应的从服务器作为冷备服务器。
[0071] 其中,时间戳是指一个能表示一份数据在某个特定时间之前已经存在的、完整的、可验证的数据,通常是一个字符序列,用于唯一的标识某一刻的时间。本发明实施例通过时间戳判断从服务器中的数据与主服务器中的数据差距大小,如果从服务器中最新数据的时间戳与主服务器中最新数据的时间戳之间的差值小,证明从服务器同步数据较快,其存储的数据与主服务器中的数据较为接近。选择与主服务器存储数据最接近的从服务器作为冷备服务器的优势在于可以确保获取binlog文件的稳健性。
[0072] S302:从所述冷备服务器获取二进制日志binlog文件,并对所述二进制日志binlog文件进行解析,获得binlog解析数据。
[0073] 具体的,在从冷备服务器获取二进制日志binlog文件之后,需要确定获取的二进制日志binlog文件是否是与上一条获取的二进制日志binlog文件连续的,如果不连续,说明有binlog文件被遗漏,将造成消息集群中存储的消息不完整。请参见图5,在获取到二进制日志binlog文件之后,还包括如下步骤:
[0074] S502:根据获取的二进制日志binlog文件判断是否存在二进制日志binlog文件缺失;
[0075] S503:如果存在二进制日志binlog文件缺失,则向分布式协调服务器集群发送补偿请求,所述补偿请求用于触发分布式协调服务器创建补偿节点,并在所述补偿节点中写入补偿信息;
[0076] S504:判断所述补偿节点是否被处理;
[0077] 如果所述补偿节点已被处理,则执行步骤S505,对所述二进制日志binlog文件进行解析,获得binlog解析数据;如果所述补偿节点未被处理,则返回执行步骤S504;
[0078] 此外,如果不存在二进制日志binlog文件缺失,则执行步骤S505,对所述二进制日志binlog文件进行解析,获得binlog解析数据。
[0079] 其中,两种情况可以定义为二进制日志binlog文件缺失,其一是为无法按照对应的事务ID找到binlog文件,其二是生产的消息在服务器ID相同的情况下不连续。
[0080] 由于二进制日志binlog文件的事务ID的数值是连续递增的,如果出现事务ID的数值不连续,可以判定二进制日志binlog文件缺失。本发明实施例以二进制日志binlog文件的事务ID是否连续来判断binlog文件是否缺失,具体包括如下步骤:
[0081] (1)提取本次获取的二进制日志binlog文件的事务ID;
[0082] (2)判断本次获取的二进制日志binlog文件的事务ID与上次获取的二进制日志binlog文件的事务ID是否连续;
[0083] (3)如果事务ID是连续的,则判定不存在二进制日志binlog文件缺失;
[0084] (4)如果事务ID不连续,则判定存在二进制日志binlog文件缺失。
[0085] 本发明方案在获取到二进制日志binlog文件后,进一步判断binlog文件是否有缺失,在存在缺失的情况下暂停解析binlog文件,直至缺失的binlog文件被处理完成后,再继续执行解析binlog文件的步骤,确保了存入消息集群中的消息实体的有序、完整及正确。
[0086] S303:根据所述binlog解析数据获取所述二进制日志binlog文件的表结构信息,根据获取的表结构信息对表存储模块内存储的所述二进制日志binlog文件的表结构信息进行更新。
[0087] 在一个具体的实施例中,根据所述binlog解析数据获取所述二进制日志binlog文件的表结构信息包括:
[0088] S3031:判断所述binlog解析数据是否包含DDL语句。
[0089] 所述DDL(data definition language)语句是数据定义语言,用于定义和管理MySQL数据库中的所有对象的语言,主要的命令有CREATE、ALTER、DROP等,DDL主要是用在定义或改变表(TABLE)的结构、数据类型、表之间的链接和约束等初始化工作上。而DML(data manipulation language)语句是用来对数据库里的数据进行操作的语言,不会改变表结构信息。因此,本发明实施例通过DDL语句来获取表结构信息。
[0090] S3032:如果所述binlog解析数据包含DDL语句,则根据所述DDL语句获取所述二进制日志binlog文件的表结构信息,并根据获取的表结构信息对表存储模块中存储的所述二进制日志binlog文件的表结构信息进行更新。
[0091] 在一个具体的实施例中,表结构模块在创建时是没有数据的,当冷备服务器确定后,会对表结构模块进行初始化,使表结构模块中存储冷备服务器中binlog文件的表结构信息。具体的,对表结构模块进行初始化包括:
[0092] a)、刷新库表以清除缓存(FLUSH TABLES);
[0093] b)、为库表添加全局读锁定(FLUSH TABLES WITH READ LOCK);
[0094] c)、锁定查询中使用的所有数据(SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ);
[0095] d)、启动事务处理(START TRANSACTION);
[0096] e)、查看数据库当前正在使用的二进制日志及当前执行二进制日志位置(SHOW MASTER STATUS);
[0097] f)、获取表结构信息并存储在表存储模块内;
[0098] g)、解锁库表(UNLOCK TABLE)。
[0099] 在一个具体的实施例中,根据所述DDL语句获取所述二进制日志binlog文件的表结构信息包括:
[0100] 解析所述DDL语句获得库表名;
[0101] 向结构信息库发送重放请求,所述重放请求包括库表名和DDL语句;
[0102] 接收结构信息库返回的所述二进制日志binlog文件的表结构信息,所述表结构信息包括库表名和表结构数据。
[0103] S3033:如果所述binlog解析数据不包括DDL语句,则判定所述二进制日志binlog文件的表结构信息与所述表存储模块中存储的所述二进制日志binlog文件的表结构信息相同。
[0104] 具体的,如果binlog解析数据不包括DDL语句,则binlog解析数据对应的binlog文件的表结构数据没有发生改变,无需对表存储模块中已存储的表结构信息进行更改。
[0105] S304:根据所述binlog解析数据和所述表存储模块中对应的表结构信息生成消息实体。
[0106] 在一个可能的实施方式中,可以根据库表名来匹配binlog解析数据和表结构信息。具体包括:根据所述binlog解析数据包含的库表名,在所述表存储模块中查询获得包含所述库表名的表结构信息;将查询得到的表结构信息与所述binlog解析数据进行封装,获得消息实体。
[0107] 在一个可能的实施方式中,所述步骤S304之后,还包括S305:将所述消息实体发送给消息集群,所述消息集群用于存储消息实体。
[0108] 在一个可能的实施方式中,当另一个从服务器替代当前作为冷备服务器的从服务器,成为新的冷备服务器时,新的冷备服务器的生产者模块需要找到解析二进制日志binlog的起始位置,具体的可以通过以下方法确定:
[0109] 步骤一:读取所述消息集群中与所述MySQL集群对应的最新的消息实体;
[0110] 步骤二:对所述最新的消息实体进行解析,获得事务ID和事务ID偏移量;
[0111] 步骤三:根据所述事务ID和事务ID偏移量,确定解析二进制日志binlog文件的起始位置。可选地,解析二进制日志binlog文件的起始位置可以用binlog文件的事物ID表示,所述最新的消息实体的事务ID和事务ID偏移量相加所得的值为待解析的binlog文件的事物ID。
[0112] 本发明实施例为MySQL集群的每个主服务器和从服务器配置一生产者模块,并设置表存储模块,从各个从服务器中确定一冷备服务器,通过冷备服务器的生产者模块解析binlog文件获得binlog解析数据,进而通过分析binlog解析数据获取表结构信息存入表存储模块内,在输出消息实体时,将binlog解析数据和表存储模块内对应的表结构信息一起封装成消息实体并输出。本发明实施例具有如下有益效果:
[0113] 1、现有技术中,由于binglog文件本身及时间差的问题,往往无法获得准确的表结构信息数据,本发明实施例借助DDL事件重放机制,在消息实体中增加表结构信息,丰富了数据的内容,并使得消息实体中表结构信息准确可靠。
[0114] 2、本发明实施例基于对MySQL集群binlog文件的解析来获取数据,以旁路的方式完成数据处理,不增加MySQL集群负担,实现了对MySQL集群零侵入,确保了数据库本身在运行过程中其性能不受影响。
[0115] 3、当冷备服务器由一个从服务器切换为另一个从服务器时,会确定解析二进制日志binlog文件的起始位置,可以确保处理获得的消息实体的连续性和完整性,避免消息集群中出现重复数据。
[0116] 本发明实施例提供了一种数据处理方法,图7是本发明实施例提供的另一种数据处理方法的流程示意图。请参见图7,所述数据处理方法包括:
[0117] S701:获取分布式协调服务器集群上补偿节点中的补偿信息,所述补偿信息包括MySQL集群的识别码和IP地址。
[0118] S702:根据所述IP地址判断是否存在与所述补偿信息对应的补偿任务。
[0119] 在一个具体的实施方式中,步骤S705可以包括:
[0120] S7021、判断所述补偿信息中的IP地址与自身IP地址是否相同;
[0121] S7022、如果所述补偿信息中的IP地址与自身IP地址相同,则判定存在与所述补偿信息对应的补偿任务;
[0122] S7023、如果补偿信息中的IP地址与自身IP地址不相同,则判定不存在与所述补偿信息对应的补偿任务。
[0123] S703:如果存在补偿任务,则根据所述MySQL集群的识别码,从消息集群中获取与所述MySQL集群对应的最新的消息实体。
[0124] S704:根据获取的所述消息实体,从主服务器获取二进制日志binlog文件。
[0125] 在一个具体的实施方式中,步骤S704可以包括:
[0126] S7041、对所述消息实体进行解析,获得事务ID和事务ID偏移量;
[0127] S7042、根据所述事务ID和事务ID偏移量,确定待获取二进制日志binlog文件的事务ID;可选地,所述待获取二进制日志binlog文件的事务ID的值可以是所述事务ID和事务ID偏移量之和;
[0128] S7043、根据所述待获取二进制日志binlog文件的事务ID,从主服务器获取二进制日志binlog文件。
[0129] S705:对所述二进制日志binlog文件进行处理,获得消息实体。
[0130] 在一个具体的实施方式中,步骤S705可以包括:
[0131] S7051、对所述二进制日志binlog文件进行解析,获得binlog解析数据;
[0132] S7052、根据所述binlog解析数据获取所述二进制日志binlog文件的表结构信息,根据获取的表结构信息对表存储模块内存储的所述二进制日志binlog文件的表结构信息进行更新;
[0133] 在一个具体的实施方式中,所述步骤S7052可以包括:判断所述binlog解析数据是否包含DDL语句;如果所述binlog解析数据包含DDL语句,则根据所述DDL语句获取所述二进制日志binlog文件的表结构信息,并根据获取的表结构信息对表存储模块中存储的所述二进制日志binlog文件的表结构信息进行更新;如果所述binlog解析数据不包括DDL语句,则判定所述二进制日志binlog文件的表结构信息与所述表存储模块中存储的所述二进制日志binlog文件的表结构信息相同。其中,所述根据所述DDL语句获取所述二进制日志binlog文件的表结构信息可以包括:解析所述DDL语句获得库表名;向结构信息库发送重放请求,所述重放请求包括库表名和DDL语句;接收结构信息库返回的所述二进制日志binlog文件的表结构信息,所述表结构信息包括库表名和表结构数据。
[0134] S7053、根据所述binlog解析数据和所述表存储模块中对应的表结构信息生成消息实体。
[0135] S706:将处理获得的消息实体发送至消息集群,并向所述分布式协调服务器集群发送修改请求,所述修改请求用于触发分布式协调服务器集群删除所述补偿节点。
[0136] 在实际的生产环境中,MySQL数据库往往以集群的方式存在,即采用一主N从的方式进行部署,增加系统的可用性。本发明实施例借助了MySQL集群的高可用特性来保证数据的可靠性,当冷备服务器的生产者模块发现binlog文件缺失时,通过主服务器的生产者模块处理缺失的binlog文件,直至缺失的binlog文件被处理完成,冷备服务器的生产者模块才继续执行解析binlog文件的步骤,可以确保消息集群中数据的完整有序及正确。
[0137] 本发明实施例还提供了一种数据处理装置,如图9所示,图9是本发明实施例提供的一种数据处理装置的结构示意图。具体的,所述数据处理装置900可以包括:
[0138] 冷备服务器确定单元901,用于根据MySQL集群的主服务器和从服务器中存储的数据,将与所述主服务器存储数据最接近的从服务器作为冷备服务器;
[0139] binlog解析单元902,用于从所述冷备服务器获取二进制日志binlog文件,并对所述二进制日志binlog文件进行解析,获得binlog解析数据;
[0140] 表结构信息更新单元903,用于根据所述binlog解析数据获取所述二进制日志binlog文件的表结构信息,根据获取的表结构信息对表存储模块内存储的所述二进制日志binlog文件的表结构信息进行更新;
[0141] 消息实体生成单元904,用于根据所述binlog解析数据和所述表存储模块中对应的表结构信息生成消息实体。
[0142] 需要说明的是:上述实施例提供的数据处理装置进行数据处理时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的数据处理装置与上述实施例提供的数据处理方法属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
[0143] 本发明实施例还提供了一种数据处理装置,如图10所示,图10是本发明实施例提供的一种数据处理装置的结构示意图。具体的,所述数据处理装置1000可以包括:
[0144] 第一获取单元1001,用于获取分布式协调服务器集群上补偿节点中的补偿信息,所述补偿信息包括MySQL集群的识别码和IP地址;
[0145] 判断单元1002,用于根据所述IP地址判断是否存在与所述补偿信息对应的补偿任务;
[0146] 第二获取单元1003,用于在存在补偿任务时,根据所述MySQL集群的识别码,从消息集群中获取与所述MySQL集群对应的最新的消息实体;
[0147] 第三获取单元1004,用于根据获取的所述消息实体,从主服务器获取二进制日志binlog文件;
[0148] 处理单元1005,用于对第三获取单元获取的所述二进制日志binlog文件进行处理,获得消息实体;
[0149] 发送单元1006,用于将处理单元处理获得的消息实体发送至消息集群,并向所述分布式协调服务器集群发送修改请求,所述修改请求用于触发分布式协调服务器集群删除所述补偿节点。
[0150] 需要说明的是:上述实施例提供的数据处理装置进行数据处理时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的数据处理装置与上述实施例提供的数据处理方法属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
[0151] 本发明实施例提供了一种数据处理服务器,该数据处理服务器包括处理器和存储器,该存储器中存储有至少一条指令、至少一段程序、代码集或指令集,该至少一条指令、该至少一段程序、该代码集或指令集由该处理器加载并执行以实现如上述方法实施例所提供的数据处理方法。
[0152] 存储器可用于存储软件程序以及模块,处理器通过运行存储在存储器的软件程序以及模块,从而执行各种功能应用以及数据处理。存储器可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、功能所需的应用程序等;存储数据区可存储根据所述设备的使用所创建的数据等。此外,存储器可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地,存储器还可以包括存储器控制器,以提供处理器对存储器的访问。
[0153] 本发明实施例还提供了一种服务器的结构示意图,请参阅图11,该服务器1100用于实施上述实施例中提供的数据处理方法,具体来讲,所述服务器结构可以包括上述数据处理装置。该服务器1100可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上中央处理器(Central Processing Units,CPU)1110(例如,一个或一个以上处理器)和存储器1130,一个或一个以上存储应用程序1123或数据1122的存储介质1120(例如一个或一个以上海量存储设备)。其中,存储器1130和存储介质1120可以是短暂存储或持久存储。存储在存储介质1120的程序可以包括一个或一个以上模块,每个模块可以包括对服务器中的一系列指令操作。更进一步地,中央处理器1110可以设置为与存储介质1120通信,在服务器1100上执行存储介质1120中的一系列指令操作。服务器1100还可以包括一个或一个以上电源1160,一个或一个以上有线或无线网络接口1150,一个或一个以上输入输出接口1140,和/或,一个或一个以上操作系统1121,例如Windows ServerTM,Mac OS XTM,UnixTM,LinuxTM,FreeBSDTM等等。
[0154] 本发明的实施例还提供了一种存储介质,所述存储介质可设置于服务器之中以保存用于实现方法实施例中一种数据处理方法相关的至少一条指令、至少一段程序、代码集或指令集,该至少一条指令、该至少一段程序、该代码集或指令集由该处理器加载并执行以实现上述方法实施例提供的数据处理方法。
[0155] 可选地,在本实施例中,上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地,在本实施例中,上述存储介质可以包括但不限于:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
[0156] 由上述本发明提供的数据处理方法、装置、服务器或存储介质的实施例可见,本发明为MySQL集群的每个主服务器和从服务器配置一生产者模块,并设置表存储模块,从各个从服务器中确定一冷备服务器,通过冷备服务器的生产者模块解析binlog文件获得binlog解析数据,进而通过分析binlog解析数据获取表结构信息存入表存储模块内,在输出消息实体时,将binlog解析数据和表存储模块内对应的表结构信息一起封装成消息实体并输出。本发明方案以旁路方式获取及解析binlog文件,不增加MySQL集群负担,实现了对MySQL集群零侵入,确保了数据库本身在运行过程中其性能不受影响;通过分析binlog解析数据获得表结构信息,并设置表存储模块统一管理表结构信息,实现了binlog文件的表结构信息的准确可查,同时输出的消息实体增加了表结构信息,丰富了数据的内容。
[0157] 本发明方案可用于数据订阅,可以提升数据订阅的可靠性和可用性,可用于以下场景:
[0158] (1)多中心数据同步及分发:多个数据中心的数据准实时同步,实现一对多的拓扑结构。
[0159] (2)异构索引:在多个数据节点数据同步的基础上,根据业务需求采用不同的索引结构,优化查询效率。
[0160] (3)准实时数据备份:实现多中心的数据同步及备份。
[0161] 需要说明的是:上述本发明实施例先后顺序仅仅为了描述,不代表实施例的优劣。且上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
[0162] 本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于装置和服务器实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
[0163] 本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
[0164] 以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。