CN114048217A - 增量数据的同步方法和装置、电子设备和存储介质 - Google Patents

Abstract

本申请提供了一种增量数据的同步方法和装置、电子设备和存储介质，其中，该方法包括：在确定源端的目标业务系统内的目标子业务被更新的情况下，获取被更新时产生的增量数据对应的操作记录；将操作记录按照关联信息的分类分别发送至分布式消息队列的各个主题分区中；利用流式处理引擎提取主题分区中的操作记录进行消费，并将消费后的操作记录写入第二数据库内，得到操作记录排序队列；利用流式处理引擎读取第二数据库内存放的操作记录排序队列，并将操作记录排序队列对应的增量数据发送至目标端，使得目标端完成增量数据的同步。通过本申请，解决了相关技术中存在的源端和目标端的增量数据同步不准确的问题。

Description

增量数据的同步方法和装置、电子设备和存储介质

技术领域

本申请涉及数据处理领域，尤其涉及一种增量数据的同步方法和装置、电子设备和存储介质。

背景技术

目前，存在一些源端数据库和目标端数据库中存储的数据需要达成同步的场景，常见的数据同步方式为数据库的增量数据同步，增量数据，顾名思义，指新增加的数据。其中，在一种关系型数据库的增量同步中，一般要求传输源端数据库的操作记录到目标端，并利用消息队列来实现操作记录数据的削峰填谷，保证吞吐量。

然而在多数据源，多表，大数据量的场景下，消息队列需要开启多分区特性，消费者从不同分区中读取消息的速度不一致，那么就会导致传达到目标端的数据库操作记录顺序不一致，比如，操作记录为先删除再插入的顺序，如果反了则会丢失后面插入的数据，源端和目标端的数据将会出现偏差。因此消息队列的消费不能保证消息的全局有序性，致使增量同步目标端数据不准确。

因此，相关技术中存在源端数据和目标端数据的增量数据同步不准确的问题。

发明内容

本申请提供了一种增量数据的同步方法和装置、电子设备和存储介质，以至少解决相关技术中存在源端数据和目标端数据的增量数据同步不准确的问题。

根据本申请实施例的一个方面，提供了一种增量数据的同步方法，该方法包括：

在确定源端的目标业务系统内的目标子业务被更新的情况下，获取被更新时产生的增量数据对应的操作记录，其中，所述目标业务系统内包含多个子业务，所述操作记录用于表征所述增量数据产生时对应的多个关联信息，所述关联信息包含时间戳；

将所述操作记录按照所述关联信息的分类分别发送至分布式消息队列的各个主题分区中；

利用流式处理引擎提取所述主题分区中的所述操作记录进行消费，并将消费后的所述操作记录写入第二数据库内，得到操作记录排序队列，其中，所述第二数据库按照预设格式将所述消费后的所述操作记录进行存放，所述操作记录排序队列是依据所述时间戳的先后次序对所述消费后的所述操作记录进行排序后生成的队列；

利用所述流式处理引擎读取所述第二数据库内存放的所述操作记录排序队列，并将所述操作记录排序队列对应的所述增量数据发送至目标端，使得所述目标端完成所述增量数据的同步。

根据本申请实施例的另一个方面，还提供了一种增量数据的同步装置，该装置包括：

第一获取单元，用于在确定源端的目标业务系统内的目标子业务被更新的情况下，获取被更新时产生的增量数据对应的操作记录，其中，所述目标业务系统内包含多个子业务，所述操作记录用于表征所述增量数据产生时对应的多个关联信息，所述关联信息包含时间戳；

第一发送单元，用于将所述操作记录按照所述关联信息的分类分别发送至分布式消息队列的各个主题分区中；

得到单元，用于利用流式处理引擎提取所述主题分区中的所述操作记录进行消费，并将消费后的所述操作记录写入第二数据库内，得到操作记录排序队列，其中，所述第二数据库按照预设格式将所述消费后的所述操作记录进行存放，所述操作记录排序队列是依据所述时间戳的先后次序对所述消费后的所述操作记录进行排序后生成的队列；

第二发送单元，用于利用所述流式处理引擎读取所述第二数据库内存放的所述操作记录排序队列，并将所述操作记录排序队列对应的所述增量数据发送至目标端，使得所述目标端完成所述增量数据的同步。

根据本申请实施例的又一个方面，还提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器、通信接口和存储器通过通信总线完成相互间的通信；其中，存储器，用于存储计算机程序；处理器，用于通过运行所述存储器上所存储的所述计算机程序来执行上述任一实施例中的增量数据的同步方法步骤。

根据本申请实施例的又一个方面，还提供了一种计算机可读的存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一实施例中的增量数据的同步方法步骤。

根据本申请实施例的又一个方面，还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中；计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一实施例中的增量数据的同步方法步骤。

