CN109284312A - 一种异构数据库变更实时通知方法 - Google Patents

Abstract

本发明公开了一种异构数据库变更实时通知方法，首先确定源表集和目标表集，通过数据变更捕获机制，监听源表集，当对源表进行数据的增加或删除或改变操作时，数据变更捕获机制将DML操作记录到目标表集中对应的目标表中；然后通过数据转换程序，从目标表集中获取变更数据，并将变更数据转换为统一格式后存放到另行建立的变更数据库中；当变更数据库中新增变更数据后，将变更消息通过消息队列机制推送给用户。本发明实现了异构数据库的数据变更捕获和推送。使用者不需要关心不同版本的数据兼容问题，本发明可以处理不同数据库不同版本的数据，统一格式对外输出，使用者可对所有数据库的数据变更进行定制化订阅。

Description

一种异构数据库变更实时通知方法

技术领域

本发明涉及一种监听异构数据库中数据变更情况并实时推送的方法。

背景技术

实际应用中，用户及运维者具有实时获取数据库变更通知的需求，而数据库变更捕获，是实现数据库变更通知的基础。

目前，数据库变更捕获主要有两种实现方式：一种多存在于OLAP（联机分析处理）和ETL（数据仓库技术）开发中，进行增量的抽取，另一种是基于CDC（数据变更捕获），是在数据库级别实现的增量抽取解决方案。

在CDC出现之前，基于OLAP和ETL开的数据增量抽取方法可分为：

一、时间戳：

在数据库表中增加时间戳字段，数据库中发生的所有CUD（增改删）操作，均同步修改时间戳，当进行数据抽取时，通过对比上次抽取时间与时间戳字段的一致性来决定抽取哪些数据。

部分数据库不支持时间戳的自动更新，即表中数据发生变更时，数据库不能自主更新时间戳，需要业务逻辑进行相对应的处理。

该方式的优点是：时间戳性能较好，结构清晰，实现简单，可以满足数据的递增加载。缺点在于：在表结构的层级对数据变更捕获进行侵入，耦合性很高，如果对生产项目增加时间戳字段，需要耦合的业务代码众多。另外对于不支持自动更新时间戳的数据库，还需处理CUD业务逻辑，手动处理时间戳，易产生错误。并且时间戳无法捕捉到delete操作，在数据准确性上受到一定影响。

二、触发器：

在要捕获的数据库表中，建立触发器，一般根据需求，对新增/修改/删除三种操作创建，同时根据业务需求判断是否需要创建临时表。

每当源表发生新增/修改/删除数据变更时，触发器会将对应的操作存入到临时表中，通知线程会从临时表中抽取数据，临时表中抽取过的数据会被标记或者删除。

该方式的优点在于：触发器性能高，实时性好，处理规则简单，不需要修改源表结构，可以实现源表的变更捕获。缺点在于：要求对源表建立触发器，对业务系统有一定的影响，破坏数据库业务逻辑，容易对源数据库构成威胁，同时增加维护的复杂程度。

三、全表对比方式

全表对比的方式是借助ETL工具事先为要抽取的表建立一个结构类似的临时表，该临时表记录源表主键以及根据所有字段的数据计算出来，每次进行数据抽取前，对源表和临时表进行对比，如有不同，进行增删改操作。

该方式的优点在于：对已有源表结构不产生影响，不需要修改业务逻辑程序，所有抽取规则由ETL完成，管理维护统一，可以实现数据的递增加载。缺点在于：对比过程较复杂，设计也较为复杂，速度较慢。与触发器和时间戳的方式不同，全表对比方式是被动的进行全表数据的比对，性能较差。当表中没有主键或唯一列、且含有重复记录时，全表对比方式的准确性要单独处理。

四、日志表方式

在业务系统中添加系统日志表，当业务数据发生变化时，更新维护日志表内容，当作ETL 加载时，通过读日志表数据决定加载那些数据及如何加载。

该方式的优点在于：不需要修改业务系统表结构，源数据抽取清楚，速度较快。可以实现数据的递增加载。缺点在于：日志表维护需要由业务系统完成，需要对业务系统业务操作程序作修改，记录日志信息。日志表维护较为麻烦，对原有系统有较大影响。工作量较大，改动较大，有一定风险。

五、全表读取数据

