CN110196844A - 一种数据迁移方法、系统及存储介质 - Google Patents

Abstract

本发明提供了一种数据迁移方法、系统及存储介质，方法包括：接收在源数据库形成增量数据的写指令，所述增量数据包括在所述源数据库中对应的键和值；以所述增量数据的键为索引，在源数据库中写入所述增量数据的值；接收在目标数据库中形成所述增量数据的写指令；以所述键在所述目标数据库中对应的新键为索引，在所述目标数据库中写入所述增量数据的值；将所述目标数据库中的增量数据与所述源数据库中的增量数据进行状态同步。

Description

一种数据迁移方法、系统及存储介质

技术领域

本发明涉及数据库技术，尤其涉及一种数据迁移方法、系统及存储介质。

背景技术

对互联网应用来说，后台的服务需要在数据库(DB，Data Base)中维护海量数据作为业务支撑，随着数据快速增长，数据库通常会出现难以支撑应用的情况，为了保证应用的服务质量，通过数据迁移来将旧数据库中的业务数据部署在新的数据库，以提升业务响应能力成为有效的技术手段。

常见的数据迁移方式包括：数据库扩容迁移，缓存扩容迁移等，对于这些迁移方式来说，数据迁移后数据的键(Key)与迁移前一致，区别在于迁移后数据库(DB，Data Base)发生变化，即数据的存储位置发生改变。

在相关技术提供数据库中，典型的方式是数据以键-值(Key-Value)对的结构存储，其中键作为关键字在数据库中检索值，而值用于存储数据的具体内容。

相关技术的提供数据迁移方案，只支持数据库中数据的整体迁移，在迁移过程中数据的存储结构(包括键和值)都不会发生改变。

然而，在从源数据库向目标数据库数据迁移数据时，由于数据库的数据结构、功能和特性存在差异，不可避免地涉及到对数据结构中的键进行改变，以适应目标数据库的数据结构，如何克服相关技术在数据迁移技术方面存在的限制，以平滑、高效地在数据库之间迁移数据，相关技术尚无有效解决方案。

发明内容

有鉴于此，本发明实施例提供一种数据迁移方法、系统及存储介质，能够在数据库之间平滑、高效地迁移数据。

本发明实施例提供一种数据迁移方法，包括：

接收在源数据库形成增量数据的写指令，所述增量数据包括在所述源数据库中对应的键和值；

以所述增量数据的键为索引，在源数据库中写入所述增量数据的值；

接收在目标数据库中形成所述增量数据的写指令；

以所述键在所述目标数据库中对应的新键为索引，在所述目标数据库中写入所述增量数据的值；

将所述源数据库中的增量数据与所述目标数据库中的增量数据进行状态同步。

本发明实施例提供一种数据迁移系统，包括：

数据接口，用于接收在源数据库形成增量数据的写指令，所述增量数据包括在所述源数据库中对应的键和值；

源数据库服务，用于以所述增量数据的键为索引，在源数据库中写入所述增量数据的值；

所述数据接口，用于接收在目标数据库中形成所述增量数据的写指令；

所述目标数据库服务，用于以所述键在所述目标数据库中对应的新键为索引，在所述目标数据库中写入所述增量数据的值；

所述目标数据库服务，用于将所述目标数据库中的增量数据与所述源数据库中的增量数据进行状态同步。

上述方案中，所述增量数据的状态包括写入成功和写入失败；

所述目标数据库服务，还用于以所述增量数据在所述源数据库中的状态为基准，调整所述目标数据库中的增量数据进行同步；

所述源数据库服务，还用于当所述增量数据在所述源数据库中的状态为写入失败时，重试写入直至写入成功。

上述方案中，所述目标数据库服务，还用于将所述源数据库中存量数据的键转换为新键，所述存量数据的新键用于适配所述目标数据库；以所述存量数据的新键为索引，在所述目标数据库中写入所述存量数据的值。

上述方案中，还包括：

对账服务，用于当所述目标数据库中的增量数据与所述源数据库中的增量数据进行状态同步完成时，将所述目标数据库中的数据与所述源数据库中的数据进行核对。

上述方案中，所述对账服务，还用于基于在分界时间点后的订单流水，与所述目标数据库中的增量数据进行核对，以及，

基于在所述分界时间点后的订单流水，与所述源数据库中的增量数据进行核对；

所述订单流水为在分界时间点之后产生，所述分界时间点用于根据创建时间界定所述存量数据和所述增量数据。

上述方案中，所述对账服务，还用于当所述源数据库中的存量数据迁移到所述目标数据库时，将所述目标数据库中的存量数据与所述源数据库中的存量数据进行核对。

上述方案中，所述对账服务，还用于将所述源数据库中待核对数据的键转换为新键，所述待核对数据的新键用于适配所述目标数据库；将所述目标数据库中以所述新键索引的待核对数据的值，与所述源数据库中对应的值进行核对。

上述方案中，所述数据接口，还用于当所述目标数据库中的数据与所述源数据库中的数据核对一致时，将所述数据接口与源数据库服务的对接，切换为所述数据接口与目标数据库服务的对接；其中，所述数据接口用于响应业务前端的读指令或写指令。

上述方案中，所述数据接口包括读数据接口，用于将所述读数据接口与源数据库服务的对接，切换为所述读数据接口与目标数据库服务的对接；其中，所述读数据接口用于响应所述业务前端的读指令。

上述方案中，所述数据接口包括写数据接口，用于将所述写数据接口与源数据库服务的对接、以及写数据接口与目标数据库服务的对接，切换到所述写数据接口与所述目标数据库的对接；其中，所述写数据接口用于响应所述业务前端的写指令。

上述方案中，所述源数据库服务，还用于当向所述源数据库写入所述增量数据的值后，向发送所述写指令的数据接口发送源数据库写入成功确认；

所述目标数据库服务，还用于当向所述目标数据库写入所述增量数据的值之前，向发送所述写指令的数据接口发送目标数据库写入成功确认。

上述方案中，还包括：

订单服务，用于对待检验的写指令校验是否存在对应的订单；

所述源数据库服务，还用于调用所述订单服务对在源数据库形成增量数据的写指令进行订单校验；当通过订单校验未存在与所述写指令对应的重复订单时，在所述源数据库中写入所述增量数据的值。

上述方案中，所述目标数据库服务，还用于当在目标数据库形成所述增量数据的写指令携带第一类型标签时，跳过调用订单服务，并在所述目标数据库中写入所述增量数据的值；

其中，所述第一类型标签用于指示对相应的写指令忽略调用订单服务。

