CN112487087A - 一种增量数据实时同步的方法及相关设备 - Google Patents

Abstract

本说明书一个或多个实施例提供一种增量数据实时同步的方法及相关设备，通过从配置文件中读取MongoDB数据集合，创建数据的同步线程，所述同步线程将数据转换格式并发送到Kafka中，并将异步发送立刻返回的返回值加入到发送列表中，判断所述发送列表的数据量是否达到阈值，确认是否有数据发送失败并作出相应处理，使得其他业务系统通过消费同步到Kafka中的数据，实现了系统之间隔离，避免了不同系统的互相影响，降低了系统运行的风险；同时还实现了数据之间的共享，利于探索不同的应用场景，发挥数据更大的价值，提升了系统的反应速度和用户体验。

Description

一种增量数据实时同步的方法及相关设备

技术领域

本说明书一个或多个实施例涉及数据同步技术领域，尤其涉及一种增量数据实时同步的方法及相关设备。

背景技术

目前网络技术飞速发展，数据以指数级的速度增长，各种系统之间的数据有一定的内在联系，如何打通数据之间的壁垒，实现各系统数据之间的有效融合，挖掘数据的价值，对公司的发展有着至关重要的作用。

MongoDB是一个高性能、无模式的文档型数据库，是当前noSql数据库产品中最热门的一种，他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型，而且支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。它是一个面向集合的,模式自由的文档型数据库。oplog是Mongodb保存操作日志的固定集合，MongoDB主节点应用业务操作修改到数据库中，然后记录这些操作到oplog中，从节点复制这些oplog，然后应用这些修改，保持主从同步，可以利用oplog实现MongoDB增量数据的实时同步，其中，增量数据指数据库进行修改后新增的数据。

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。具有高性能、持久化、多副本备份、横向扩展能力等优点，用于构建实时数据管道和流应用程序。

Redis基于内存的数据库，读写性能十分优越，可以支持每秒十几万此的读/写操作。

将MongoDB增量数据实时同步到Kafka可以提供给下游系统消费，同时减轻业务系统的压力。

目前需要MongoDB业务数据的其他系统，有两种可行方案可以获得MongoDB的业务数据，一种是直接连接MongoDB业务系统来获取需要的数据，一种是以批作业的形式定时拉取MongoDB的现有存量数据，然后存储到对应系统的数据库中。然而直连使用MongoDB系统会加大MongoDB业务系统的访问压力，对MongoDB业务系统运行会产生影响，同时直连MongoDB业务系统也会对数据的安全性产生不利影响。另外批作业定时拉取的方式，有一定的延迟性，数据不是实时数据，同时每次拉取全部存量数据不论对MongoDB业务系统还是对需要MongoDB数据的其他系统都有不小的压力，对系统正常运行产生不利影响。

发明内容

有鉴于此，本说明书一个或多个实施例的目的在于提出一种增量数据实时同步的方法及相关设备。

基于上述目的，本说明书一个或多个实施例提供了一种增量数据实时同步的方法，包括：

从配置文件中读取需要同步的MongoDB数据集合，创建数据的同步线程；

所述同步线程从oplog中读取对应的所述MongoDB数据集合的数据，将读取到的所述MongoDB数据集合的数据转换成json格式；

所述同步线程将所述json格式的数据加入到发送列表中并异步发送到与所述MongoDB数据集合对应的Kafka的主题中，同时将异步发送立刻返回的返回值加入到发送列表中；

判断所述发送列表的数据量是否达到预设的阈值，如果未达到预设的阈值，则继续发送所述json格式的数据，如果达到阈值，则使用所述Kafka提供的接口判断是否所述发送列表中的所有数据都发送成功，如果所述发送列表中的所有数据都发送成功，则返回上一步骤，继续发送下一个批次的所述json格式的数据，如果所述发送列表中的数据存在一个或多个发送失败，则对所述发送列表中的所有数据进行重复发送，直至发送成功，返回上一步骤，继续发送下一个批次的所述json格式的数据。