在本申请实施例中，采用增量数据的同步的方式，通过在确定源端的目标业务系统内的目标子业务被更新的情况下，获取被更新时产生的增量数据对应的操作记录，其中，目标业务系统内包含多个子业务，操作记录用于表征增量数据产生时对应的多个关联信息，关联信息包含时间戳；将操作记录按照所述关联信息的分类分别发送至分布式消息队列的各个主题分区中；利用流式处理引擎提取主题分区中的操作记录进行消费，并将消费后的操作记录写入第二数据库内，得到操作记录排序队列，其中，第二数据库按照预设格式将消费后的操作记录进行存放，操作记录排序队列是依据时间戳的先后次序对消费后的操作记录进行排序后生成的队列；利用流式处理引擎读取第二数据库内存放的操作记录排序队列，并将操作记录排序队列对应的增量数据发送至目标端，使得目标端完成增量数据的同步。由于本申请实施例利用目标子业务被更新时产生的增量数据对应的操作记录，将这些操作记录记录在第二数据库内，利用第二数据库作为增量同步操作记录的中转存储介质，并通过第二数据库基于操作记录对应的时间戳的先后次序对这些操作记录进行自动排序，这样在处理引擎读取排序好的操作记录，并发送其对应的增量数据至目标端时，保证了消息的先后顺序，实现了从源端到目标端增量数据同步的次序准确性，进而解决了相关技术中源端和目标端的增量数据同步不准确的问题。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

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

图1是根据本申请实施例的一种可选的增量数据的同步方法的流程示意图；

图2是根据本申请实施例的一种可选的增量数据的同步方法的整体流程示意图；

图3是根据本申请实施例的一种可选的增量数据的同步装置的结构框图；

图4是根据本申请实施例的一种可选的电子设备的结构框图。

具体实施方式

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

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

为了解决由源端到目标端中增量数据同步不准确的问题，相关技术1：基于mysql自增列做同步，每次同步都缓存当前自增长字段从哪个数开始，字段一次递增多少，然后再将sql查询的结果数据取出来批量导入到目标端。但是该方法过于依赖表中的数据，对于无自增列的场景无法适用，比如以用户清洗加密后的ID作为唯一主键的表单的场景，或者业务在配置表单之初没有添加自增列的表单的场景。

相关技术2：短暂停业务，导出源端数据到目标端，等目标端追平源端数据后，采取双写模式，并定时校验两边数据。但是该方法涉及的双写模式只适用业务简单的场景，对于核心的，复杂的业务，显然无法去停业务等待追平。

相关技术3：解析mysql Binlog日志，恢复成对目标数据库表的变更记录，并在目标端表中重复执行此变更操作。但是该方法对应的流式解析Binlog日志并在目标端表中重复执行Binlog中的变更操作，在利用kafka作为消息队列时，为了尽量保证顺序一致，只能写入一个kafka partition，消费者也只能从一个partition读取，大大削弱了kafka分散负载的能力。由于源端的业务量不一，容易出现partition分配不均，消息队列阻塞，消费者过载的情况。

基于上述相关技术存在的缺陷，本申请实施例提供一种增量数据的同步方法，如图1所示，该方法应用于后台服务器，该方法包括：

步骤S101，在确定源端的目标业务系统内的目标子业务被更新的情况下，获取被更新时产生的增量数据对应的操作记录，其中，目标业务系统内包含多个子业务，操作记录用于表征增量数据产生时对应的多个关联信息，关联信息包含时间戳。

可选地，在本申请实施例中，首先确定进行数据同步的源端，每个源端是由目标业务系统组成，而目标业务系统内又包含多个子业务，其中，在后台服务器获取到源端的目标子业务被更新的情况下，说明这时会产生增量数据，这时，获取到目标子业务被更新时产生的增量数据所对应的操作记录，该操作记录内存储有多个与该增量数据相关的关联信息，比如时间戳、数据库操作类型等。

步骤S102，将操作记录按照关联信息的分类分别发送至分布式消息队列的各个主题分区中。

可选地，将这些操作记录同步发送至分布式消息队列，比如kafka中，需要说明的是，本申请实施例在选择分布式消息队列为kafka时，kafka的使用场景之一就是解耦生产者和消费者，生产者和消费者不再直接接触，其可以进行主题的分区，也即在kafka文件存储中，同一个主题下有多个不同分区，这时，可以基于操作记录内关联信息所对应的业务场景分类将操作记录分别发送至kafka的各个主题分区中。

步骤S103，利用流式处理引擎提取主题分区中的操作记录进行消费，并将消费后的操作记录写入第二数据库内，得到操作记录排序队列，其中，第二数据库按照预设格式将消费后的操作记录进行存放，操作记录排序队列是依据时间戳的先后次序对消费后的操作记录进行排序后生成的队列。

可选地，使用流式处理引擎，比如Flink，Spark Streaming等，提取各个主题分区中的操作记录进行消费，然后将消费后的操作记录写入第二数据库内，比如Hbase数据库，然后基于数据库的特性，实现操作记录的排序，得到操作记录排序队列。其中，Hbase数据库是一个分布式的、面向列的开源数据库，它是分布式的，擅长处理大数据；本申请实施例使用Flink作为流式处理引擎。

其中，可以理解的是，流式处理引擎以及kafka队列通常应用在生产者和消费者之间进行消息生产和消息消费的场景中，操作记录排序队列也是依据操作记录内记载的时间戳的先后次序进行排序后生成的队列，另外，Hbase数据库存在自身的表结构，这时，将操作记录记录在Hbase数据库中，需要按照表结构的预设格式进行存放。