上述方案中，所述目标数据库服务，还用于当所述目标数据库代替所述源数据库上线时，接收所述目标数据库中形成新数据的写指令，所接收的写指令携带第二类型标签，用于指示调用订单服务；

当通过订单校验未存在与所述写指令对应的重复订单时，在所述目标数据库中写入所述新数据。

本发明实施例提供一种存储介质，存储有计算机程序，所述计算机程序被处理器执行时，用于实现本发明实施例提供的数据迁移方法。

本发明实施例具有如下技术效果：

增量数据在形成时通过源数据库和目标数据库的写指令分别写入，避免了相关技术进使用源数据库响应写指令、并将增量数据累积后向目标数据库迁移而影响迁移的效率的问题；

向目标数据库写入时通过将增量数据在源数据库中的键进行转换，使得增量数据的新键能够适配目标数据库，巧妙克服了数据直接迁移不兼容的问题，实现平滑迁移数据的技术效果。

附图说明

图1A是本发明实施例提供的数据迁移系统100的一个可选的结构示意图；

图1B是本发明实施例提供的数据迁移系统100的一个可选的结构示意图；

图2是本发明实施例提供的数据迁移系统100的一个可选的结构示意图；

图3是本发明实施例提供的源数据库中增量数据和存量数据的示意图；

图4A至图4C是本发明实施例提供的数据同步的可选的示意图；

图5是本发明实施例提供的增量数据迁移的流程示意图；

图6是本发明实施例提供的存量数据迁移的流程示意图；

图7是本发明实施例提供的数据核对的流程示意图；

图8是本发明实施例提供的数据库切换的流程示意图；

图9是本发明实施例提供的数据迁移系统从旧数据库向新数据库迁移数据的一个可选架构示意图；

图10是本发明实施例提供的数据迁移系统在实现增量数据迁移的示意图；

图11是本发明实施例提供的数据迁移系统实现增量数据迁移流程的示意图；

图12是本发明实施例提供的增量数据核对的示意图；

图13是本发明实施例提供的存量数据核对的示意图；

图14是本发明实施例提供的数据库切换时读数据接口切换的示意图；

图15是本发明实施例提供的数据库切换时写数据接口切换的示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，所描述的实施例不应视为对本发明的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述具体的实施例的目的，不是旨在限制本发明。

对本发明进行进一步详细说明之前，对本发明实施例中涉及的名词和术语进行说明，本发明实施例中涉及的名词和术语适用于如下的解释。

1)数据库，本文中指基于键-值对的结构存储数据的数据库软件，还可以包括所依附的硬件，如处理器、存储器和网络通信设备；支持进行数据的写入(包括新增、修改和删除)和读(即查询)的操作。

2)源数据库，准备迁移出数据的数据库。

3)目标数据库，准备迁移入数据的数据库。

4)增量数据，在数据迁移过程中，源数据库中产生于分界时间点之后的数据。

5)存量数据，在数据迁移过程中，源数据库中产生于分界时间点之前的数据。

6)状态，用于表示数据在数据库写入成功或写入失败的情况，可以根据数据库是否返回出错字段确定。

下面首先说明实现本发明实施例的数据迁移系统，数据迁移系统用于实现从源数据库到目标数据库的迁移，当数据迁移系统开始准备迁移数据的时刻成为分界时间点，从而将分解时间点后写入的数据为增量数据。

参见图3，是本发明实施例提供的源数据库中增量数据和存量数据的示意图，在图3中示出的数据库中，假定将时刻T设定为分界点，那么源数据库中，根据创建数据(不是最近一次修改数据)的时间戳，早于时刻T的数据为存量数据，在时刻T后新创建的数据为增量数据。

可以理解，增量数据和存量数据仅仅是基于分界时间点划分形成，两者不存在依赖关系，因此，增量数据和存量数据的迁移可以是同步的，也可以是异步的，如果特别说明，本发明实施例中对增量数据和存量数据的迁移顺序不做限制。

例如，参见图4A至图4C，是本发明实施例提供的数据同步的可选的示意图，在图4A中，分界时间点对应时刻T，在分界时间点立即开始从源数据库到目标数据库的增量数据的迁移；而存量数据的迁移可以在时刻T开始存量数据的迁移，此时与增量数据的迁移是同步的；也可以如图4B所示，在时刻T之后的时刻开始量数据的迁移，此时与增量数据的迁移是异步的；或者如图4C所示，在时刻T之后的多个时间段分多次完成，如在设定的多个时间段分批次完成存量数据的迁移，或者在目标数据库的负荷低于空闲负荷的期间，分批完成存量数据的迁移。

数据迁移系统对增量数据进行实时迁移，即对于来自业务前端的写指令，采用双数据库写入(即写入源数据库和目标数据库，也称为双写数据库)的方式，因此，一旦存量数据的迁移完成，数据迁移系统随时可以进行数据库的切换，即将源数据库下线，从而使目标数据库代替源数据库上线。

当然，数据迁移系统在进行数据库的切换之前，还可以对迁移的数据进行核对，保证数据库切换后数据的一致性；数据迁移系统可以在数据迁移的过程中尽肯能进行地核对迁移的数据，例如在数据迁移的过程中对已经迁移的数据采用定期核对、不定期核对、或实时核对的方式进行核对，最大程度减少在进行数据库切换时的延迟。

在4A至图4C中，在时刻Ta完成存量数据的迁移，那么，在时刻Ta的任一时刻数据库迁移系统可以进行从源数据库到目标数据库的切换，例如在时刻Tb进行数据库迁移。

在时刻T与时刻Tb之间还可以进行数据核对，例如存量数据和增量数据以天为周期核对，每天对于前一天迁移的数据进行核；又例如，对于存量数据以天为周期核对，对于增量数据进行实时核对，从而可以在增量数据核对后的任意时刻进行实时的数据库切换。

下面结合数据迁移系统的结构对数据迁移系统的上述功能进行说明。

参见图1A，是本发明实施例提供的数据迁移系统100的一个可选的结构示意图，图1A所示的数据迁移系统100可以包括：数据接口110、源数据库服务120、目标数据库服务130和对账服务140；下面分别进行说明。

数据接口110可以用于对接业务前端400，例如可以对接互联网应用(APP)或超文本标记语言版本5(HTML5/H5，HyperText Markup Language 5)的网页等类型的前端，当业务前端400根据运行的业务逻辑需要对业务数据执行读/写操作时，数据接口110将接收来自业务前端400的读/写指令。

数据接口110还可以用于对接业务后台500如结算功能实体、业务推广功能实体等，向业务后台500提供与业务相关数据的查询和写入功能，当业务后台500根据运行的业务逻辑需要对业务数据执行读/写操作时，数据接口110将接收到来自业务后台500的读/写指令。