基于同一发明构思，本说明书一个或多个实施例还提供了一种增量数据实时同步的装置，包括：

获取模块，被配置为从配置文件中读取需要同步的MongoDB数据集合，创建数据的同步线程；

转换模块，被配置为所述同步线程从oplog中读取对应的所述MongoDB数据集合的数据，将读取到的所述MongoDB数据集合的数据转换成json格式；

发送模块，被配置为将所述同步线程将所述json格式的数据加入到发送列表中并异步发送到与所述MongoDB数据集合对应的Kafka的主题中，同时将异步发送立刻返回的返回值加入到发送列表中；

判断模块，被配置为判断所述发送列表的数据量是否达到预设的阈值，如果未达到预设的阈值，则继续发送所述json格式的数据，如果达到阈值，则使用所述Kafka提供的接口判断是否所述发送列表中的所有数据都发送成功，如果所述发送列表中的所有数据都发送成功，则返回上一步骤，继续发送下一个批次的所述json格式的数据，如果所述发送列表中的数据存在一个或多个发送失败，则对所述发送列表中的所有数据进行重复发送，直至发送成功，返回上一步骤，继续发送下一个批次的所述json格式的数据。

基于同一发明构思，本说明书一个或多个实施例还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上任意一项所述的方法。

基于同一发明构思，本说明书一个或多个实施例还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一所述方法。

从上面所述可以看出，本说明书一个或多个实施例提供的增量数据实时同步的方法及相关设备，通过从配置文件中读取MongoDB数据集合，创建数据的同步线程，所述同步线程将数据转换格式并发送到Kafka中，并将异步发送立刻返回的返回值加入到发送列表中，判断所述发送列表的数据量是否达到阈值，确认是否有数据发送失败并作出相应处理，使得其他业务系统通过消费同步到Kafka中的数据，实现了系统之间隔离，避免了不同系统的互相影响，降低了系统运行的风险；同时还实现了数据之间的共享，利于探索不同的应用场景，发挥数据更大的价值，提升了系统的反应速度，有利于提升用户体验。

附图说明

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

图1为本说明书一个或多个实施例增量数据实时同步的方法流程图；

图2为本说明书一个或多个实施例实现断点续传的流程图；

图3为本说明书一个或多个实施例增量数据实时同步的装置结构示意图；

图4为本说明书一个或多个实施例的电子设备结构示意图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。

需要说明的是，除非另外定义，本说明书一个或多个实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。

如背景技术部分所述，现有的MongoDB业务数据的同步方案还难以满足业务的需要。申请人在实现本公开的过程中发现，现有的MongoDB业务数据的同步方案存在的主要问题在于：直连使用MongoDB系统会加大MongoDB业务系统的访问压力，影响系统的运行效率，同时直连MongoDB业务系统也会对数据的安全性产生不利影响。批作业定时拉取的方式，有一定的延迟性，数据不是实时数据，同时每次拉取全部存量数据不论对MongoDB业务系统还是对需要MongoDB数据的其他系统都有不小的压力，同样会对系统正常运行产生不利影响。

有鉴于此，本说明书一个或多个实施例提供了一种增量数据实时同步的方案，具体的，首先定位到MongoDB的复制集合oplog的最后一条数据,不断获取比该条数据晚产生的所有增量数据，然后对数据进行逐条进行格式封装，实时发送到Kafka。在首次取MongoDB增量数据时，通过查找当前oplog集合中最新产生数据的时间作为标记，之后不断拉取该数据之后产生的数据，发送数据到Kafka，实现增量数据同步。

本说明书一个或多个实施例中，增量数据指数据库进行修改后新增的数据。

为了提高增量数据发送Kafka的可靠性和发送效率,本说明书一个或多个实施例采用逐条异步发送数据到Kafka，同时将异步发送立刻返回的未来结果加入到集合中，当集合中未来结果个数达到阈值时，对每个异步发送结果进行确认，如果全部返回完成，则进行下一批数据的发送，否则对该批数据全部重新发送，这样既可以保证发送效率，同时保证数据发送过程中不丢失。