每次获取数据时时均全量获取。该方式的优点在于：加载规则简单，维护简单。缺点在于：重复读取数据，性能差，一般不用。

六、CDC捕获数据变更

上述的各种捕获变更数据，都是在应用程序中实现自定义跟踪机制。这些自定义机制通常要求对跟踪的表进行架构更改，或者使用触发器。为了满足数据迁移和数据抽取的业务需要，使得有机会在数据库层面上直接实现增量抽取功能，ORACLE综合性能和场景需要，在数据库引擎层面直接集成了CDC功能，由于提供了类似API的功能接口，变更数据捕获和更改跟踪均不要求在源中进行任何架构更改或使用触发器，所以比第三方工具具有一定的优势。利用CDC捕获变更有以下特点：

（1）性能影响小。使用异步进程捕获，通过进程读取事务日志，对系统造成的影响很小，不对业务系统造成太大的压力，影响现有业务。

（2）监控范围大。对该表的所有DML和DDL操作都会被记录，有助于跟踪表的变化，实现表操作的追根溯源。

（3）操作简单。CDC是在数据库引擎中添加的功能，封装在数据库中，类似于API接口调用，不需要复杂的业务处理逻辑就可以实现DML和DDL的操作监控。

（4）有一定时延性。由于捕获进程从事务日志中提取更改数据，因此，向源表提交更改的时间与更改出现在其关联更改表中的时间之间存在内在的延迟。虽然这种延迟通常很小，但务必记住，在捕获进程处理相关日志项之前无法使用更改数据。

目前主流数据库均有数据变更捕获底层实现依赖，而由于异构数据库的SQL方言语法的不一致，导致基于异构数据库的统一数据捕获方案的缺失。因此上述中的数据库变更捕获，只能应对单一的数据库，仅作为数据库变更通知的实现基础。而很多企业存在多种数据库/不同版本数据库的并行使用，异构数据库变更捕获的需求逐渐增多，采用上述方式仅仅能获得数据的变更信息，并不能解决异构数据库的兼容问题，无法即时向相关人员推送变更通知。

发明内容

本发明提出了一种异构数据库变更实时通知方法，其目的是：实现异构数据库的数据变更捕获和推送。

一种异构数据库变更实时通知方法，其特征在于通过计算机装置实现下述步骤：

（1）确定源表集和目标表集，所述源表集用于指定需要监听的源表，所述目标表集用于指定源表所对应的目标表；通过数据变更捕获机制，监听源表集，当对源表进行数据的增加或删除或改变操作时，数据变更捕获机制将DML操作记录到目标表集中对应的目标表中；

（2）通过数据转换程序，从目标表集中获取变更数据，并将变更数据转换为统一格式后存放到另行建立的变更数据库中；

（3）变更数据库中新增变更数据后，将变更消息通过消息队列机制推送给用户。

作为本发明的进一步改进：所述源表集还指定源表中需要监听的字段。

作为本发明的进一步改进：所述数据变更机制基于CDC或者Trigger；当异构数据库中某数据库支持CDC捕获数据变更时，所述目标表是指该数据库的CDC Schema表；如果异构数据库中某数据库不支持CDC捕获数据变更，则采用Trigger机制捕获数据变更，所述目标表为另建的用于存储DML操作记录的中间数据表。

作为本发明的进一步改进：使用模块化的数据库CDC启动方案，对不属于既定业务模块的表不进行CDC功能开启。

作为本发明的进一步改进：所述统一格式为JSON格式。

作为本发明的进一步改进：所述消息队列机制采用订阅/通知模式。

作为本发明的进一步改进：所述消息队列机制通过Exchange代理和Queue通道进行消息的推送。

作为本发明的进一步改进：用户订阅时设置订阅规则，所述订阅规则指定订阅的源表及源表中的字段。

作为本发明的进一步改进：消息推送前，根据订阅规则将待推送消息分组为多个Collection，推送时每个Queue只负责推送一个Collection中的数据记录，以减少消息队列压力。

作为本发明的进一步改进：变更数据库中新增变更数据后，对新增的变更数据进行合并整理：如果新增变更数据中部分记录所对应的字段之间在数据库的关系模型中存在关联关系，则将相关联的记录合并为一条记录。