数据接口110可以能够响应读/写指令的复合接口，也可以分隔读/写处理的单一型接口，参见图1B，是本发明实施例提供的数据迁移系统100的一个可选的结构示意图，所述数据接口110可以包括读数据接口1101和写数据接口1102两种类型，其中读数据接口1101用于响应读指令，写数据接口1102用于响应写入指令，读/写指令区分接口响应能够提升指令响应效率。

源数据库服务120是连接业务前端400和源数据库200的服务，用于支持业务前端400对源数据库200进行读操作/写操作，通过数据接口110接收业务前端400发送的读/写指令，并向业务前端400返回读操作/写操作的结果。

目标数据库服务130是连接业务前端400和目标数据库300的服务，用于支持业务前端400对目标数据库300进行读操作/写操作，通过数据接口110向业务前端400返回读操作/写操作的结果。

对账服务140分别连接源数据库服务120和目标数据库服务130，在目标数据库300代替源数据库200上线以响应来自业务前端400的读/写指令前，对源数据库200和目标数据库300中的数据进行核对的服务，包括对源数据库200中的增量数据进行核对、对目标数据库300中的增量数据进行核对、以及将源数据库200中的存量数据与目标数据库300中的存量数据进行核对。

下面结合数据迁移系统的组件，对增量数据的迁移过程进行说明。

在一个实施例中，在增量数据的迁移阶段，当业务前端400的写指令所操作的目标数据是增量数据时，数据接口110将接收业务前端400通过数据接口110向源数据服务发送在源数据库200中形成增量数据的写指令，以及通过数据接口110向目标数据库服务130发送在目标数据库300中形成增量数据的写指令，从而实现双数据库写入(即写入源数据库200和目标数据库300，也称为双写数据库)的技术效果。

对于源数据库服务120来说，当源数据库服务120从数据接口110接收业务前端400的针对源数据库200写入增量数据的写指令时，作为响应，源数据库服务120将写指令提交到源数据库200，在源数据库200中以所述增量数据的键为索引的存储位置写入所述增量数据的值。

对于目标数据库服务130来说，当目标数据库服务130从数据接口110接收业务前端400的针对目标数据库300写入增量数据的写指令时，作为响应，目标数据库服务130将所述源数据库200中存量数据的键(下文中也称为原始键)转换为新键，所述存量数据的新键用于适配所述目标数据库300；以所述存量数据的新键为索引，在所述目标数据库300中写入所述存量数据的值；将携带增量数据的新键和值的写指令提交到目标数据库300，在目标数据库300中以所述增量数据的新键为索引的存储位置写入所述增量数据的值。

作为示例，目标数据库服务130根据目标数据库300的键的命名规则，包括允许使用的字符、键的长度等，将增量数据的原始键(即在源目标数据库300中的键)转换为新键，通常为了便于转换，采用统一的转换规则，例如对增量数据的原始键统一添加固定长度的字符，以符合目标数据库300系统中键的长度；又例如，对增量数据的新键中不允许出现的特定字符，采用设定的合法字符对原始键中的特定字符进行统一替换，等等。

作为示例，就数据接口110接收的在源数据库200中形成增量数据的写指令来说，包括如下几种情况：

情况1)在分界时间点之后，业务前端400需要在源数据库200写入新数据。

例如对于在视频业务，视频APP在源数据库200中记录新注册用户所拥有的券，其中键是用于索引用户的序列号，记为vipid，索引的值是新注册用户所拥有的券(例如折扣券、抵价券)。

情况2)业务前端400需要修改在分界时间点之后向源数据库200写入的数据。

仍以在线视频业务为例，视频APP在源数据库200中修改记录注册用户所拥有的券，其中键是用于索引用户的序列号(ID，IDentity)，记为vipid，值是修改后用户所拥有的券。

情况3)业务前端400需要删除在分界时间点之后向源数据库200写入的数据。

仍以在线视频业务为例，视频APP在源数据库200中删除注册用户所拥有的券，其中键是用于索引用户的序列号，记为vipid，值为空，表示注册用户名下没有券。

在一个实施例中，业务前端400采用同步或异步的方式，向源数据库200以及目标数据库300发送写指令；相应地，数据接口110接收来自业务前端400的在源数据库200中形成增量数据的写指令、以及针对在目标数据库300中形成增量数据的写指令时，可以是同步接收，也可以是异步接收。

当同步接收写指令时，由于源数据库200与目标数据库300会同步响应写指令，源数据库200与目标数据库300状态同步的一次成功率将显著提升；当然，即使异步接收写指令导致源数据库200与目标数据库300出现状态不同步的情况，源数据库200和目标数据库300可以尝试重新同步，直至增量数据的状态同步为写入成功。

就写指令的类型而言，包括在相应的存储位置执行以下一种类型的操作：增加、修改和删除。

以源数据库200记录在线视频业务的数据为例，在增量数据的迁移阶段，如果用户在购买付费业务时使用了券，视频APP通过数据接口110向源数据库服务120和目标数据库服务130发送修改类型的写指令，其中携带的键为用户在视频后台的用户序列号，记为vipid，值为“-1”，表示将记录的用户vipid的券的数量减少1张。

再以源数据库200记录在线视频业务的数据为例，在增量数据的迁移阶段，业务后台500进行付费业务的推广，向重要(VIP，Very Important Person)赠送付费业务的券(例如折扣券、抵扣券等)，业务后台500将通过数据接口110向源数据库服务120和目标数据库300发送增加类型的写指令，其中携带的键为用户在视频后台的用户序列号，记为vipid，值为“+1”，表示将记录的用户vipid增加1张券。

在相关技术提供的数据迁移技术中，对于在分界时间点后业务前端400需要写入数据库的情况，业务前端400总是提交单数据库(即源数据库200)的写指令，并在源数据库200下线前，才将源数据库200中的增量数据一次性或分批迁移到目标数据库300，这会导致数据迁移出现不可避免的延迟，尤其是对于目前大数据的应用业务。

本发明实施例中采用增量数据双数据库写入的方案，通过同步或异步写入两个数据库的方式，将增量数据的迁移分解在数据写入的过程中完成，源数据库200下线后目标数据库300可以即时上线，实现了从源数据库200到目标数据库300的无缝迁移，响应业务前端400的实时性能具有良好的稳定性，不会因数据迁移而出现抖动。

在增量数据的迁移阶段，还涉及业务前端400读取增量数据、读取存量数据以及写存量数据的情况，下面分别进行说明。

