发明内容
有鉴于此,本说明书一个或多个实施例提供一种数据迁移方法和装置,以在迁移状态型数据时降低对业务的影响。
具体地,本说明书一个或多个实施例是通过如下技术方案实现的:
第一方面,提供一种数据迁移方法,所述方法用于将源数据库的状态型数据迁移到目标数据库,所述状态型数据是动态更新的数据;所述方法包括:
第一应用服务接收数据更新请求,所述数据更新请求用于请求对源数据库的状态型数据进行更新;所述源数据库用于接收存储第一应用服务获得的数据;
所述第一应用服务开启事务模板记录对应本次更新操作的更新数据,所述更新数据包括:所述状态型数据的最新值,并将所述更新数据同步至消息中心;
所述第一应用服务在接收到消息中心返回的同步成功通知后,将所述事务模板记录的更新数据提交至源数据库,以使得源数据库更新对应的状态型数据;
所述消息中心将所述更新数据发送至第二应用服务,由第二应用服务将所述更新数据发送至目标数据库;所述目标数据库用于接收存储第二应用服务获得的数据;所述第一应用服务和第二应用服务属于同一应用系统。
第二方面,提供一种数据迁移系统,所述系统用于将源数据库的状态型数据迁移到目标数据库,所述状态型数据是动态更新的数据;所述系统包括:
第一应用服务,用于接收数据更新请求,所述数据更新请求用于请求对源数据库的状态型数据进行更新;所述源数据库用于接收存储第一应用服务获得的数据;开启事务模板记录对应本次更新操作的更新数据,所述更新数据包括:所述状态型数据的最新值,并将所述更新数据同步至消息中心;在接收到消息中心返回的同步成功通知后,将所述事务模板记录的更新数据提交至源数据库,以使得源数据库更新对应的状态型数据;
消息中心,用于在接收到第一应用服务发送的更新数据后,在存储成功后向第一应用服务返回同步成功通知;并将更新数据发送至第二应用服务;所述第一应用服务和第二应用服务属于同一应用系统;
第二应用服务,用于将更新数据发送至目标数据库,所述目标数据库用于接收存储第二应用服务获得的数据。
第三方面,提供一种业务处理设备,所述设备包括存储器、处理器,以及存储在存储器上并可在处理器上运行的计算机指令,所述处理器执行指令时实现以下步骤:
接收向源数据库的数据更新请求,所述数据更新请求用于请求对源数据库的状态型数据进行更新;
开启事务模板记录对应本次更新操作的更新数据,所述更新数据包括:状态型数据的最新值,并将所述更新数据同步至消息中心;
在接收到消息中心返回的同步成功通知后,将所述事务模板记录的更新数据提交至源数据库,以使得源数据库更新对应的状态型数据。
第四方面,提供一种消息中心设备,所述设备包括存储器、处理器,以及存储在存储器上并可在处理器上运行的计算机指令,所述处理器执行指令时实现以下步骤:
接收第一应用服务发送的更新数据,所述更新数据包括:第一应用服务根据对源数据库的状态型数据进行更新的请求得到的所述状态型数据的最新值;
向所述第一应用服务返回同步成功通知,以使得第一应用服务将所述事务模板记录的更新数据提交至源数据库;
在接收到源数据库发送的处理成功通知时,将所述更新数据发送至第二应用服务,以使得第二应用服务将所述更新数据同步至目标数据库。
本说明书一个或多个实施例的数据迁移方法和装置,通过在迁移状态型数据时,以事务的方式记录更新数据,可以保证消息中心和源数据库的数据存储是同步成功或者失败,要么都失败,要么都成功。比如,数据先发给消息中心,再发给源数据库,如果源数据存储失败,事务回滚,消息中心也不会向目标库投递的。如此保证源库和目标库的一致性,保证了“准确一致性”。并且,通过由消息中心将数据投递至目标库,使得不需要将源库的数据实时和目标库同步,提升了性能。此外,该方案可以在应用于迁移状态型数据时,不需要停止状态型数据对应的应用服务很长时间,可以实现一边运行服务一边进行数据迁移,并且使得保证数据一致性和性能提升,这种在服务的同时进行迁移的方式,停止服务的时间显著缩短了,显著降低了对业务的影响。
具体实施方式
为了使本技术领域的人员更好地理解本说明书一个或多个实施例中的技术方案,下面将结合本说明书一个或多个实施例中的附图,对本说明书一个或多个实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书一部分实施例,而不是全部的实施例。基于本说明书一个或多个实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本公开保护的范围。
状态型数据:数据会动态更新,例如,用户的账户余额,当用户进行提现等账户操作时,账户余额的数据会更新。
消息中心:一种事务型消息中间件,通过该中间件能确保消息准确投递。
本说明书至少一个实施例提供的数据迁移方法,图1示例了该方法的应用系统架构,如图1所示,源数据库11中存储有状态型数据,例如,存储有用户的账户余额。如下表1示例了一种源数据中存储的状态型数据,以账户余额为例,用户可以提现并触发该状态型数据的变动:
表1状态型数据
账户名 |
账号 |
余额 |
账户状态 |
最新修改时间 |
小明 |
1001 |
100 |
正常 |
2018-1-12 12:00:01 |
假设现在要进行数据迁移,要将机房A的源数据库11中存储的状态型数据迁移至机房B的目标数据库12中。如下描述该迁移方法:请继续参见图1,该方法的实现,可以由第一应用服务13、消息中心14、第二应用服务15与上述的源数据库11和目标数据库12配合实现。
其中,所述的第一应用服务13位于机房A,可以用于在接收到用户的业务请求时执行业务逻辑的处理,比如,根据用户对账户的提现请求进行提现处理并更改业务数据。第一应用服务13对应处理的业务数据可以存储至源数据库11。第二应用服务15是位于机房B,同样可以执行业务逻辑的处理,而第二应用服务15对应处理的业务数据可以存储至目标数据库12。
所述的第一应用服务13和第二应用服务15属于同一应用系统,例如,都属于某一APP,其中的第一应用服务13可以是位于机房A的用于处理该APP的业务请求的服务模块,第二应用服务15可以是位于机房B的用于处理该APP的业务请求的服务模块。
示例性的,上述的第一应用服务13、消息中心14、第二应用服务15可以分别位于不同的服务器设备,比如,第一应用服务13和第二应用服务15可以运行于各自所在机房的业务处理设备上。消息中心14可以运行于消息中间设备。
请结合图1所示,用于处理状态型数据的第一应用服务13可以不停止服务,继续接收用户对状态型数据的更新请求,并能够在服务运行过程中进行数据迁移,即实现一边服务一边迁移。只是会在迁移的末尾让源数据库11禁写一小段时间即可,后续会详细描述。图2示例了数据迁移方法的流程,包括:
在步骤200中,第一应用服务接收数据更新请求,所述数据更新请求用于请求对源数据库的状态型数据进行更新。
例如,用户发送了数据更新请求,该请求被机房A的第一应用服务13接收。该数据更新请求用于请求对源数据库的状态型数据进行更新,比如,可以是用户在请求对账号1001的资金进行提现。对应图1中的步骤a。
在步骤202中,第一应用服务开启事务模板,记录对应本次更新操作的更新数据。
本步骤中,所述的开启事务模板表示,图1中的步骤b和步骤c属于一个事务,要么都成功,要么都失败。第一应用服务13在接收到数据更新请求后,进行正常的业务逻辑的处理,比如,由账号1001中提现50元,并且声称对应本次更新操作的更新数据。该更新数据可以包括:所述状态型数据的最新值。
例如,上述的最新值可以是如下的表2,相比表1,余额发生变更。并且最新修改时间也进行了更新,表示是在12点10分左右修改余额。
表2状态型数据的最新值
账户名 |
账号 |
余额 |
账户状态 |
最新修改时间 |
小明 |
1001 |
100 |
正常 |
2018-1-12 12:10:01 |
需要说明的是,尽管用户账号的“余额”是在动态变化的状态型数据,但是一般在做业务处理时,可以将余额与其他相关联的信息一起存储,比如,余额所属的账户、账户的状态等。而且在数据迁移时也是将这些关联信息与状态型数据“余额”一起迁移,因此,在对方法的描述中是直接以类似表2的表格来描述,但是可以理解,数据迁移是将表2整体进行迁移,其中包含了状态型数据“余额”。
此外,所述更新数据还可以包括:更新明细记录和核对状态。所述更新明细记录用于记载本次更新操作的更新内容;所述核对状态用于表示所述源数据库和目标数据库的更新明细记录的核对状态。
表3更新明细记录
其中,更新明细记录记载了本次更新操作的更新内容,即本次数据更新请求对应更新了哪些内容。比如,一次数据更新请求有可能涉及到会变更五个表格的数据,可以通过一个更新明细记录的表格一次性将这五个表格发生了哪些变化记录下来,用于依据该更新明细记录就可以清晰的知晓本次数据更新请求发生的变更内容。
该更新明细记录可以用于更新操作的核对。比如,当状态型数据的最新值在源数据库和目标数据库都已经存储完成后,可以比对一下这两个数据库中的更新明细记录是否一致。若一致,表明数据已经准确的实现向目标数据库的同步。后续将继续详述对更新明细记录的核对。在尚未核对前,可以将更新明细记录对应的核对状态设置为I初始状态,表示尚未核对;待核对成功后,再修改该核对状态为核对成功。
在步骤204中,第一应用服务将所述更新数据同步至消息中心。
参见图1中的步骤b,第一应用服务13可以将更新数据同步至消息中心14。所述的更新数据可以包括表2的状态型数据最新值和表3的更新明细记录。
在步骤206中,消息中心向第一应用服务返回同步成功通知。
本步骤中,当消息中心14将更新数据存储成功后,可以向第一应用服务13返回同步成功通知。
在步骤208中,第一应用服务将所述事务模板记录的更新数据提交至源数据库,以使得源数据库更新对应的状态型数据。
本步骤中,可以参见图1中的步骤c,第一应用服务13将所述事务模板记录的更新数据提交至源数据库11。源数据库11可以存储表2和表3的更新数据。
在步骤210中,源数据库向消息中心发送处理成功通知。
例如,如图1中的步骤d。源数据库11在存储更新数据成功后,可以向消息中心14发送处理成功通知,以触发消息中心14将更新数据投递至目标数据库12。
在步骤212中,消息中心将所述更新数据发送至第二应用服务。
本步骤中,消息中心14能够保证更新数据成功投递至目标数据库。当然,在向目标数据库投递时,是经过第二应用服务15转发。如果所述消息中心14向第二应用服务15发送更新数据失败,则进行发送重试,直至将所述更新数据成功发送至第二应用服务15。如图1中的步骤e。
本步骤中,消息中心可以预配置上消息订阅关系,该订阅关系可以表示消息投递路径,根据该消息投递路径知晓第一应用服务的更新数据是要发送至第二应用服务。具体的消息订阅关系的预配置可以按照消息中心的常规配置方式进行,不再详述。
在步骤214中,第二应用服务将所述更新数据发送至目标数据库。
本步骤中,第二应用服务15可以将更新数据发送至目标数据库,包括状态型数据的最新值(表2)和更新明细记录(表3)。此时,状态型数据就完全由源数据库同步到了目标数据库。如图1中的步骤f。
在步骤216中,目标数据库存储更新数据。
本步骤中,目标数据库在接收到更新数据时,要确保接收到的数据是最新数据。可以根据表2中的时间戳判断是否是最新数据。
例如,目标数据库在接收到表2时,可以查看是否已经存在账号1001的账号数据。若不存在,直接存储该表2的数据。如果已经存在,则获取到目标数据库已经存在的该账号1001对应的最新修改时间,称为第一时间戳。可以将表2中的最新修改时间称为第二时间戳,是目标数据库接收到的更新数据中的状态型数据的最新值对应的更新时间。
目标数据库可以比较第一时间戳和第二时间戳,若第一时间戳较新,则丢弃所述更新数据中的最新值,即不保存接收到的表2。若第二时间戳较新,比如,已经存在的第一时间戳是12:00:01,则用所述最新值覆盖所述目标数据库已经存在的状态型数据。
此外,不论目标数据库丢弃还是存储接收到的更新数据,都会存储更新明细记录,以用于更新操作的核对。目标数据库存储更新数据之后,第一应用服务或者第二应用服务还可以定时任务捞取源数据库和目标数据库中的每一笔交易(对应每一次数据更新操作)的更新明细记录进行比对核对,且捞取的更新明细记录的核对状态是尚未核对。若核对成功,则将所述核对状态设置为核对成功状态。比如,根据唯一键8001,获取到源数据库和目标数据库中对应同一账号的更新明细记录,且这两个记录的核对状态都是I即尚未核对。可以将更新明细记录中的每个字段逐一比对,如果各个字段比对均一致,则核对成功,可以将所述核对状态设置为核对成功状态S。如果各个字段比对不一致(如,一边不存在或者比对不一致)就可以报警,待查验,且不更新核对状态。
表4示例了核对状态修改之后的更新明细记录。
表4更新明细记录
在数据迁移的最后,源数据库可以采取禁写一小段时间,这段禁写的时间内,第一应用服务将所述事务模板记录的更新数据提交至源数据库时将发生失败,由于图1中的步骤b和步骤c是一个事务,即使第一应用服务接收到数据更新请求,该更新数据也不会存储到消息中心,进而消息中心也不会投递到目标数据库。即这段禁写的时间内可以保证源数据库和目标数据库都不会再有新的数据。消息中心也可能还有尚未投递完成的更新数据,可以在这段禁写的时间内继续将剩余的更新数据全部成功发送至第二应用服务,此时数据迁移完成。
在数据迁移全部完成后,可以将源数据库和目标数据库中尚未核对的更新明细记录进行核对,若均一致,修改核对状态为核对成功,表明所有数据均同步完毕,可以确保数据的正确性。之后,用户的数据更新请求可以发送至机房B的第二应用服务进行处理,目标数据库也替代了源数据库。
还需要说明的是,在图2的例子中,第一应用服务13向消息中心传递了两个信息,一个是状态型数据的最新值例如表2,还有一个更新明细记录例如表3,并且,源数据库和目标数据库也都接收到了这两个信息。但是,可以理解的是,这种方式可以使得更新数据在落地到数据后,可以尽快的进行核对,提升了核对效率。该更新明细记录也可以不包括在图2的流程中,而是在数据迁移完成后再另行进行核对,比如,第一应用服务13向消息中心传递一个信息即状态型数据的最新值,同理,源数据库和目标数据库也都只接收最新值。可以待数据迁移完后,另外执行核对处理。
本说明书至少一个实施例的数据迁移方法,对源数据库的每一笔对状态型数据的更新操作以消息的形式发送的消息中心,消息中心可以部署在同城的异地机房,消息中心可以保证消息一定能投递成功。同时积压的消息也可以通过消息中心查询出来,如果没有积压说明数据完全同步。
该数据迁移方法在应用于迁移状态型数据时,不需要停止状态型数据对应的应用服务很长时间,可以实现一边运行服务一边进行数据迁移,只是在迁移过程的最后阶段禁写源数据库一小段时间即可,例如可以在业务运行的低峰期进行禁写,从而降低了对应用服务的影响。
此外,该数据迁移方法还可以实现如下效果:
1、最大化性能:
应用服务在接收到数据更新请求后,不需要保证实时和目标数据库同步,而是采取将更新数据通过事务性消息的方式进行记录,待真正提交到源数据库后再通过消息中心投递出去,保证了最大的性能。
2、数据最终一致:
应用服务每次在源数据库进行的请求操作,最终都会同步到目标数据库,这份数据要么已经同步到目标数据库,要么残留在消息中心待投递,通过消息中心事务型消息机制,能够确保消息一定投递成功,从而保证数据最终一致性。
3、完善的核对逻辑:
应用服务的每一笔请求均在源数据库和目标数据库记录一笔更新明细记录,且置为初始状态,后台定时任务进行捞取比对,确保数据一致性后修改状态为成功状态。这样确保了每一笔交易数据的核对逻辑。而且这个核对在交易完结之后可以尽快核对出来,出现问题及时报警。
本说明书至少一个实施例提供了一种数据迁移系统,所述系统用于将源数据库的状态型数据迁移到目标数据库,所述状态型数据是动态更新的数据;所述系统包括:
第一应用服务,用于接收数据更新请求,所述数据更新请求用于请求对源数据库的状态型数据进行更新;所述源数据库用于接收存储第一应用服务获得的数据;开启事务模板记录对应本次更新操作的更新数据,所述更新数据包括:所述状态型数据的最新值,并将所述更新数据同步至消息中心;在接收到消息中心返回的同步成功通知后,将所述事务模板记录的更新数据提交至源数据库,以使得源数据库更新对应的状态型数据;
消息中心,用于在接收到第一应用服务发送的更新数据后,在存储成功后向第一应用服务返回同步成功通知;并将更新数据发送至第二应用服务;所述第一应用服务和第二应用服务属于同一应用系统;
第二应用服务,用于将更新数据发送至目标数据库,所述目标数据库用于接收存储第二应用服务获得的数据。
在一个例子中,所述消息中心,还用于在向第二应用服务发送更新数据失败时,进行发送重试,直至将所述更新数据成功发送至第二应用服务。
在一个例子中,消息中心,还用于在所述第一应用服务将所述事务模板记录的更新数据提交至源数据库时失败之后,所述失败由于源数据库采取了禁写,继续将剩余的更新数据全部成功发送至第二应用服务,此时数据迁移完成。
在一个例子中,更新数据还包括:更新明细记录和核对状态,所述更新明细记录用于记载本次更新操作的更新内容;所述核对状态用于表示所述源数据库和目标数据库的更新明细记录的核对状态;
所述第二应用服务,还用于:获取源数据库和目标数据库中核对状态是尚未核对的更新明细记录进行比对核对;若核对成功,则将所述核对状态设置为核对成功状态。
上述实施例阐明的装置或模块,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
为了描述的方便,描述以上装置时以功能分为各种模块分别描述。当然,在实施本说明书一个或多个实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现。
上述图中所示流程中的各个步骤,其执行顺序不限制于流程图中的顺序。此外,各个步骤的描述,可以实现为软件、硬件或者其结合的形式,例如,本领域技术人员可以将其实现为软件代码的形式,可以为能够实现所述步骤对应的逻辑功能的计算机可执行指令。当其以软件的方式实现时,所述的可执行指令可以存储在存储器中,并被设备中的处理器执行。
例如,对应于上述方法,本说明书一个或多个实施例同时提供一种业务处理设备。该设备可以包括处理器、存储器、以及存储在存储器上并可在处理器上运行的计算机指令。当该设备上运行第一应用服务时,所述处理器通过执行所述指令,用于实现如下步骤:
接收向源数据库的数据更新请求,所述数据更新请求用于请求对源数据库的状态型数据进行更新;
开启事务模板记录对应本次更新操作的更新数据,所述更新数据包括:状态型数据的最新值,并将所述更新数据同步至消息中心;
在接收到消息中心返回的同步成功通知后,将所述事务模板记录的更新数据提交至源数据库,以使得源数据库更新对应的状态型数据。
当该设备上运行第二应用服务时,所述处理器执行指令时还实现以下步骤:接收消息中心发送的更新数据,并将所述更新数据发送至目标数据库。
例如,对应于上述方法,本说明书一个或多个实施例同时提供一种消息中心设备。该设备可以包括处理器、存储器、以及存储在存储器上并可在处理器上运行的计算机指令,所述处理器通过执行所述指令,用于实现如下步骤:
接收第一应用服务发送的更新数据,所述更新数据包括:第一应用服务根据对源数据库的状态型数据进行更新的请求得到的所述状态型数据的最新值;
向所述第一应用服务返回同步成功通知,以使得第一应用服务将所述事务模板记录的更新数据提交至源数据库;
在接收到源数据库发送的处理成功通知时,将所述更新数据发送至第二应用服务,以使得第二应用服务将所述更新数据同步至目标数据库。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此,本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书一个或多个实施例,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于数据处理设备实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。