将每条数据产生的时间记录到Redis中，对于程序运行一段时间重启时，可以直接从Redis中读取上次同步数据的时间标记，对该标记之后的数据进行同步，这样可以实现数据的断点续传，不至于因为程序的中断而丢失数据。为了提高数据同步的效率，对同步的MongoDB集合按集合粒度进行多线程划分(即每个集合一个同步线程，集合即传统数据库中表的概念)，也就是每个线程分别从oplog中取一个集合的数据，多线程对数据进行同步，记录到Redis中的时间标记也是按集合进行划分。

可见，本说明书一个或多个实施例的增量数据实时同步的方案既实现了将MongoDB增量数据实时同步到Kafka，又通过多线程取各集合数据和将数据产生的时间标记记录到Redis，实现了断点续传。将数据发送至Kafka过程中的逐条异步和批量确认的方式，保证了数据同步高效率、可靠性以及完整性。

以下，通过具体的实施例来详细说明本说明书一个或多个实施例的技术方案。

参考图1，本说明书一个实施例的增量数据实时同步的方法，包括以下步骤：

步骤S101、从配置文件中读取需要同步的MongoDB数据集合，创建数据的同步线程。

本实施例中，所述创建数据的同步线程的数量不少于一个，当同步线程多于一个时，每个线程分别执行所述创建数据的同步线程之后的操作。

本步骤中，需要同步的MongoDB数据集合为增量数据。

作为一个示例，为了提高同步效率，可以对同步的MongoDB集合按集合粒度进行多线程划分(即每个集合一个同步线程，集合即传统数据库中表的概念)，也就是每个线程分别从oplog中取一个集合的数据，多线程对数据进行同步。

步骤S102、所述同步线程从oplog中读取对应的所述MongoDB数据集合的数据，将读取到的所述MongoDB数据集合的数据转换成json格式。

本步骤中，oplog是Mongodb保存操作日志的固定集合，MongoDB所有的数据操作都会记录到该集合中，然后从节点从oplog拉取数据，修改相应的从节点数据，保持主从同步。上述json格式的数据由增量数据转换格式之后得到。

步骤S103、所述同步线程将所述json格式的数据加入到发送列表中并异步发送到与所述MongoDB数据集合对应的Kafka的主题中，同时将异步发送立刻返回的返回值加入到发送列表中，以便后续对数据是否发送成功进行确认。

本步骤中，采用逐条异步发送数据到Kafka。

步骤S104、判断所述发送列表的所述返回值数量是否达到预设的阈值，如果未达到预设的阈值，则继续发送所述json格式的数据，如果达到阈值，则使用所述Kafka提供的接口判断是否所述发送列表中的所有数据都发送成功，如果所述发送列表中的所有数据都发送成功，则返回上一步骤，继续发送下一个批次的所述json格式的数据，如果所述发送列表中的数据存在一个或多个发送失败，则对所述发送列表中的所有数据进行重复发送，直至发送成功。

本实施例中，为了保证数据的顺序性，所述发送列表中的数据存在一个或多个发送失败时，需要所有数据都发送。例如，一条数据先后做了修改和删除操作，修改的那条日志记录发送失败，删除的日志记录发送成功，这时如果只把修改的重复发送，会造成数据的不一致，需要把所有数据都发送。

可见，在本实施例中通过多线程取oplog数据，能够提高从MongoDB拉取增量数据的效率，通过使用逐条发送和逐批次确认的方式发送数据到Kafka，可以提高发送效率，对数据发送失败的批次进行重发，能够保证增量数据不丢失，这能够有效的提升本实施例的方法的效果。

作为一个可选的实施例，参考图2，对于前述实施例中的步骤S102，其还可以包括以下步骤：

S201、所述同步线程从Redis读取同步时间标记。