在一个实施例中，在增量数据的迁移阶段，当业务前端400需要读取业务的相关数据例如增量数量或者存量数据时，数据接口110将接收到业务前端400经由数据接口110向源数据库服务120提交的读指令，由源数据库服务120在源数据库200中以键索引的存储位置，读取对应的值并通过数据接口110返回业务前端400。

由于增量数据迁移阶段目标数据库300尚在构建和初步使用的阶段，因此利用源数据库200响应读指令，能够减小利用目标数据库300响应读指令遇到异常的情况，实现从源数据库200到目标数据库300平滑过渡的技术效果。

在一个实施例中，在增量数据的迁移阶段，对于业务前端400的写指令所操作的目标数据是存量数据的情况，业务前端400将只通过数据接口110向源数据库服务120发送写指令，携带存量数据的键和值，由源数据库服务120在源数据库200中以键索引的存储位置写入对应的值；此外，还可以向业务前端400返回写入成功确认。

例如，源数据库服务120向源数据写入以及向业务前端400返回写入成功确认可以是同步的，即在写入源数据库200的同时，向业务前端400返回写入成功确认，从而能够提升业务前端400的写入响应效率。

当然，源数据库服务120向源数据写入以及向业务前端400返回写入成功确认可以是异步的，例如先向源数据库200写入然后返回写入成功确认，或者，先向业务前端400返回写入成功确认，然后写入源数据库200。

如上所述，由于源数据库200的存量数据是分界时间点之前的数据，而迁移数据的一个典型的情况是容量升级，因此通常情况下存量数据的数据量远大于增量数据，如果存量数据采取增量数据同样的双数据库写入的方式，将导致很大的资源消耗，因此，在增量数据的迁移阶段，对于存量数据的写指令采用单数据库写入的方式，将有效实现数据迁移时的资源集约、以及写入的可靠性。

继续结合数据迁移系统的组件说明存量数据的迁移过程。

在一个实施例中，在存量数据的迁移阶段，目标数据库服务130将所述源数据库200中存量数据的键转换为新键，所述存量数据的新键用于适配所述目标数据库300；以所述存量数据的新键为索引，在所述目标数据库300中写入所述存量数据的值。

例如，目标数据库300一次性存量数据迁移到目标数据库300，又例如，根据在目标数据库300的负荷低于空闲负荷的期间，将存量数据迁移到目标数据库300，在不影响增量数据迁移的前提下完成存量数据的迁移。

由于数据库运行过程中各种不可控因素，在增量数据双写到数据库的过程中，可能存在数据写入失败的情况，为了保证增量数据在源数据库200和目标数据库300总是成功写入，避免数据写入失败问题，本发明实施例提供对增量数据迁移后的状态同步的方案，下面进行说明。

在增量数据的迁移阶段，目标数据库服务130以源数据库200中的增量数据的状态为准，实时地将所述源数据库200中的增量数据与所述目标数据库300中的增量数据进行状态同步，需要指出，增量数据的状态以在源数据库200中的状态为准，将有助于克服目标数据库300尚在构建和初步使用的阶段而出现的不稳定的情况。而数据写入数据库是存在写入成功和写入失败的情况，对于增量数据的源数据库200与目标数据库300进行状态同步时，存在如表1所示的几种情况：

表1

在情况1)中和情况2)中，增量数据在源数据库200和目标数据库300中取得了一致的状态，但是在情况2)中取得了一致的写入失败的状态，对于写入失败的增量数据，源数据库服务120将尝试重新写入源数据库200直至写入成功，目标数据库300将尝试重新写入目标数据库300直至写入成功，并继续同步增强数据的状态直至为同步为写入成功的状态。

在情况3)和情况4)中，写入失败的源数据服务/目标数据库服务130将尝试重新写入，直至源数据服务同步源数据库200中的增量数据的状态，与源数据库200中增量数据的状态均为写入成功。

在增量数据的迁移过程中，除了同步增量数据在源数据库200和目标数据库300中的同步状态，还可以对写入数据库的增量数据的值进行核对以保证增量数据的完全一致，以保证数据的一致性；当然，在存在数据的迁移过程中，也可以将存量数据在源数据库200中的值，与存量数据在目标数据库300中的值进行核对，以确定存量数据的一致性，下面分别进行说明。

需要指出，由于增量数据和存量数据没有依赖关系，因此增量数据的核对与存量数据的核对没有依赖关系，两种数据的核对可以同步、异步或交错进行。

就存量数据核对的时间而言，可以是随机性地，也可以是周期性地，例如，在分界时间点之后定期或不定期地设置有核对时间点，在时间轴上相邻的核对时间点形成一个核对周期，核对周期的长度反映了核对存量数据的实时性程度(二者负相关，即核对周期越短，实时性程度越高)；当存量数据的核对周期的计时到达时，对账服务140将以将所述目标数据库300中在所述核对周期内迁移的存量数据，与所述源数据库200在所述核对周期内写入的存量数据进行核对。

此外，核对周期还可以是一次性的，即当源数据库200中的存量数据全部迁移到目标数据库300时，才识别为核对周期的计时时间到达，将源数据库200中的存量数据与目标数据库300中的存量数据进行一次性的核对。

作为核对存量数据的一个示例，对于核对周期内迁移的存量数据而言，对账服务140根据源数据库200与目标数据库300的键转换关系，将所述源数据库200中待核对数据的键转换为新键，使转换的新键能够适配所述目标数据库300，从而能够查询到目标数据库300中新键索引的值，将所述目标数据库300中以所述新键索引的待核对数据的值，与所述源数据库200中对应的值进行核对，如果一致则表示核对成功；如果不一致，则以源数据库200中的键为准，调整目标数据库300中新键索引的值与源数据库200的值一致；以源数据库200在核对周期内迁移的存量数据为基准核对，能够避免在目标数据库300构建和初步使用的阶段出现的数据写入错误的问题，确保数据的一致性。

就增量数据的核对而言，对账服务140定期或不定期从订服务扫描分界时间点之后的订单流水，所述订单流水为在分界时间点之后产生订单的按照先后时间顺序的记录，例如以小时、天为单位进行扫描，利用扫描的订单流水与源数据库200中的增量数据进行核对，并利用订单流水与目标数据库300中的增量数据进行核对；定期或不定期扫描订单流水并进行核对，能够避免当源数据库200准备下线前才进行全部增量数据的扫描导致数据库切换的延迟。

作为扫描的订单流水与源数据库200中的增量数据进行核对的示例，对账服务140根据在每天扫描的订单流水，提取订单中的用户ID，将用户ID作为键，向源数据库200中的提交查询，将查询到的值与订单流水中的值核对，如果不一致，则向源数据库服务120提交写指令，将用户ID索引的存储位置存储的值修改为订单流水中对应的值。