步骤S104，利用流式处理引擎读取第二数据库内存放的操作记录排序队列，并将操作记录排序队列对应的增量数据发送至目标端，使得目标端完成增量数据的同步。

可选地，第二数据库(即Hbase数据库)中已存放好排序完成的操作记录，本申请实施例的后台服务器将启动流式处理引擎再次读取第二数据库内的操作记录排序队列，逐次消费操作记录排序队列内的操作记录，将读取出的增量数据发送至目标端的数据库，进行同步写入，最终使得目标端完成增量数据的同步。同时，Flink每消费一个操作记录后即可清空此操作记录在Hbase中存储的对应数据。

在本申请实施例中，采用增量数据的同步的方式，通过在确定源端的目标业务系统内的目标子业务被更新的情况下，获取被更新时产生的增量数据对应的操作记录，其中，目标业务系统内包含多个子业务，操作记录用于表征增量数据产生时对应的多个关联信息，关联信息包含时间戳；将操作记录发送至分布式消息队列的各个主题分区中；利用流式处理引擎提取主题分区中的操作记录进行消费，并将消费后的操作记录写入第二数据库内，得到操作记录排序队列，其中，第二数据库按照预设格式将消费后的操作记录进行存放，操作记录排序队列是依据时间戳的先后次序对消费后的操作记录进行排序后生成的队列；利用流式处理引擎读取第二数据库内存放的操作记录排序队列，并将操作记录排序队列对应的增量数据发送至目标端，使得目标端完成增量数据的同步。由于本申请实施例利用目标子业务被更新时产生的增量数据对应的操作记录，将这些操作记录记录在第二数据库内，利用第二数据库作为增量同步操作记录的中转存储介质，并通过第二数据库基于操作记录对应的时间戳的先后次序对这些操作记录进行自动排序，这样在处理引擎读取排序好的操作记录，并发送其对应的增量数据至目标端时，保证了消息的先后顺序，实现了从源端到目标端增量数据同步的次序准确性，进而解决了相关技术中源端和目标端的增量数据同步不准确的问题。

作为一种可选实施例，获取被更新时产生的增量数据对应的操作记录包括：

获取目标业务系统内的第一数据库，其中，第一数据库内存储有目标子业务更新后的增量数据；

对第一数据库内存储的增量数据进行实例化配置，得到可读取数据；

获取可读取数据对应的操作记录。

可选地，数据库用于记录业务系统对数据库内存储的数据执行的一些操作，这时，本申请实施例需要获取到源端目标业务系统中的第一数据库，其中，该第一数据库可以为mysql数据库，第一数据库内存储有目标子业务更新后的增量数据以及更新前的原始数据。

这时，为了从mysql数据库中读取出需要的增量数据，这时需要对增量数据进行实例化配置，才能得到可读取数据，然后再基于可读取数据找到其对应的一些操作记录。

在本申请实施例中，由于所有的数据更新都是在数据库中获取或执行的，这时，为了得到可读数据，需要对数据库进行实例化，这时才能从内存中读取出增量数据，而此时的增量数据是可读的、可操作的，然后再进行操作记录的对应查找，获取准确的增量数据。

作为一种可选实施例，获取可读取数据对应的操作记录包括：

将可读取数据转换为二进制日志文件，其中，二进制日志文件用于记录第一数据库内存储的已更新数据和待更新数据；

根据解析工具解析二进制日志文件，得到目标子业务被更新时执行的操作记录。

可选地，目标业务系统中的目标子业务对数据库的操作都会转存为二进制的日志文件，比如Binlog日志文件，二进制日志文件记录有第一数据库内存储的已更新数据和待更新数据，也即，只要第一数据库内出现数据更新，就可以转存为二进制日志文件。

然后通过数据库操作记录解析工具(比如xxxx的canal开源解析工具)解析Binlog日志文件，生成对库表的操作记录。

以下是操作记录的示例：

//UPDATE

{"data":[{"id":"29","order_id":"291029","amount":"281727.39","create_time":"2020-09-2503:17:59"}],"database":"testbase","es":1600975079000,"id":4,"isDdl":false,"mysqlType":{"id":"BIGINT","order_id":"VARCHAR(64)","amount":"DECIMAL(10,2)","create_time":"DATETIME"},"old":[{"amount":"666.0"}],"pkNames":["id"],"sql":"","sqlType":{"id":-5,"order_id":12,"amount":3,"create_time":93},"table":"order","ts":1600975179000,"type":"UPDATE"}。

其中，data：此处包含修改后的数据，也就是表结构字段的key和value；id：识别码；order_id：识别码次序；amount：总数；create_time：创建时间；database：Binlog日志(即二进制日志)对应的库名；es：Binlog的执行时间戳，可以是毫秒级的；database中的id：Binlog的附属识别码；isDdl：是否是ddl语句；mysqlType：表结构；old：未修改前字段的值；pkNames：主键字段名；sql，sqltype：解析还原的sql指令原文和分类；table：表名；ts：解析时的时间戳，可以是毫秒级的；type：数据库操作类型。需要说明的是本申请各实施例中id(ID)的含义均是识别码。