相对于现有技术，本发明具有以下积极效果：（1）本发明针对异构数据库，基于底层进行变更数据的捕获，然后转换为统一格式的数据，通过消息队列推送给用户，解决了异构数据库数据捕获的兼容性问题，并且以更易于阅读和使用的数据格式，通知给数据需求方，实现了异构数据库实时变更通知的统一规范；（2）本发明优选采用数据捕获方式中性能最优、对源表影响最小、对业务逻辑耦合最低的CDC（数据变更捕获）的底层技术实现，在不同的数据库厂商的不同CDC实现上，集成了统一的数据变更捕获接口，实现了对Oracle/SqlServer/MySQL等主流数据库的CDC变更捕获，其采用天然的数据库恢复日志模块以获取变更数据，降低了负荷，最大程度减少监听变更对数据库本身性能的影响，以提高数据库DML操作的响应时间，同时针对老版本数据库提供了Trigger方案，尽可能地覆盖较多的版本；（3）本发明对数据库变更捕获后，采用消息队列进行实时通知，具备持久化、传输确认、发布确认、消息集群、高可用和多种协议等特性；（4）使用模块化的数据库CDC启动方案，对不属于既定业务模块的表不进行CDC功能开启，进一步降低了负荷，提升了数据库性能；（5）通过对目标表集的设定，可以自定义监听的表和字段，提高捕获效率，进一步减小对系统性能的影响，并且为精细化订阅奠定基础；（6）采用订阅/通知模式，订阅时可以设置订阅规则，依据订阅规则确定目标表集，并对订阅者进行定制推送，从最底层的数据库CDC数据变更捕获到订阅模块的根据表/字段的灵活化订阅，实现了高度自定义化配置，满足各种业务需求；（7）消息队列可提供多平台、多语言的实现支持，主流的操作系统(Linux，Windows，Mac)等均可实现订阅。

具体实施方式

下面详细说明本发明的技术方案：

本发明方法通过异构数据库变更实时通知服务实现，本服务基于异构数据库底层的恢复日志功能，首先需要开启异构数据库的恢复日志功能。服务集成了Oracle、Sql Server、MySQL等主流数据库的CDC模块，只需要一套程序入口，可抓取三种数据库的数据变更集。恢复日志模块会记录数据库DML操作到既定CDC Schema表中。优先使用模块化的数据库CDC启动方案，对不属于既定业务模块的表不进行CDC功能开启，提高服务性能。对于低版本不支持此功能的数据库，本程序提供开启Trigger的候选方案。上述操作记录，为数据变更通知提供了底层支持。

本服务通过消息队列实现最终消息的推送。所述消息队列机制采用订阅/通知模式，通过Exchange代理和Queue通道进行消息的推送。用户通过本服务对异构数据库的数据进行订阅，订阅时设置订阅规则，所述订阅规则指定订阅的源表及源表中的字段。

服务根据业务情况结合订阅规则确定源表集和目标表集，所述源表集用于指定需要监听的源表，还可以指定源表中需要监听的字段。从而从最底层的数据库CDC数据变更捕获到订阅模块的根据表/字段的灵活化订阅，实现了高度自定义化配置，满足各种业务需求。

所述目标表集用于指定源表所对应的目标表。

服务程序根据配置信息，通过恢复日志模块/trigger模块获取到变更信息：通过数据变更捕获机制，监听源表集，当对源表进行数据的增加或删除或改变操作时，数据变更捕获机制将DML操作记录到目标表集中对应的目标表中。

当异构数据库中某数据库支持CDC捕获数据变更时，所述目标表是指该数据库的CDC Schema表；如果异构数据库中某数据库不支持CDC捕获数据变更，则采用Trigger机制捕获数据变更，所述目标表为另建的用于存储DML操作记录的中间数据表。

服务设置有数据转换程序，根据源表集与目标表集的对应关系，从目标表集中获取变更数据记录，并将变更数据转换为统一格式后存放到另行建立的变更数据库中。具体的，程序根据一定时间（可配置）进行轮询，捕获到不同版本数据库（Mysql，Sql Server，Oracle）的变更记录，读取16进制数据，然后程序统一转换为更易于理解的Json格式数据。最终所有不同版本的数据库的变更记录均存储为统一的格式。