作为扫描的订单流水与目标数据库300中的增量数据进行核对的示例，对账服务140根据在每天扫描的订单流水，提取订单中的用户ID，将用户ID作为键，根据源数据库200与目标数据库300的键转换规则，将用户ID转换为新键，向目标数据库300中的提交查询新键索引的值，将查询到的值与订单流水中的值核对，如果不一致，则向目标数据库服务130提交写指令，将用户ID索引的值修改为订单流水中对应的值。

至此，已经说明了增量数据和存量数据核对，需要指出，由于增量数据是在数据库的运行过程中不断产生的，因此只有当目标数据库300代替源数据库200在线(即目标数据库300下线)时，增量数据的迁移阶段才会终止。

例如在图4A至图4C中，对于在分界时间点(记为时刻T)之后的时刻Ta，源数据库200的存量数据(即创建时间在时刻T之后的数据)都迁移到目标数据库300，并且截止到时刻Tb已经成功核对时，那么在时刻Tb可以进行从源数据库200到目标数据库300的切换，由目标数据库300代替源数据库200上线，目标数据库300将单独响应业务前端400的读/写指令。

下面，对在增量数据以及存量数据核对完成后，源/目标数据切换(也就是源数据库200下线以及目标数据库300替代源数据库200上线，以响应业务前端400的读/写指令)过程进行说明。

在图1A中，当所述目标数据库300中的数据与所述源数据库200中的数据核对一致时，数据接口110还用于将所述数据接口110与源数据库服务120的对接，切换为所述数据接口110与目标数据库服务130的对接。

以图1B中的读数据接口1101和为例，读数据接口1101用于将所述读数据接口1101与源数据库服务120的对接，切换为所述读数据接口1101与目标数据库服务130的对接；其中，所述读数据接口1101用于响应来自所述业务前端400的读指令。

以图1B中的写数据接口1102和为例，写数据接口1102用于将所述写数据接口1102与源数据库服务120的对接、以及写数据接口1102与目标数据库服务130的对接，切换到所述写数据接口1102与所述目标数据库300的对接；所述写数据接口1102用于响应来自所述业务前端400的写指令。

在一个实施例中，参见图1B，数据迁移系统还可以包括订单服务150，订单服务150用于记录写指令对应的订单流水，包括生成时间、用户ID(对应键)、业务数据(对应值，如券的数量等)等字段。订单服务150通过连接源数据库服务120和目标数据库服务130，提供订单校验功能，即根据待查询的写指令查询是否已经存在对应的订单，并且，对于未查询到对应的订单的情况，订单服务150会根据待查询的写指令生成新的订单。

例如，订单服务150订单根据源数据库服务120或目标数据库300提交写指令携带的键(例如用户ID)查询订单流水，如果查询到包括用户ID的订单，说明存在重复订单，属于重复写入的情况，如果未查询到则说明未有重复订单，并针对提交的写指令生成新的订单，从而能够校验新的重复订单。

源数据库服务120和目标数据库服务130根据订单校验的结果，能够避免源数据库服务120和目标数据库服务130重复写入的情况，典型地，用户只有一张券时，重复使用券的写指令将无法通过订单校验；业务后台500针对VIP用户赠送一张券时，重复赠送的写指令将无法通过订单校验，下面就源数据库服务120和目标数据库服务130使用订单校验的过程进行说明。

就源数据库服务120来说，当源数据库200在线时，例如在增量数据的迁移阶段，如果源数据库服务120接收到在源数据库200中形成增量数据的写指令，则调用所述订单服务150对在源数据库200形成增量数据的写指令进行订单校验；当通过订单校验未存在与所述写指令对应的重复订单时，则在所述源数据库200中写入所述增量数据的值；如果存在与写指令对应的重复订单，那么通过数据接口110向业务前端400返回出错信息。

就目标数据库300来说，如果处于增量数据的迁移阶段，即目标数据库300还未替代源数据库200而上线，当目标数据库300接收到在目标数据库300形成所述增量数据的写指令时，写指令将携带第一类型标签(记为tag1)，第一类型标签用于指示对相应的写指令忽略调用订单服务150。目标数据库300解析到第一类型标签时，将跳过调用订单服务150，即不做订单校验，直接在所述目标数据库300中写入所述增量数据的值。

在增量数据的迁移阶段，增量数据采用了双写数据库的方案，增量数据的校验由源数据库200完成，目标数据库300不做订单校验而直接入库，一方面保证了数据写入的正确性，另一方面避免了对订单服务150的不必要调用，节约系统资源。

就目标数据库300来说，如果处于上线阶段，即目标数据库300替代源数据库200上线而单独响应业务前端400的读/写指令时，还用于当所述目标数据库300代替所述源数据库200上线时，接收所述目标数据库300中形成新数据的写指令，所接收的写指令将携带第二类型标签(记为tag2)，用于指示调用订单服务150；目标数据库300解析到第二类型标签时，将调用订单服务150进行订单校验，校验成功后入库存储，如果校验为重复订单，则向业务前端400返回出错信息。

继续说明实现本发明实施例的数据迁移系统的结构。

参见图2，是本发明实施例提供的数据迁移系统100的一个可选的结构示意图，图2所示的数据迁移系统包括：至少一个处理器150、至少一个通信总线160、用户接口180、至少一个网络接口170和存储器190。数据迁移系统100中的各个组件通过通信总线160耦合在一起。可以理解，通信总线160用于实现这些组件之间的连接通信。通信总线160除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为通信总线160。

其中，用户接口180可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按钮、触感板或者触摸屏等。网络接口170可以包括标准的有线接口、无线接口可以是WiFi接口。

可以理解，存储器190可以是高速RAM存储器，也可以是非不稳定的存储器(Non-Volatile Memory)，例如至少一个磁盘存储器。存储器190还可以是至少一个在物理位置上远离处理器150的存储系统。

本发明实施例提供的应用于数据迁移系统的数据迁移方法可以应用于处理器150中，或者由处理器150实现。处理器150可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，应用于数据迁移系统的数据迁移方法中的不同操作可以通过处理器150中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器150可以是通用处理器、DSP或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器150可以实现或者执行本发明实施例应用于数据迁移系统的数据迁移方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本发明实施例所提供的应用于数据迁移系统的数据迁移方法，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。

作为示例，软件模块可以位于存储介质中，存储介质可以是如图2示出的存储器190，处理器150读取存储器190中的信息，结合其硬件完成本发明实施例提供的应用于数据迁移系统的数据迁移方法，包括如图1A示出的数据接口110、源数据库服务120、目标数据库服务130和对账服务140；当然，数据接口110还可以包括如图1B示出的读数据接口1101和写数据接口1102，还可以包括如图1B示出的订单服务150。