在本申请实施例中通过将可读取数据转换为二进制日志文件，并根据解析工具解析二进制日志文件，得到目标子业务被更新时执行的操作记录，以达到快速获取目标业务系统中的目标子业务对数据库执行的各种操作的目的。

作为一种可选实施例，利用流式处理引擎提取主题分区中的操作记录进行消费，并将消费后的操作记录写入第二数据库内，得到操作记录排序队列包括：

流式处理引擎基于预设关键信息，对主题分区中的操作记录进行消费，得到消费后的操作记录；

获取第二数据库存放数据的预设格式；

将时间戳作为版本号，并按照预设格式将消费后的操作记录写入预设格式对应的预设单元内；

按照版本号的大小顺序，对消费后的操作记录排序，得到操作记录排序队列。

可选地，本申请实施例在利用Flink去批量消费各个主题分区中的操作记录时，可以提前设置一些预设关键信息，基于这些预设关键信息使得在消费过程中记录一些关键信息。

具体为，在Flink的处理计算过程中，基于预设关键信息将操作记录中与预设关键信息相匹配的操作记录给记录下来，比如预设关键信息为：库名、表名、Binlog ID、时间戳等，其中，记录库名、表名、Binlog ID实现去重，防止上游系统数据由于网络原因出现的重复发送的情况。记录时间戳是为了第二数据库的排序功能的实现。另外，还可以直接将整条操作记录记录下来，这样记录的就是一条状态信息，并进行状态持久化，来保证容错能力，当Flink任务失败挂掉，可以自动从持久化中的状态重启，而不丢失数据。

基于第二数据库的库表结构，得到第二数据库在存储数据时的预设格式。由于本申请实施例可以选用Hbase作为第二数据库；

同时，Hbase的原理就是基于版本号实现的自动排序，所以本申请实施例的Hbase将时间戳作为版本号，根据版本号的大小顺序对Flink消费后的操作记录进行自动排序，并按照预设格式将Flink消费后的操作记录写入第二数据库的预设格式对应的预设单元内，二进制码流可以设为mysql中的主键id，操作记录作为Hbase中的value，解析出的操作时间戳作为版本区分方式，Hbase支持的表结构格式的示例如下：(rowkey,handle_msg,datasource,table,handle_type,handle_id,version)。

其中，rowkey：主键id；handle_msg：操作记录；datasource：数据源；table：表；handle_type：操作类型；handle_id：操作id；version：版本。

写入数据示例如下：

(1,{"id":"1","order_id":"10086","amount":"10087.0","create_time":"2020-03-02 05:12:49"},"test","order","UPDATE","4",1583143974870)，

这时，“1583143974870”即为版本号，按照版本号的大小顺序，对消费后的操作记录排序，得到操作记录排序队列。

需要说明的是，在本申请实施例中，获取时间戳可以按照当前时间对应计算Unix时间戳的方式得出，比如，18:00，计算Unix时间戳为：1630663219，其中，当前时间的数值大小与Unix时间戳的数值大小成正比例关系，当前时间的数值越大，对应的时间戳数值也越大。

在本申请实施例中，Flink消费的数据都带有操作记录时间戳，将该时间戳作为Hbase单个单元记录的版本号，对于由于网络延时或者是多分区下消费速率不一致导致的乱序数据，可由Hbase基于时间戳的多版本性实现自动排序。

作为一种可选实施例，在将操作记录排序队列对应的增量数据发送至目标端之前，方法还包括：

对操作记录排序队列对应的增量数据进行格式的转换，得到转换格式后的增量数据，其中，转换格式后的增量数据满足目标端所支持的数据格式；

将转换格式后的增量数据发送至目标端，其中，目标端的数量为至少一个。

可选地，由于与源端对应的目标端的数量为至少一个，所以为了适应不同目标端的数据库支持格式，本申请实施例将操作记录排序队列对应的增量数据进行格式的转换，得到转换格式后的增量数据，再将转换格式后的增量数据发送至目标端，这样就可以在目标端的数据库完成增量数据的存储。

比如，源端的数据库是mysql，目标端的数据库是Hive、ElasticSearch等，这时，要根据数据写入操作指令，对mysql数据库中的增量数据进行格式更改，以适应Hive数据仓库、Elastic Search(搜索服务引擎，ES)等目标端的数据库支持的数据格式。

在本申请实施例中能够提供跨数据库类型的同步能力，实现不同数据库间数据的同步。

作为一种可选实施例，利用流式处理引擎读取第二数据库内存放的操作记录排序队列包括：

流式处理引擎根据预设消费方案对读取的操作记录排序队列进行消费，其中，预设消费方案用于指示流式处理引擎对操作记录排序队列内的各个操作记录执行有且仅有一次的消费操作。

可选地，为了保证流式消费引擎的消费高效性，本申请实施例利用预设消费方案，比如exactly-once(精确一次)消费状态来保证对操作记录进行了消费且仅被消费一次，与此同时，还可以通过checkpiont检查点机制将所有操作记录写入Flink侧，保证数据的一致性。在这里，预设消费方案的消费对象是，第二数据库中存放的操作记录排序队列中的各个操作记录。

作为一种可选实施例，在流式处理引擎根据预设消费方案对读取的操作记录排序队列进行消费之后，方法还包括：