S202、根据所述同步时间标记从oplog中读取对应的所述MongoDB数据集合的数据。如果所述Redis中有对应的所述MongoDB数据集合的时间标记，则从所述oplog中读取所述时间标记之后的所述MongoDB数据集合的数据，如果所述Redis中没有对应的所述MongoDB数据集合的时间标记，则从所述oplog中读取最新产生的所述MongoDB数据集合的数据。

S203、所述同步线程所有数据都发送成功之后，将该批次最后一条数据的时间标记记录到所述Redis中，以实现断点续传。

本步骤中，所述同步线程多于一个时，记录到所述Redis中的时间标记按照同步线程的集合进行划分。

可见，在本实施例中通过将数据产生时间标记记录到Redis，对于任务进行一段时间重启时的情况，可以直接从Redis中取上次同步数据的标记，取该标记之后的数据进行同步，实现断点续传的效果。

需要说明的是，本说明书一个或多个实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本说明书一个或多个实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。

需要说明的是，上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

基于同一发明构思，与上述任意实施例方法相对应的，本说明书一个或多个实施例还提供了一种增量数据实时同步的装置。

参考图3，所述增量数据实时同步的装置，包括：

获取模块301，被配置为从配置文件中读取需要同步的MongoDB数据集合，创建数据的同步线程。

转换模块302，被配置为所述同步线程从oplog中读取对应的所述MongoDB数据集合的数据，将读取到的所述MongoDB数据集合的数据转换成json格式。

发送模块303，被配置为将所述同步线程将所述json格式的数据加入到发送列表中并异步发送到与所述MongoDB数据集合对应的Kafka的主题中，同时将异步发送立刻返回的返回值加入到发送列表中。

判断模块304，被配置为判断所述发送列表的所述返回值数量是否达到预设的阈值，如果未达到预设的阈值，则继续发送所述json格式的数据，如果达到阈值，则使用所述Kafka提供的接口判断是否所述发送列表中的所有数据都发送成功，如果所述发送列表中的所有数据都发送成功，则返回上一步骤，继续发送下一个批次的所述json格式的数据，如果所述发送列表中的数据存在一个或多个发送失败，则对所述发送列表中的所有数据进行重复发送，直至发送成功。

作为一个可选的实施例，所述转换模块302，具体被配置为所述同步线程从Redis读取同步时间标记，根据所述同步时间标记从oplog中读取对应的所述MongoDB数据集合的数据，如果所述Redis中有对应的所述MongoDB数据集合的时间标记，则从所述oplog中读取所述时间标记之后的所述MongoDB数据集合的数据，如果所述Redis中没有对应的所述MongoDB数据集合的时间标记，则从所述oplog中读取最新产生的所述MongoDB数据集合的数据；将读取到的所述MongoDB数据集合的数据转换成json格式。

作为一个可选的实施例，所述判断模块之后还包括断点续传模块，被配置为当所述同步线程所有数据都发送成功之后，将该批次最后一条数据的时间标记记录到所述Redis中，以实现断点续传。

作为一个可选的实施例，所述获取模块301，具体被配置为不少于一个的创建数据的同步线程，当同步线程多于一个时，每个线程分别执行所述创建数据的同步线程之后的操作。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述实施例的装置用于实现前述任一实施例中相应的增量数据实时同步的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本说明书一个或多个实施例还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的增量数据实时同步的方法。

图4示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

上述实施例的电子设备用于实现前述任一实施例中相应的增量数据实时同步的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本说明书一个或多个实施例还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的增量数据实时同步的方法。

本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的增量数据实时同步的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本说明书一个或多个实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

尽管已经结合了本公开的具体实施例对本公开进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本说明书一个或多个实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (10)

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

从配置文件中读取需要同步的MongoDB数据集合，创建数据的同步线程；

所述同步线程从oplog中读取对应的所述MongoDB数据集合的数据，将读取到的所述MongoDB数据集合的数据转换成json格式；

所述同步线程将所述json格式的数据加入到发送列表中并异步发送到与所述MongoDB数据集合对应的Kafka的主题中，同时将异步发送立刻返回的返回值加入到发送列表中；