至此已经说明了实现本发明实施例的数据迁移系统，下面再结合数据库迁移系统进行增量数据迁移、存量数据迁移、数据核对以及数据库切换的流程进行说明。

参见图5，是本发明实施例提供的增量数据迁移的流程示意图，将结合各个步骤进行说明。

步骤101，业务前端通过数据接口向源数据库服务发送写指令，用于在源数据库形成增量数据。

增量数据包括在所述源数据库中对应的键和值。

步骤102，源数据库服务调用订单服务对在源数据库形成增量数据的写指令进行订单校验。

步骤103，当订单服务通过订单校验确定未存在与所述写指令对应的重复订单时，源数据库服务以所述增量数据的键为索引，在源数据库中写入所述增量数据的值。

步骤104，当订单服务通过订单校验确定存在与所述写指令对应的重复订单时，目标数据库服务通过数据接口向业务前端的返回重复订单的错误信息。

步骤105，业务前端通过数据接口向目标数据库发送写指令，用于在目标数据库中形成所述增量数据。

步骤106，目标数据库服务以所述键在所述目标数据库中对应的新键为索引，在所述目标数据库中写入所述增量数据的值。

步骤107，目标数据库服务将所述目标数据库中的增量数据与所述源数据库中的增量数据进行状态同步。

作为同步的示例，所述增量数据的状态包括写入成功和写入失败的情况，目标数据库服务以所述增量数据在所述源数据库中的状态为基准，调整所述目标数据库中增量数据进行同步；当同步后任一方的增量数据的状态为写入失败时，重试写入直至写入成功，从而实现增量数据在两个数据库的状态一致。

需要指出，业务前端执行步骤101和步骤103实现数据库双写可以是同步的，也可以是异步的，步骤101和步骤03的执行先后顺序不会影响根据步骤107的增量数据的状态最终达到写入成功的一致状态。

需要指出，步骤101至步骤107记载的以业务前端向进行数据库双写并进行状态同步的方案，同样适用于业务后台进行数据库双写并进行状态同步的情况。

参见图6，是本发明实施例提供的存量数据迁移的流程示意图，将结合各个步骤进行说明。

步骤201，源数据库服务将所述源数据库中存量数据的键转换为新键，所述存量数据的新键用于适配所述目标数据库。

步骤202，源数据库服务以所述存量数据的新键为索引，在所述目标数据库中写入所述存量数据的值。

当所述目标数据库中的增量数据与所述源数据库中的增量数据进行状态同步完成时，数据迁移系统还可以进行数据的核对，参见图7，是本发明实施例提供的数据核对的流程示意图，将结合各个步骤进行说明。

步骤301，对账服务基于在分界时间点后的订单流水，与所述目标数据库中的增量数据进行核对。

步骤302，对账服务基于在所述分界时间点后的订单流水，与所述源数据库中的增量数据进行核对。

所述订单流水为在分界时间点之后产生订单的按照先后时间顺序的记录。

步骤303，当所述源数据库中的存量数据迁移到所述目标数据库时，对账服务将所述目标数据库中的存量数据与所述源数据库中的存量数据进行核对。

作为对存量数据进行核对的示例，将所述源数据库中待核对数据的键转换为新键，将所述目标数据库中以所述新键索引的待核对数据的值，与所述源数据库中对应的值进行核对。

当所述目标数据库中的数据与所述源数据库中的数据核对一致时，数据迁移系统还可以进行数据的核对，将数据接口与源数据库服务的对接，切换为所述数据接口与目标数据库服务的对接；其中，所述数据接口用于响应业务前端的读指令或写指令。参见图8，是本发明实施例提供的数据库切换的流程示意图，将结合各个步骤进行说明。

步骤401，读数据接口将读数据接口与源数据库服务的对接，切换为所述读数据接口与目标数据库服务的对接；其中，所述读数据接口用于响应所述业务前端的读指令。

步骤402，写数据接口将写数据接口与源数据库服务的对接、以及写数据接口与目标数据库服务的对接，切换到所述写数据接口与所述目标数据库的对接；其中，所述写数据接口用于响应所述业务前端的写指令。

在数据库切换的过程中，读数据接口执行步骤401、以及写数据接口执行步骤402不存在先后顺序的限制。

步骤403，目标数据库服务器通过写数据接口从业务前端接收在所述目标数据库中形成新数据的写指令，所接收的写指令携带第二类型标签，用于指示调用订单服务。

步骤404，目标数据库服务调用订单服务校验是否存在与写指令对应的重复订单。

步骤405，当订单服务通过订单校验存在与所述写指令对应的重复订单时，目标数据库服务通过写数据接口向业务前端返回出错信息。

步骤406，当订单服务通过订单校验未存在与所述写指令对应的重复订单时，写数据接口通过目标数据库服务向目标数据库中写入所述新数据。

至此，已经说明了数据迁移系统进行增量数据迁移、存量数据迁移、数据核对以及数据库切换的流程，下面，再以在线视频播放业务后端的数据库迁移为例，说明实现本发明实施例的数据库迁移过程。

在线视频播放业务的运营过程中，需要在后台的数据库以VIP用户的ID为键(记录用户的业务数据，例如用户的券。数据库记录业务后台向VIP用户赠送的券，同时根据业务前端的订单修改VIP用户所拥有的券。

在视频业务的运营过程中，后台的数据库的存储的数据不断增长，数据库不足以在满足服务质量，数据迁移系统需要将旧数据库(作为源数据库)中的数据迁移到新数据库(作为目标数据库)，对迁移的数据核对后，旧数据库下线，目标数据库上线，新数据库将单独响应业务前端和业务后台的读/写指令。

参见图9，是本发明实施例提供的数据迁移系统从旧数据库向新数据库迁移数据的一个可选架构示意图。

在线视频业务在分界时间点之前产生的订单的记录为旧订单流水，在分界时间点之前的期间，旧数据库单独在线，业务前端/后台根据旧订单流水对应的写指令在旧任务表中排队，由旧数据库服务采用先入先出的方式在旧数据库中写入以vipid索引的值如券的类型和数量，即为存量数据。旧数据库服务写入存量数据前还调用订单服务进行重复订单校验，避免重复入库。

在进行数据迁移时，数据迁移系统实现以下五个部分的功能。

1)增量数据的迁移，通过数据库双写，增量数据以同步或异步的方式写入旧数据库和新数据库，订单服务对旧数据库入库前进行订单校验，不存在重复订单时增量数据入旧数据库存储。