获取操作记录排序队列内的各个操作记录的识别码；

对识别码执行检查机制操作，其中，检查机制包括：识别码错误检查机制、识别码重复检查机制；

将检查机制指示错误的操作记录从操作记录排序队列中删除。

可选地，本申请实施例在利用流式处理引擎对操作记录执行消费时，会获取到操作记录排序队列内的各个操作记录的识别码，其中，识别码用于唯一地表示操作记录，每个操作记录均对应一个识别码，这时，对这些识别码进行查重，查错的操作，对于识别码的编号相同的操作记录或者识别码的编号有误的操作记录从操作记录排序队列中删除。

同时，将这些处理的操作记录的前后操作状态都进行持久化存储。

在本申请实施例中，通过对各个操作记录的识别码执行检查机制的操作，可保证操作记录的准确性和单一性。

作为一种可选实施例，在利用流式处理引擎读取第二数据库内存放的操作记录排序队列之后，方法还包括：

在利用流式处理引擎消费操作记录的情况下，确定当前消费的操作记录对应的第一版本号；

获取预设单元内存放的所有版本号；

比较所有版本号与第一版本号的数值大小，将小于第一版本号的第二版本号所对应的操作记录进行删除，其中，第二版本号为所有版本号中除了第一版本号之外的其他任意版本号。

可选地，Flink消费的时候会记录消费到当前消费的操作记录对应的第一版本号，即当前的最新的版本号，然后将预设单元内存放的所有版本号与该第一版本号进行数值大小的比较，将版本号小于这个第一版本号对应的操作记录进行删除，可以理解的是，版本号就是时间戳，而时间戳又是由当前时刻转换来的，所以如果所有版本号中存在数值小于第一版本号的第二版本号，则证明该操作记录已消费完毕，这些操作记录的数据就相当于已“过期”，所以需要将“已过期”的操作记录进行删除。其中，第二版本号为所有版本号中除了第一版本号之外的其他任意一个版本号。

在本申请实施例中，通过版本号来删除已消费过的操作记录，达到数据去冗余的效果。

作为一种可选实施例，如图2所示，图2是根据本申请实施例的一种可选的增量数据的同步方法的整体流程示意图，其执行步骤如下：

(1)获取mysql数据源的Binlog日志文件。

具体地，mysql实例经过合理配置后，业务系统对数据库的操作转存为二进制的Binlog文件。

(2)解析Binlog日志文件的Binlog信息，放入kafka消息队列。

具体可以通过数据库操作记录解析工具(比如canal开源解析工具)解析mysql的Binlog日志，获取执行的每一个Insert/Update/Delete的指令，与修改前后的数据，聚合成json形式，成为生成对库表的操作记录。

(3)Flink提取kafka消息队列中的消息，写入Hbase中。

具体地，将解析出来的操作记录同步发送到kafka的topic中。可以根据业务场景为topic配置多partition，通过分布式写入和读取，实现变更记录频繁的业务库表的操作记录消息的高吞吐。

在Flink的处理计算过程中，将之前消费的操作记录中的关键信息进行记录下来，(比如将库名表名和Binlog ID记录下来，由于上游系统数据由于网络原因可能有重复发送的情况，通过库名表名和Binlog ID来实现去重)，或者直接记录整条handle msg(也就是记录状态)，并进行状态持久化，来保证容错能力，当Flink任务失败挂掉，可以自动从持久化中的状态重启，而不丢失数据。Flink将解析出操作记录的时间戳及其他关键信息写入HBase中的单个cell中，rowkey可以设为mysql中的主键id，操作记录作为Hbase中的value，解析出的操作时间戳作为Hbase单条cell记录的版本号(版本数设为max)，对于由于网络延时或者是多partition下消费速率不一致导致的乱序数据，可由Hbase基于timestamp的多版本性实现自动排序。

(4)Flink读取Hbase，写入目标端，同时，在写入目标端之前，需要删除过去的版本号，即删除过期的操作记录，输入不同的目标端，例如Hive数据仓库、ES搜索服务引擎、mysql实例。

具体地，由Flink程序读取Hbase中的多版本数据，通过Flink对canal json格式的支持，可以依次解析Hbase中存储排序后的json数据到Flink sql中。并由Flink对接Elasticsearch，或者其他Hbase实例，配合Flink的链接器，使用Flink sql对目标端的数据库进行同步写入，最终实现增量数据同步。其中，写入时可将原始数据转换成不同数据源的写入格式(例如ES中的一个doc、Hbase中的一条put)，与此同时将偏移量保存在状态信息中。

本申请中偏移量，指的是Flink当前消费到的Binlog记录的ID编号，这里也是有状态的读取的，对于ID编号相同的记录，会采取去重操作。Flink读取出的数据，在转换操作前后均存储在状态中，并持久化。

本申请中，借由Flink exactly-once状态一致性保证消息有且仅被消费一次，将数据checkpiont到Flink端保证容错。Flink消费后即可清空此时间窗口内Hbase中的数据。

另外，上述各个实施例提供的增量数据的同步方法，可以应用到多种业务场景中：