判断所述发送列表的数据量是否达到预设的阈值，如果未达到预设的阈值，则继续发送所述json格式的数据，如果达到阈值，则使用所述Kafka提供的接口判断是否所述发送列表中的所有数据都发送成功，如果所述发送列表中的所有数据都发送成功，则返回上一步骤，继续发送下一个批次的所述json格式的数据，如果所述发送列表中的数据存在一个或多个发送失败，则对所述发送列表中的所有数据进行重复发送，直至发送成功，返回上一步骤，继续发送下一个批次的所述json格式的数据。

2.根据权利要求1所述的方法，其特征在于，所述同步线程从oplog中读取对应的所述MongoDB数据集合的数据，还包括所述同步线程从Redis读取同步时间标记，根据所述同步时间标记从oplog中读取对应的所述MongoDB数据集合的数据；

所述同步线程所有数据都发送成功之后，将该批次最后一条数据的时间标记记录到所述Redis中，以实现断点续传。

3.根据权利要求2所述的方法，其特征在于，所述根据所述同步时间标记从oplog中读取对应的所述MongoDB数据集合的数据，包括：

如果所述Redis中有对应的所述MongoDB数据集合的时间标记，则从所述oplog中读取所述时间标记之后的所述MongoDB数据集合的数据，如果所述Redis中没有对应的所述MongoDB数据集合的时间标记，则从所述oplog中读取最新产生的所述MongoDB数据集合的数据。

4.根据权利要求1所述的方法，其特征在于，所述创建数据的同步线程的数量不少于一个；当同步线程多于一个时，每个线程分别执行所述创建数据的同步线程之后的操作。

5.一种增量数据实时同步的装置，其特征在于，包括：

获取模块，被配置为从配置文件中读取需要同步的MongoDB数据集合，创建数据的同步线程；

转换模块，被配置为所述同步线程从oplog中读取对应的所述MongoDB数据集合的数据，将读取到的所述MongoDB数据集合的数据转换成json格式；

发送模块，被配置为将所述同步线程将所述json格式的数据加入到发送列表中并异步发送到与所述MongoDB数据集合对应的Kafka的主题中，同时将异步发送立刻返回的返回值加入到发送列表中；

判断模块，被配置为判断所述发送列表的数据量是否达到预设的阈值，如果未达到预设的阈值，则继续发送所述json格式的数据，如果达到阈值，则使用所述Kafka提供的接口判断是否所述发送列表中的所有数据都发送成功，如果所述发送列表中的所有数据都发送成功，则返回上一步骤，继续发送下一个批次的所述json格式的数据，如果所述发送列表中的数据存在一个或多个发送失败，则对所述发送列表中的所有数据进行重复发送，直至发送成功，返回上一步骤，继续发送下一个批次的所述json格式的数据。

6.根据权利要求5所述的装置，其特征在于，所述同步线程从oplog中读取对应的所述MongoDB数据集合的数据，具体被配置为所述同步线程从Redis读取同步时间标记，根据所述同步时间标记从oplog中读取对应的所述MongoDB数据集合的数据；

所述判断模块之后还包括断点续传模块，被配置为当所述同步线程所有数据都发送成功之后，将该批次最后一条数据的时间标记记录到所述Redis中，以实现断点续传。

7.根据权利要求6所述的装置，其特征在于，所述转换模块，具体被配置为如果所述Redis中有对应的所述MongoDB数据集合的时间标记，则从所述oplog中读取所述时间标记之后的所述MongoDB数据集合的数据，如果所述Redis中没有对应的所述MongoDB数据集合的时间标记，则从所述oplog中读取最新产生的所述MongoDB数据集合的数据。

8.根据权利要求5所述的装置，其特征在于，所述获取模块，具体被配置为不少于一个的创建数据的同步线程，当同步线程多于一个时，每个线程分别执行所述创建数据的同步线程之后的操作。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至4任意一项所述的方法。

10.一种非暂态计算机可读存储介质，其特征在于，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行权利要求1至4任一所述方法。

Images