2)增量数据对账，对账服务全量扫描每天新产生的订单流水，利用每天的订单流水对旧数据库中的增量数据进行核对，利用每天的订单流水对新数据库中的增量数据进行核对。

3)存量数据迁移，扫描服务每月扫描旧VIP用户表(即分界时间点之前创建的VIP用户的表)，将vipid转换对应的新键vuid，由新数据库服务在新数据库中写入以vuid索引的值。

4)存量数据对账，对账服务定期如每月核对旧数据库中以vipid索引的值与新数据库中vipdi索引值。

5)数据库平滑切换，业务前端/后台通过数据接口与旧数据库的对接，切换到通过数据接口与新数据库的对接。

在线视频业务在分界时间点之后产生的订单的记录为新订单流水，在分界时间点之后的期间，旧数据库下线，新数据库单独在线，业务前端/后台根据新订单流水对应的写指令在旧任务表中排队，由新数据库服务采用先入先出的方式在新数据库中写入以vuid索引的值如券的类型和数量。新数据库服务写入存量数据前还可以调用订单服务进行重复订单校验，避免重复入库。

下面再对上述五个部分进行说明。

1)增量数据的迁移

参见图10，是本发明实施例提供的数据迁移系统在实现增量数据迁移的示意图。

在增量数据的迁移阶段，针对VIP用户的券进行修改、增加和删除的写指令，将经由数据被同步发送到新数据库服务和目标数据库服务，采用数据库双写的方式，在新数据库和旧数据库入库存储。

数据接口可以实施为接收读/写指令的服务，可以读/写的复合型接口，兼容响应读指令和写指令，也可以是单一的读接口(响应读指令)或单一的写接口(响应写指令)，由于写指令是用于修改数据库中用户所拥有的券，因此写指令也称为写券操作。

就针对旧数据库的写指令而言，携带欲赠送券/修改券的VIP用户的ID(记为vipid)以及VIP用户的券的信息。

例如，数据接口包括对接业务后台的开通送券服务和按月送券服务，开通送券服务用于支持业务后台向初次开通VIP业务的用户赠送券，按月送券服务用于支持业务后台按月向VIP用户赠送券，赠送的券可以用于付费业务的折扣或减免。

针对旧数据库的写指令而言，在旧任务表中以先入先出的顺序排队，由旧数据库服务向数据库提交写指令，在旧数据库中以vipid索引的存储位置写入券的类型和数量。

针对新数据库的写指令而言，在旧任务表中以先入先出的顺序排队，由旧数据库服务向数据库提交写指令，在旧数据库中以vipid索引的存储位置写入券的类型和数量。

又例如，数据接口可以包括对接业务前端的网页端写服务和移动客户端(APP)写服务，网页端写服务用于当用户通过H5网页购买在线视频业务的付费服务(例如月度会员)并使用券时，将使用公共网关接口(CGI，Common Gateway Interface)响应来自网页版的视频播放器的写指令，修改用户所拥有的券的数量；移动客户端服务用于当用户通过视频APP购买在线视频业务的付费服务(例如月度会员)并使用券时，响应来自视频客户端的写指令，修改用户所拥有的券的数量。

在写新数据库时，写指令携带tag1，订单服务将对写指令忽略进行订单校验，因为针对源数据库的写指令已经就相同的订单进行了校验，重复校验一方面会导致订单出错，另一方面会导致写入的不必要延迟，由目标数据库服务直接将vuid和券的信息写入新数据库。

参见图11，是本发明实施例提供的数据迁移系统实现增量数据迁移流程的示意图，在增量数据的迁移过程中，当通过数据接口向新数据库和旧数据库写入数据时，向新/旧数据库写入数据、以及向数据接口返回写入成功确认(通过返回一个数据包来确认，因此也称为回包)的顺序可以相同，也可以不同。

例如，当业务后台通过数据接口向VIP用户赠送一张券，或者当VIP用户在视频APP购买付费业务并使用券抵扣费用时，涉及到向旧数据库和新数据库写入券的数据。

向旧数据库写入券的数据为旧键值，包括键(vipid)和值(即券的信息)，首先将旧键值写入旧数据库然后先数据接口返回写入成功确认；向新数据库写入券的数据为新键值，包括键(vuid)和值(即券的信息)，首先向数据接口返回写入成功确认，然后将新键值写入新数据库，这样可以避免用于写入新数据库延迟导致用户等待，具有良好的实时性。

当增量数据写入新数据库和旧数据库后，以旧数据库的状态为准，将新数据库中数据的状态进行同步；如果写入旧数据库失败则会重试写入直至写入成功，从而，确保数据在最终在新数据库和旧数据库均写入成功。

以旧数据库中的增量数据在为准是基于这样的考虑，旧数据库是稳定运行一段时间的，迁移到新数据库时，由于新数据库在重构、初步使用的阶段，以旧数据库为准进行核对，相对于以新数据库为基准,更能够保证数据的正确性。

2)增量数据对账

参见图12，是本发明实施例提供的增量数据核对的示意图，对账服务实时读取旧订单流水，将旧订单流水中的用户ID(即vipid)和券的信息，与旧数据库中的vipid索引的数据进行核对；将旧订单流水中的用户ID即vipid转换为vuid，与新数据库中的vuid索引的数据进行核对。

3)存量数据迁移

参见图13，是本发明实施例提供的存量数据核对的示意图，将旧数据库中创建于分界时间点之前的数据(即存量数据)保存的用户的ID(vipid)，根据键转换关系，转换为适配在新数据库中使用的ID(即vuid)，在新数据库中以vuid索引的存储位置写入。

4)存量数据对账

全量扫描旧数据库中在分界时间点之后修改过的存量数据，将新数据库中对应的数据与修改过的存量数据进行核对。

5)数据库切换

增量数据和存量数据的对账完成之后，所有的数据接口从旧数据库服务切换到新数据库服务。

参见图14，是本发明实施例提供的数据库切换时读数据接口切换的示意图，以用于响应读指令的数据接口为例，可以包括电视端读服务和网页端读服务，电视端/网页端读服务与旧数据库的对接关闭，并与新数据库服务对接，用户通过电视或网页查询所拥有的券时，对应的读指令将由新数据库响应。

参见图15，是本发明实施例提供的数据库切换时写数据接口切换的示意图，以用于响应写指令的数据接口为例，可以包括电视端写服务和网页端写服务，电视端/网页端写服务与旧数据库的对接关闭，并与新数据库服务对接，用户通过电视或网页使用券购买视频播放业务的付费服务时，需要修改用户的券，对应的写指令将由新数据库响应。