1.简单的数据中心备份异地容灾场景中，通过在不同地点建立备份系统，可以提高业务抵抗各种可能安全因素的容灾能力。这需要将主业务源数据实时的同步到异地的备份数据中心去，当灾难发生后可以使用异地的备份数据实现快速接管，保证数据的安全性和业务的连续性。

2.异地多数据中心多个场景下，为了保证多个数据中心同时为业务提供服务，并实现流量划拨等能力，这就要求目标端数据中心拥有源端数据中心相同的数据，包括数据库数据，分布式缓存数据，分布式队列数据，以及各种中间件数据等。本申请主要应用到数据库的备份场景中。多中心的数据库备份涉及共享数据和独占数据的备份。共享数据是单项的备份，通过竞争型服务，将数据统一写入一个数据中心，然后通过本申请描述的数据同步机制，同步到其他数据中心。独占数据则要求交叉互备，本申请同样可以应用于多个数据源。

3.为了给业务数据分析部门提供强大的数据支持，企业往往建立有大型的数据仓库系统，汇集不同数据源的数据到统一仓库中，通过数据清洗，提取，分析流程，产出分析性报告，为企业的各类决策提供数据支撑，指导流程改进，监控业务成本，获客率，日活，PV，UV等重要参数的变化。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

根据本申请实施例的另一个方面，还提供了一种用于实施上述增量数据的同步方法的增量数据的同步装置。图3是根据本申请实施例的一种可选的增量数据的同步装置的结构框图，如图3所示，该装置可以包括：

第一获取单元301，用于在确定源端的目标业务系统内的目标子业务被更新的情况下，获取被更新时产生的增量数据对应的操作记录，其中，目标业务系统内包含多个子业务，操作记录用于表征增量数据产生时对应的多个关联信息，关联信息包含时间戳；

第一发送单元302，与第一获取单元301相连，用于将操作记录按照关联信息的分类分别发送至分布式消息队列的各个主题分区中；

得到单元303，与第一发送单元302相连，用于利用流式处理引擎提取主题分区中的操作记录进行消费，并将消费后的操作记录写入第二数据库内，得到操作记录排序队列，其中，第二数据库按照预设格式将消费后的操作记录进行存放，操作记录排序队列是依据时间戳的先后次序对消费后的操作记录进行排序后生成的队列；

第二发送单元304，与得到单元303相连，用于利用流式处理引擎读取第二数据库内存放的操作记录排序队列，并将操作记录排序队列对应的增量数据发送至目标端，使得目标端完成增量数据的同步。

需要说明的是，该实施例中的第一获取单元301可以用于执行上述步骤S101，该实施例中的第一发送单元302可以用于执行上述步骤S102，该实施例中的得到单元303可以用于执行上述步骤S103，该实施例中的第二发送单元304可以用于执行上述步骤S104。

通过上述模块，利用目标子业务被更新时产生的增量数据对应的操作记录，将这些操作记录记录在第二数据库内，利用第二数据库作为增量同步操作记录的中转存储介质，并通过第二数据库基于操作记录对应的时间戳的先后次序对这些操作记录进行自动排序，这样在处理引擎读取排序好的操作记录，并发送其对应的增量数据至目标端时，保证了消息的先后顺序，实现了从源端到目标端增量数据同步的次序准确性，进而解决了相关技术中源端和目标端的增量数据同步不准确的问题。

作为一种可选的实施例，第一获取单元包括：

第一获取模块，用于获取目标业务系统内的第一数据库，其中，第一数据库内存储有目标子业务更新后的增量数据；

第一得到模块，用于对第一数据库内存储的增量数据进行实例化配置，得到可读取数据；

第二获取模块，用于获取可读取数据对应的操作记录。

作为一种可选的实施例，第二获取模块包括：

转换子单元，用于将可读取数据转换为二进制日志文件，其中，二进制日志文件用于记录第一数据库内存储的已更新数据和待更新数据；

得到子单元，用于根据解析工具解析二进制日志文件，得到目标子业务被更新时执行的操作记录。

作为一种可选的实施例，得到单元包括：

第二得到模块，用于流式处理引擎基于预设关键信息，对主题分区中的操作记录进行消费，得到消费后的操作记录；

第三获取模块，用于获取第二数据库存放数据的预设格式；

写入模块，用于将时间戳作为版本号，并按照预设格式将消费后的操作记录写入预设格式对应的预设单元内；

排序模块，用于按照版本号的大小顺序，对消费后的操作记录排序，得到操作记录排序队列。

作为一种可选的实施例，该装置还包括：

转换单元，用于在将操作记录排序队列对应的增量数据发送至目标端之前，对操作记录排序队列对应的增量数据进行格式的转换，得到转换格式后的增量数据，其中，转换格式后的增量数据满足目标端所支持的数据格式；

第三发送单元，用于将转换格式后的增量数据发送至目标端，其中，目标端的数量为至少一个。

作为一种可选的实施例，第二发送单元还包括：

消费模块，用于流式处理引擎根据预设消费方案对读取的操作记录排序队列进行消费，其中，预设消费方案用于指示流式处理引擎对操作记录排序队列内的各个操作记录执行有且仅有一次的消费操作。

作为一种可选的实施例，该装置还包括：

第二获取单元，用于在流式处理引擎根据预设消费方案对读取的操作记录排序队列进行消费之后，获取操作记录排序队列内的各个操作记录的识别码；

