一种数据库的远程数据同步方法和装置
技术领域
本申请涉及数据库技术,特别涉及一种数据库的远程数据同步方法和装置。
背景技术
在数据库的应用中,经常涉及到部署在不同位置的数据库之间的数据同步。当存在数据同步需求的两端数据库相距较远时,传统的数据库同步技术的同步延时较高,同步效率较低,并且由于延时高还可能导致两端在对同一对象进行更改时,在数据库侧造成数据冲突而使得数据库拒绝正确的数据修改,从而造成两端数据库的数据不一致,可靠性较低。
发明内容
有鉴于此,本申请提供一种数据库的远程数据同步方法和装置,以实现快速可靠的数据同步。
具体地,本申请是通过如下技术方案实现的:
第一方面,提供一种数据库的远程数据同步方法,所述方法由业务应用执行,所述数据库用于存储所述业务应用的数据;所述方法包括:
获取数据更新事件更新的业务数据,生成与所述数据更新事件对应的事件版本,并将所述业务数据和事件版本封装成事件对象;
将所述事件对象传输至对端的业务应用,以使得对端的业务应用在根据所述事件版本确定数据更新事件有效时,根据所述业务数据更新对端数据库。
第二方面,提供一种数据库的远程数据同步方法,所述方法由业务应用执行,所述数据库用于存储所述业务应用的数据;所述方法包括:
接收对端的业务应用发送的事件对象,所述事件对象包括:数据更新事件更新的业务数据、以及对应所述数据更新事件的事件版本;
在根据所述事件版本确定对端的数据更新事件有效时,根据所述数据更新事件更新的业务数据更新本地数据库。
第三方面,提供一种数据库的远程数据同步装置,所述装置设置在业务应用中,所述数据库用于存储所述业务应用的数据;所述装置包括:
事件封装模块,用于获取数据更新事件更新的业务数据,生成与所述数据更新事件对应的事件版本,并将所述业务数据和事件版本封装成事件对象;
事件发送模块,用于将所述事件对象传输至对端的业务应用,以使得对端的业务应用在根据所述事件版本确定数据更新事件有效时,根据所述业务数据更新对端数据库。
第四方面,提供一种数据库的远程数据同步装置,所述装置设置在业务应用中,所述数据库用于存储所述业务应用的数据;所述装置包括:
事件接收模块,用于接收对端的业务应用发送的事件对象,所述事件对象包括:数据更新事件更新的业务数据、以及对应数据更新事件的事件版本;
数据更新模块,用于在根据所述事件版本确定对端的数据更新事件有效时,根据所述数据更新事件更新的业务数据更新本地数据库。
本申请提供的数据库的远程数据同步方法和装置,通过由业务应用将更新的数据和事件版本封装成事件对象传输至对端应用,使得可以快速的传输数据更新信息,并且依靠事件版本可以明确数据更新事件的发生顺序,从而保证快速可靠的数据同步。
附图说明
图1是一个例子中数据同步的应用场景;
图2是一个例子中数据同步的平台架构;
图3是一个例子中数据同步的事件发送端的执行流程;
图4是一个例子中业务应用的结构示意图;
图5是一个例子中数据同步的事件接收端的执行流程;
图6是一个例子中远程数据同步装置的结构图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
图1示例了一种数据同步的应用场景,如图1所示,假设“业务应用”是一个用于获取并存储用户信息的应用,例如存储支付宝用户的账号、手机号等用户信息。该业务应用在A地和B地均有部署,这两地之间是远程的,比如中国和美国,河北省和江苏省等,业务应用的用户信息存储在数据库中,例如,业务应用在A地获取的用户信息(比如,用户在支付宝网站注册得到的用户信息)存储在数据库A,在B地获取的用户信息存储在数据库B。基于业务的需求,A地得到的用户信息也需要同步至B地,同样,B地得到的用户信息也需要同步至A地,保证两地的数据库的数据一致,这就涉及到数据库A和数据库B之间的远程数据同步。
本实施例的远程数据同步方法,有别于传统方式中的数据库之间的数据同步(如图1的虚点线箭头所示,数据库A和数据B之间直接进行数据同步),由应用层即业务应用之间来执行数据同步的处理(如图1的实线箭头所示,两地的业务应用之间进行数据同步)。如下分别从时延性和可靠性两方面,对数据库层的同步与应用层的同步进行比较:
时延性:在数据库同步机制中,数据库通常会采用定期同步的方式,比如,每隔一段时间检查数据库中存储的信息是否发生更新,如果发生了更新则将该段时间间隔内的更新数据传输至对端。并且,在传输方式上,以改变了一条用户数据中的用户名称为例,数据库在改变该用户名称时,可能是执行了多条数据库指令(例如,多条SQL语句)实现对数据的更新,在向对端同步时,也需要将该多条数据库指令都传输至对端,并且还需要按照指令的执行顺序向对端发送(例如,在接收到对端反馈的其中一条指令接收成功时,发送下一条指令),这些因素都可能导致向对端数据库的数据传输速度较低,尤其是在远程的这种远距离的数据同步中,将更为降低速度。
而本实施例的数据同步方法中,业务应用可以在每次发生数据更新时,立刻发送至对端,实时发送。并且在传输方式上,业务应用可以从业务层面获取本次数据更新的信息,比如,不去关注更具体的操作层面的SQL语句,而是关注本次数据更新的结果,例如,经过多条数据库指令的执行,结果是改变了一条用户数据中的用户名称;而且业务应用还可以获取更多的业务层面的信息,比如发生改变的该用户名称属于哪条用户数据,对这个数据更新事件的发生时间进行标记。即业务应用可以将本次数据更新的整体作为一个事件,在向对端传输时直接将该事件的数据更新结果一次性传输至对端,更为简洁和快速。
可靠性:传统的数据库同步机制具有一定的缺陷,在执行数据同步的两端接近同时修改数据库文件时,数据库本身难以确定两端的数据更新的发生顺序,并导致数据库认为数据冲突而拒绝本来正确的数据更新。本实施例中,业务应用层可以记录本端的数据更新的时间标识,并且还可以根据该时间标识来判断各次数据更新的顺序,选择最新的数据更新至数据库,也就是说,应用层可以执行更多的处理,使得数据库的数据同步更加可靠。
基于上述,本申请实施例的远程数据同步方法由业务应用来执行,图2示例了该数据同步方法的原理,假设A地的数据库A发生了数据更新,则数据同步要从A地同步至B地,此时A地的业务应用作为数据同步的发送端,B地的业务应用作为数据同步的接收端。该图2示例了作为发送端的业务应用和作为接收端的业务应用分别包括的处理模块,需要说明的是,当B地向A地同步数据时,同样的,B地的业务应用也包括图2中的A地业务应用中的各个模块,A地业务应用也包括B地业务应用的各个模块,即反向流程是一致的,如下的实施例仅描述其中一个方向的数据同步的处理过程。
图3示例了作为发送端的A地的业务应用执行的远程数据同步方法的流程,结合图2和图3所示,该方法可以包括:
301、业务应用执行对业务数据变更的数据更新事件;
例如,业务应用接收到用户通过应用站点修改其用户名称的请求,将用户名称由Jim更改为Tom,则业务应用可以据此修改数据库,比如应用可以通过数据库接口操作数据库完成上述用户名称的变更。本次数据变更可以称为一个“数据更新事件”。
本实施例中,数据库中存储有数据文件,每个数据文件中包括存储的用户信息。在数据库中,各个不同的用户信息可以是存储在不同的行,可以将每个行信息称为一个数据存储单元,例如,第一个数据存储单元用于存储用户Y1的信息,比如,User:{id=1,name=Jim},当然还可以包括更多的信息比如User:{id=1,name=Jim,phone=132****1112};第二个数据存储单元用于存储用户Y2的信息,比如,User:{id=2,name=Mary}。其中,用户信息中的id可以称为业务主键,用于区分不同的业务数据,本实施例中即用不同的id区分不同用户的信息。如果只有一个用户的信息,也可以不使用业务主键。
在本步骤中,数据更新事件对业务数据的变更,可以是一条用户信息中的部分数据,比如,User:{id=1,name=Jim,phone=132****1112}这条用户信息中可以只修改name,但是对于本实施例用于存储用户信息的业务应用,本实施例可以将上述的用户信息的整体称为一条业务数据。结合图2所示,可以由业务应用中的数据变更模块执行对业务数据的变更。
302、业务应用获取数据更新事件更新的业务数据,生成与数据更新事件对应的事件版本,并将业务数据和事件版本封装成事件对象;
例如,业务应用的数据变更模块在对业务数据变更后,比如将用户的name由Jim变更为Tom,业务应用还要获取这次变更对应的业务数据,即获取User:{id=1,name=Tom},也就是本次数据变更是对这条业务数据中的name进行了变更。
业务应用还生成与该数据更新事件对应的事件版本,本实施例中,对数据库数据的一次增加、删除、修改等数据更新都可以称为一次数据更新事件,并且根据事件发生的顺序,记录“事件版本”来表示事件之间的先后顺序,比如,第一次发生的事件,其版本可以为“1”,即version=1,第二次发生的事件,其版本向上可以步长1递增,即version=2,以此类推。当然,事件版本的递增步长不一定是1,比如步长可以为2,第一次事件版本为1,第二次事件版本为3;或者,也不一定以数字表示,例如可以通过事件发生的时间戳来表示事件版本,比如第一次发生的事件版本为2014.12.31,第二次发生的事件版本为2015.1.20,通过该时间戳也可以识别事件发生的先后顺序。
结合图2所示,本步骤中,可以由业务应用的事件封装模块来执行上述的获取业务数据、生成事件版本的操作,并且,事件封装模块可以将业务数据和事件版本封装成事件对象。例如,封装的事件对象可以是Event:{user={id=1,name=Tom},version=1}。当业务应用中存储有多个用户信息时,如上所示的事件对象,事件对象中可以包括业务主键,以表示该事件对象对应于哪个用户。
303、业务应用将所述事件对象传输至对端的业务应用;
例如,结合图2所示,业务应用封装的事件对象,可以由事件发送模块向对端的业务应用(即远程的需要同步数据的对端)发送,由对端业务应用的事件接收模块接收。本实施例中,可以将发送端的事件发送模块与接收端的事件接收模块的整体,称为“事件通知平台”,该平台用于传输业务应用封装的事件对象,可以是通过消息的形式进行传输。
通过事件通知平台传输事件,不仅可以做到实时传输,比如,业务应用在进行数据库的数据更新后,可以实时的封装事件对象并由事件通知平台传输至对端,相对于传统的数据库定期同步将显著提高同步效率;并且,该事件通知平台对于一次数据更新,可以通过一个Event事件对象,将本次数据更新的信息一次性都传输至对端,相对于传统的数据库顺序传输一次数据更新包括的多条指令信息的方式,也提高了数据同步的速度。例如,在跨国的数据同步中,该平台可以支持接近毫秒级别将一个事件对象跨国传递至对端。
本实施例中,业务应用还可以在将业务数据和事件版本封装成事件对象之后,记录该事件对象。参见图4的示例,业务应用中还可以包括事件记录模块,该模块可以用于记录事件对象,该事件对象可以记录在数据库中;并且可以将每一次事件对象都记录下来,例如:
Event:{user={id=1,name=Jim},version=0};
Event:{user={id=1,name=Tom},version=1};
通过记录事件对象,一方面可以用于在接收到对端发送的事件对象时,即作为接收端时,从该记录的事件对象中提取事件版本信息用于事件有效性的确定,该处理可以参见后续的接收端执行的方法描述。另一方面,通过将各次事件对象都记录下来,有助于了解数据变更的过程,做到历史可追溯。
事件记录模块对事件对象的记录,可以在事件封装模块封装事件对象完成,发送对象之前执行;或者也可以在事件发送模块发送事件对象之后。
图5示例了作为接收端的B地的业务应用执行的远程数据同步方法的流程,结合图2和图5所示,该方法可以包括:
501、业务应用接收对端的业务应用发送的事件对象,所述事件对象包括:数据更新事件更新的业务数据、以及对应所述数据更新事件的事件版本;
例如,作为接收端,业务应用可以由事件接收模块接收对端发来的事件对象,该事件对象中可以包括业务数据、事件版本。例如上面例子中的事件对象Event:{user={id=1,name=Tom},version=1};当数据库中存储有一个以上用户的信息时,该事件对象的业务数据中至少包括业务主键、以及进行更新的数据,该业务主键用于区分不同用户的信息。
502、业务应用根据事件对象中包括的业务主键,获取与所述业务主键对应的本地记录的数据更新事件的事件版本;
例如,结合图2所示,业务应用中的数据更新模块可以对事件对象解封装,获取到事件对象中包括的业务主键和事件版本,比如上述的事件中,业务主键id=1,事件版本version=1。
在图3所示的例子中提到,业务应用可以通过事件记录模块在自身记录发生过的事件对象,在本步骤中,数据更新模块可以根据接收到的对端事件对象中的业务主键id=1,获取与所述业务主键对应的本地记录的数据更新事件的事件版本,比如从本地已经记录的事件记录中提取业务主键和事件版本信息,如{id=1,version=0}。如果本地记录了多个对应同一id的事件版本,则获取最新发生事件的事件版本,比如是时间最新或版本数字最大。
503、业务应用根据事件版本判断接收的数据更新事件是否有效;
例如,业务应用的数据更新模块可以比较本地记录的对应同一id的事件版本,与接收到的对端事件的事件版本,如果对端事件在时间上后发生,则对端事件有效,表明是最新的数据更新事件;如果对端事件在时间上先发生,则表明本地已经记录了最新的数据更新事件,对端事件是无效的。
在具体判断时,在上面的例子中,可以判断事件版本的大小比较,对端事件的事件版本version=1大于本端的事件版本version=0,则确定对端的数据更新事件有效,继续执行504;否则,假设对端的事件版本低于本端事件版本,则确定对端事件无效,可以执行506。此外,如果用时间戳表示事件版本时,同样比较时间戳判断本端和对端事件发生的先后顺序。
504、业务应用根据数据更新事件更新的业务数据更新本地数据库;
例如,业务应用在确定对端的数据更新事件有效后,可以调用数据库接口更改数据库中对应的业务数据。即根据user={id=1,name=Tom},更新本地的业务数据为user={id=1,name=Tom}。
505、业务应用记录所述事件对象;
例如,业务应用在根据对端的数据更新事件,更新本地数据库中的业务数据后,还根据该事件更新本地记录的事件对象,如上面例子提到的,业务应用可以通过事件记录模块,将最新的事件对象Event:{user={id=1,name=Tom},version=1}记录在本地数据库中,并保留历史事件记录,以便于追溯。具体实施中,可以在确定对端的事件有效后就记录该事件对象,或者在更新本地数据库之后记录,都可以。
506、业务应用丢弃该事件对象,不根据该事件对象更新本地数据库;
本实施例的业务应用通过使用事件版本,标识各次数据更新事件的发生顺序,有助于准确识别最新发生的事件,确保数据库的准确更新;例如,即使在两端接近同时发生了对同一目标的数据更改,也可以通过事件版本的比较来准确识别最新发生的数据更新。
本实施例的远程数据同步方法,这种基于事件的数据同步,可以实时的传输数据更新的信息,事件传输比较快速;而且还可以通过事件的版本来区分不同次数据更新的顺序,保证数据库的数据更新的准确性和可靠性。
由以上描述可以看到,在发送端和接收端的业务应用,都包括远程数据同步装置,例如图2和图4所示,用于通过该装置中的各个模块执行本实施例的远程数据同步方法。此外,对于接收端的业务应用,远程数据同步装置的结构可以参见图6,包括:事件接收模块61和数据更新模块62;其中,数据更新模块62可以包括:记录获取单元621和事件判断单元622;
记录获取单元621,用于根据事件对象中包括的业务主键,获取与所述业务主键对应的本地已经记录的数据更新事件的事件版本,所述业务主键用于区分不同的业务数据;
事件判断单元622,用于比较本地事件版本与对端的事件版本,确定对端的数据更新事件在时间上发生在本地已经记录的数据更新事件之后。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。