需要指出，在数据切换前的增量数据迁移阶段，电视端/网页端写服务写券时，旧新数据库发送的写指令，旧数据库服务将调用订单服务进行重复订单校验，避免重复入库；而电视端/网页端写服务向新数据库发送的写指令携带tag1，新数据库服务将根据tag1忽略进行订单校验而直接入库。

在数据库切换后，电视端/网页端写服务向新数据库服务发送的写指令携带tag2，新数据库服务将调用订单服务进行订单校验，校验是否有ID为vuid的用户的重复订单，如果没有重复订单，则在新数据库以vuid索引的存储位置写入券的信息，从而避免订单的重复写入。

综上所述，本发明实施例具有以下有益效果：

1)增量数据在形成时通过源数据库和目标数据库的写指令分别写入，避免了相关技术进使用源数据库响应写指令、并将增量数据累积后向目标数据库迁移而影响迁移的效率的问题。

2)向目标数据库写入时通过将增量数据在源数据库中的键进行转换，使得增量数据的新键能够适配目标数据库，巧妙克服了数据直接迁移不兼容的问题，实现平滑迁移数据的技术效果。

3)在增量数据迁移阶段，通过第一类型标签避免了订单的重复校验以及重复写入，提升了数据写入的效率和准确性；在数据库切换后，通过第二类型标签使新数据库进行订单校验，

4)增量数据的迁移实时地在源数据库和目标数据库之间进行，因此一旦存量数据的迁移完成，数据库即可进行无缝切换。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (15)

1.一种数据迁移方法，其特征在于，包括：

接收在源数据库形成增量数据的写指令，所述增量数据包括在所述源数据库中对应的键和值；

以所述增量数据的键为索引，在源数据库中写入所述增量数据的值；

接收在目标数据库中形成所述增量数据的写指令；

以所述键在所述目标数据库中对应的新键为索引，在所述目标数据库中写入所述增量数据的值；

将所述目标数据库中的增量数据与所述源数据库中的增量数据进行状态同步。

2.根据权利要求1所述的方法，其特征在于，所述将所述目标数据库中的增量数据与所述源数据库中的增量数据进行状态同步，包括：

所述增量数据的状态包括写入成功和写入失败；

以所述增量数据在所述源数据库中的状态为基准，调整所述目标数据库中增量数据进行同步，以及，

当所述增量数据在所述源数据库中的状态为写入失败时，重试写入直至写入成功。

3.根据权利要求1所述的方法，其特征在于，还包括：

将所述源数据库中存量数据的键转换为新键，所述存量数据的新键用于适配所述目标数据库；

以所述存量数据的新键为索引，在所述目标数据库中写入所述存量数据的值。

4.根据权利要求1所述的方法，其特征在于，还包括：

当所述目标数据库中的增量数据与所述源数据库中的增量数据进行状态同步完成时，

将所述目标数据库中的数据与所述源数据库中的数据进行核对。

5.根据权利要求4所述的方法，其特征在于，所述将所述目标数据库中的数据与所述源数据库中的数据进行核对，包括：

基于在分界时间点后的订单流水，与所述目标数据库中的增量数据进行核对，以及，

基于在所述分界时间点后的订单流水，与所述源数据库中的增量数据进行核对；

其中，所述订单流水为在分界时间点之后产生，所述分界时间点用于根据创建时间界定所述存量数据和所述增量数据。

6.根据权利要求4所述的方法，其特征在于，所述将所述目标数据库中的数据与所述源数据库中的数据进行核对，包括：

当所述源数据库中的存量数据迁移到所述目标数据库时，

将所述目标数据库中的存量数据与所述源数据库中的存量数据进行核对。

7.根据权利要求4所述的方法，其特征在于，所述将所述目标数据库中的数据与所述源数据库中的数据进行核对，包括：

将所述源数据库中待核对数据的键转换为新键，所述待核对数据的新键用于适配所述目标数据库；

将所述目标数据库中以所述新键索引的待核对数据的值，与所述源数据库中对应的值进行核对。

8.根据权利要求1所述的方法，其特征在于，还包括：

当所述目标数据库中的数据与所述源数据库中的数据核对一致时，

将数据接口与源数据库服务的对接，切换为所述数据接口与目标数据库服务的对接；

其中，所述数据接口用于响应业务前端的读指令或写指令。

9.根据权利要求8所述的方法，其特征在于，所述将数据接口与源数据库服务的对接，切换为所述数据接口与目标数据库服务的对接，包括：

将读数据接口与源数据库服务的对接，切换为所述读数据接口与目标数据库服务的对接；

其中，所述读数据接口用于响应所述业务前端的读指令。

10.根据权利要求8所述的方法，其特征在于，所述将数据接口与源数据库服务的对接，切换为所述数据接口与目标数据库服务的对接，包括：

将写数据接口与源数据库服务的对接、以及所述写数据接口与目标数据库服务的对接，切换为所述写数据接口与所述目标数据库的对接；

其中，所述写数据接口用于响应所述业务前端的写指令。

11.根据权利要求1所述的方法，其特征在于，所述在源数据库中写入所述增量数据的值，包括：

调用订单服务对在源数据库形成增量数据的写指令进行订单校验；

当通过订单校验未存在与所述写指令对应的重复订单时，在所述源数据库中写入所述增量数据的值。

12.根据权利要求1所述的方法，其特征在于，所述在所述目标数据库中写入所述增量数据的值，包括：

所述在目标数据库形成所述增量数据的写指令携带第一类型标签，所述第一类型标签用于指示对相应的写指令忽略调用订单服务；

跳过调用订单服务，并在所述目标数据库中写入所述增量数据的值。

13.根据权利要求1所述的方法，其特征在于，还包括：

当所述目标数据库代替所述源数据库上线时，

接收所述目标数据库中形成新数据的写指令，所接收的写指令携带第二类型标签，用于指示调用订单服务；

当通过订单校验未存在与所述写指令对应的重复订单时，在所述目标数据库中写入所述新数据。

14.一种数据迁移系统，其特征在于，包括：

数据接口，用于接收在源数据库形成增量数据的写指令，所述增量数据包括在所述源数据库中对应的键和值；

源数据库服务，用于以所述增量数据的键为索引，在所述源数据库中写入所述增量数据的值；

所述数据接口，用于接收在目标数据库中形成所述增量数据的写指令；

所述目标数据库服务，用于以所述键在所述目标数据库中对应的新键为索引，在所述目标数据库中写入所述增量数据的值；

所述目标数据库服务，用于将所述目标数据库中的增量数据与所述源数据库中的增量数据进行状态同步。

15.一种存储介质，其特征在于，存储有计算机程序，所述计算机程序被处理器执行时，用于实现权利要求1至13任一项所述的数据迁移方法。