操作单元，用于对识别码执行检查机制操作，其中，检查机制包括：识别码错误检查机制、识别码重复检查机制；

第一删除单元，用于将检查机制指示错误的操作记录从操作记录排序队列中删除。

作为一种可选的实施例，该装置还包括：

确定单元，用于在利用流式处理引擎读取第二数据库内存放的操作记录排序队列之后，在利用流式处理引擎消费操作记录的情况下，确定当前消费的操作记录对应的第一版本号；

第三获取单元，用于获取预设单元内存放的所有版本号；

第二删除单元，用于比较所有版本号与第一版本号的数值大小，将小于第一版本号的第二版本号所对应的操作记录进行删除，其中，第二版本号为所有版本号中除了第一版本号之外的其他任意版本号。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。

根据本申请实施例的又一个方面，还提供了一种用于实施上述增量数据的同步方法的电子设备，该电子设备可以是服务器、终端、或者其组合。

图4是根据本申请实施例的一种可选的电子设备的结构框图，如图4所示，包括处理器401、通信接口402、存储器403和通信总线404，其中，处理器401、通信接口402和存储器403通过通信总线404完成相互间的通信，其中，

存储器403，用于存储计算机程序；

处理器401，用于执行存储器403上所存放的计算机程序时，实现如下步骤：

在确定源端的目标业务系统内的目标子业务被更新的情况下，获取被更新时产生的增量数据对应的操作记录，其中，目标业务系统内包含多个子业务，操作记录用于表征增量数据产生时对应的多个关联信息，关联信息包含时间戳；

将操作记录按照关联信息的分类分别发送至分布式消息队列的各个主题分区中；

利用流式处理引擎提取主题分区中的操作记录进行消费，并将消费后的操作记录写入第二数据库内，得到操作记录排序队列，其中，第二数据库按照预设格式将消费后的操作记录进行存放，操作记录排序队列是依据时间戳的先后次序对消费后的操作记录进行排序后生成的队列；

利用流式处理引擎读取第二数据库内存放的操作记录排序队列，并将操作记录排序队列对应的增量数据发送至目标端，使得目标端完成增量数据的同步。

可选地，在本实施例中，上述的通信总线可以是PCI(Peripheral ComponentInterconnect，外设部件互连标准)总线、或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括RAM，也可以包括非易失性存储器(non-volatile memory)，例如，至少一个磁盘存储器。可选地，存储器还可以是至少一个位于远离前述处理器的存储装置。

作为一种示例，如图4所示，上述存储器403中可以但不限于包括上述增量数据的同步装置中的第一获取单元301、第一发送单元302、得到单元303、第二发送单元304。此外，还可以包括但不限于上述增量数据的同步装置中的其他模块单元，本示例中不再赘述。

上述处理器可以是通用处理器，可以包含但不限于：CPU(Central ProcessingUnit，中央处理器)、NP(Network Processor，网络处理器)等；还可以是DSP(DigitalSignal Processing，数字信号处理器)、ASIC(Application Specific IntegratedCircuit，专用集成电路)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

此外，上述电子设备还包括：显示器，用于显示增量数据的同步结果。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图4所示的结构仅为示意，实施上述增量数据的同步方法的设备可以是终端设备，该终端设备可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile Internet Devices，MID)、PAD等终端设备。图4其并不对上述电子设备的结构造成限定。例如，终端设备还可包括比图4中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图4所示的不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、ROM、RAM、磁盘或光盘等。

根据本申请实施例的又一个方面，还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行增量数据的同步方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

在确定源端的目标业务系统内的目标子业务被更新的情况下，获取被更新时产生的增量数据对应的操作记录，其中，目标业务系统内包含多个子业务，操作记录用于表征增量数据产生时对应的多个关联信息，关联信息包含时间戳；

将操作记录按照关联信息的分类分别发送至分布式消息队列的各个主题分区中；

利用流式处理引擎提取主题分区中的操作记录进行消费，并将消费后的操作记录写入第二数据库内，得到操作记录排序队列，其中，第二数据库按照预设格式将消费后的操作记录进行存放，操作记录排序队列是依据时间戳的先后次序对消费后的操作记录进行排序后生成的队列；

利用流式处理引擎读取第二数据库内存放的操作记录排序队列，并将操作记录排序队列对应的增量数据发送至目标端，使得目标端完成增量数据的同步。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例中对此不再赘述。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、ROM、RAM、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

根据本申请实施例的又一个方面，还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中；计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一个实施例中的增量数据的同步方法步骤。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例增量数据的同步方法的全部或部分步骤。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例中所提供的方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (11)

1.一种增量数据的同步方法，其特征在于，所述方法包括：

在确定源端的目标业务系统内的目标子业务被更新的情况下，获取被更新时产生的增量数据对应的操作记录，其中，所述目标业务系统内包含多个子业务，所述操作记录用于表征所述增量数据产生时对应的多个关联信息，所述关联信息包含时间戳；

将所述操作记录按照所述关联信息的分类分别发送至分布式消息队列的各个主题分区中；