变更数据库中新增变更数据后，对新增的变更数据进行合并整理：如果新增变更数据中部分记录所对应的字段之间在数据库的关系模型中存在关联关系，则将相关联的记录合并为一条记录。例如某表A中的字段a与某表B中的字段b为关联字段，当字段a的数据变化后字段b对应的数据必然，为了避免重复，增加消息内容的可读性，依据关系模型将字段a和b对应的数据变更记录合并为一条记录。

变更数据库中新增变更数据后，根据订阅者注册时的规则参数，筛选订阅者所订阅的数据，将变更消息通过消息队列机制MQ推送给用户。

进一步的，在消息推送前，可以根据订阅规则将待推送消息分组为多个Collection，推送时每个Queue只负责推送一个Collection中的数据记录，以减少消息队列压力。

上述消息队列机制还具有以下特性：

消息的可靠性（Reliability）：确保数据能够准确无误的到达接受者，如持久化机制，传输确认机制，发布确认机制。

灵活的路由（Flexible Routing）：在消息进入队列之前，通过Exchange来路由消息。对于典型的路由功能，已经提供了一些内置的Exchange来实现（direct/topic/fanout/header）,针对更复杂的路由功能，可以将多个Exchange绑定在一起。

消息集群（Clustering）：多个MQ服务器可以组成一个集群，形成一个逻辑Broker。

高可用（Highly Available Queues）：队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。

多种协议（Multi-protocol）：支持多种消息队列协议，比如 STOMP、MQTT 等等。

跟踪机制（Tracing）：如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么。

最终的使用者不需要关心不同版本的数据兼容问题，本服务程序可以处理不同数据库不同版本的数据，统一格式对外输出，使用者可对所有数据库的数据变更进行订阅。另外使用者可以根据自己需求进行订阅，服务后台根据情况对源表集进行调整，不必监听整表，可自定义字段。订阅者还可根据业务使用场景，对数据捕获扫描的时间间隔进行自定义配置（1s,2s,1min等）。

Claims (10)

1.一种异构数据库变更实时通知方法，其特征在于通过计算机装置实现下述步骤：

（1）确定源表集和目标表集，所述源表集用于指定需要监听的源表，所述目标表集用于指定源表所对应的目标表；通过数据变更捕获机制，监听源表集，当对源表进行数据的增加或删除或改变操作时，数据变更捕获机制将DML操作记录到目标表集中对应的目标表中；

（2）通过数据转换程序，从目标表集中获取变更数据，并将变更数据转换为统一格式后存放到另行建立的变更数据库中；

（3）变更数据库中新增变更数据后，将变更消息通过消息队列机制推送给用户。

2.如权利要求1所述的异构数据库变更实时通知方法，其特征在于：所述源表集还指定源表中需要监听的字段。

3.如权利要求1所述的异构数据库变更实时通知方法，其特征在于：所述数据变更机制基于CDC或者Trigger；当异构数据库中某数据库支持CDC捕获数据变更时，所述目标表是指该数据库的CDC Schema表；如果异构数据库中某数据库不支持CDC捕获数据变更，则采用Trigger机制捕获数据变更，所述目标表为另建的用于存储DML操作记录的中间数据表。

4.如权利要求3所述的异构数据库变更实时通知方法，其特征在于：使用模块化的数据库CDC启动方案，对不属于既定业务模块的表不进行CDC功能开启。

5.如权利要求1所述的异构数据库变更实时通知方法，其特征在于：所述统一格式为JSON格式。

6.如权利要求2所述的异构数据库变更实时通知方法，其特征在于：所述消息队列机制采用订阅/通知模式。

7.如权利要求6所述的异构数据库变更实时通知方法，其特征在于：所述消息队列机制通过Exchange代理和Queue通道进行消息的推送。

8.如权利要求6所述的异构数据库变更实时通知方法，其特征在于：用户订阅时设置订阅规则，所述订阅规则指定订阅的源表及源表中的字段。

9.如权利要求8所述的异构数据库变更实时通知方法，其特征在于：消息推送前，根据订阅规则将待推送消息分组为多个Collection，推送时每个Queue只负责推送一个Collection中的数据记录，以减少消息队列压力。

10.如权利要求1至9任一所述的异构数据库变更实时通知方法，其特征在于：变更数据库中新增变更数据后，对新增的变更数据进行合并整理：如果新增变更数据中部分记录所对应的字段之间在数据库的关系模型中存在关联关系，则将相关联的记录合并为一条记录。