利用流式处理引擎提取所述主题分区中的所述操作记录进行消费，并将消费后的所述操作记录写入第二数据库内，得到操作记录排序队列，其中，所述第二数据库按照预设格式将所述消费后的所述操作记录进行存放，所述操作记录排序队列是依据所述时间戳的先后次序对所述消费后的所述操作记录进行排序后生成的队列；

利用所述流式处理引擎读取所述第二数据库内存放的所述操作记录排序队列，并将所述操作记录排序队列对应的所述增量数据发送至目标端，使得所述目标端完成所述增量数据的同步。

2.根据权利要求1所述的方法，其特征在于，所述获取被更新时产生的增量数据对应的操作记录包括：

获取所述目标业务系统内的第一数据库，其中，所述第一数据库内存储有所述目标子业务更新后的所述增量数据；

对所述第一数据库内存储的所述增量数据进行实例化配置，得到可读取数据；

获取所述可读取数据对应的所述操作记录。

3.根据权利要求2所述的方法，其特征在于，所述获取所述可读取数据对应的所述操作记录包括：

将所述可读取数据转换为二进制日志文件，其中，所述二进制日志文件用于记录所述第一数据库内存储的已更新数据和待更新数据；

根据解析工具解析所述二进制日志文件，得到所述目标子业务被更新时执行的所述操作记录。

4.根据权利要求1所述的方法，其特征在于，所述利用流式处理引擎提取所述主题分区中的所述操作记录进行消费，并将消费后的所述操作记录写入第二数据库内，得到操作记录排序队列包括：

所述流式处理引擎基于预设关键信息，对所述主题分区中的操作记录进行消费，得到所述消费后的所述操作记录；

获取所述第二数据库存放数据的预设格式；

将所述时间戳作为版本号，并按照所述预设格式将所述消费后的所述操作记录写入所述预设格式对应的预设单元内；

按照所述版本号的大小顺序，对所述消费后的所述操作记录排序，得到所述操作记录排序队列。

5.根据权利要求1所述的方法，其特征在于，在将所述操作记录排序队列对应的所述增量数据发送至目标端之前，所述方法还包括：

对所述操作记录排序队列对应的所述增量数据进行格式的转换，得到转换格式后的增量数据，其中，所述转换格式后的增量数据满足所述目标端所支持的数据格式；

将所述转换格式后的增量数据发送至所述目标端，其中，所述目标端的数量为至少一个。

6.根据权利要求1所述的方法，其特征在于，所述利用所述流式处理引擎读取所述第二数据库内存放的所述操作记录排序队列包括：

所述流式处理引擎根据预设消费方案对读取的所述操作记录排序队列进行消费，其中，所述预设消费方案用于指示所述流式处理引擎对所述操作记录排序队列内的各个所述操作记录执行有且仅有一次的消费操作。

7.根据权利要求6所述的方法，其特征在于，在所述流式处理引擎根据预设消费方案对读取的所述操作记录排序队列进行消费之后，所述方法还包括：

获取所述操作记录排序队列内的各个所述操作记录的识别码；

对所述识别码执行检查机制操作，其中，所述检查机制包括：识别码错误检查机制、识别码重复检查机制；

将所述检查机制指示错误的所述操作记录从所述操作记录排序队列中删除。

8.根据权利要求4所述的方法，其特征在于，在利用所述流式处理引擎读取所述第二数据库内存放的所述操作记录排序队列之后，所述方法还包括：

在利用所述流式处理引擎消费所述操作记录的情况下，确定当前消费的所述操作记录对应的第一版本号；

获取所述预设单元内存放的所有所述版本号；

比较所有所述版本号与所述第一版本号的数值大小，将小于所述第一版本号的第二版本号所对应的操作记录进行删除，其中，所述第二版本号为所有所述版本号中除了所述第一版本号之外的其他任意版本号。

9.一种增量数据的同步装置，其特征在于，所述装置包括：

第一获取单元，用于在确定源端的目标业务系统内的目标子业务被更新的情况下，获取被更新时产生的增量数据对应的操作记录，其中，所述目标业务系统内包含多个子业务，所述操作记录用于表征所述增量数据产生时对应的多个关联信息，所述关联信息包含时间戳；

第一发送单元，用于将所述操作记录发送至分布式消息队列的各个主题分区中；

得到单元，用于利用流式处理引擎提取所述主题分区中的所述操作记录进行消费，并将消费后的所述操作记录写入第二数据库内，得到操作记录排序队列，其中，所述第二数据库按照预设格式将所述消费后的所述操作记录进行存放，所述操作记录排序队列是依据所述时间戳的先后次序对所述消费后的所述操作记录进行排序后生成的队列；

第二发送单元，用于利用所述流式处理引擎读取所述第二数据库内存放的所述操作记录排序队列，并将所述操作记录排序队列对应的所述增量数据发送至目标端，使得所述目标端完成所述增量数据的同步。

10.一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，所述处理器、所述通信接口和所述存储器通过所述通信总线完成相互间的通信，其特征在于，

所述存储器，用于存储计算机程序；

所述处理器，用于通过运行所述存储器上所存储的所述计算机程序来执行权利要求1至8中任一项所述的增量数据的同步方法步骤。

11.一种计算机可读的存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行权利要求1至8中任一项中所述的增量数据的同步方法步骤。

Images