CN111611227A - 一种自定义监听数据库变化产生自定义消息结构的方法及控制装置 - Google Patents

Abstract

针对现有技术的不足，本公开涉及一种自定义监听数据库变化产生自定义消息结构的方法及装置，监听Mysql数据库库表变化发布不同消息结构的变更消息通知。为实现以上目的，本公开通过以下技术方案予以实现：一种自定义监听数据库变化产生自定义消息结构的方法，包括以下步骤：步骤1：配置阶段；步骤2：从Mysql订阅binlog日志数据，解析binlog从而得到数据库的库名、表名及变更内容；步骤3：根据库表的过滤规则配置，过滤匹配操作类型，字段，以及字段条件值；步骤4：结构转换得到全新的数据结构；步骤5：数据发布到消息队列主题。本公开通过这样的技术方案，配置灵活快速，配置过程动态，即配即用，及时生效，不需要重新编译重新启动。

Description

一种自定义监听数据库变化产生自定义消息结构的方法及控 制装置

技术领域

本发明涉及数据库技术领域，尤其是涉及一种自定义监听数据库变化产生自定义消息结构的方法及控制装置。

背景技术

数据库内的数据在应用过程中不断发生变化，技术人员为了实现某些需求需要不断对数据库内数据变动进行监听。以Mysql数据库为例，Mysql数据库为例的库表变化和数据变动监听通常采用解析Mysql的binlog(数据库日志)得到变更消息，根据业务应用编写软件代码过滤不同的库表和数据变化，解析成为不同的消息结构以满足不同的应用做为数据驱动源。

但是现有技术中，即便对应同一个数据库，每次根据不同的业务，监听Mysql数据库变化均需要编写不同的软件代码做过滤和解析组合得不同的消息结构，以适应新功能。如专利申请号为CN201910595309.2的发明专利《基于监听MySQL数据库binlog变化实现数据同步的方法和系统》中就公开了一种基于监听MySQL数据库binlog变化实现数据同步的方法和系统。方法流程包括：将MySQL的binlog传输到公共存储介质；监听binlog发生变化时，发现文件变化事件；根据文件变化事件，从MySQL中获取对应的数据变化内容，解析该数据变化内容为目标数据结构；将解析后的数据加载到目标存储介质中以完成数据同步。系统包括：公共存储介质、监听模块、数据获取模块和数据加载模块；公共存储介质存储MySQL的binlog；监听模块在binlog发生变化时，发布文件变化事件；数据获取模块从MySQL中获取对应的数据变化内容，将其解析为目标数据结构后；通过数据加载模块加载到目标存储介质中存储。本发明无需开发MySQL交互协议，通过简单方法即可实现数据的同步，实现成本低。

但是该方案中只能进行数据同步，如果需要进一步操作还需要额外的数据加载模块，例如协议配置单元和数据传输单元。这些单元都要根据实际情况单独设计，当业务变化频繁时，难以满足快速高效的需求。

发明内容

为了解决上述技术问题中的至少一个，本公开涉及一种自定义监听数据库变化产生自定义消息结构的方法及装置，监听Mysql数据库库表变化发布不同消息结构的变更消息通知，不需要额外开发软件，快速实现数据驱动源，以便实现各类数据触发操作业务。

为实现以上目的，本公开通过以下技术方案予以实现：

一种自定义监听数据库变化产生自定义消息结构的方法，包括以下步骤：

步骤1：配置阶段，包括过滤规则配置、输出结构模板配置、路由配置以及发布消息主题配置；

步骤2：从Mysql订阅binlog日志数据，解析binlog从而得到数据库的库名、表名及变更内容；

步骤3：根据库表的过滤规则配置，过滤匹配操作类型，字段，以及字段条件值；

步骤4：将步骤3中过滤得到的数据配置到预设的输出结构模板中进行结构转换得到全新的数据结构；

步骤5：根据路由配置，可将步骤4中获取的数据结构的数据发布到消息队列的不同主题去。

优选的，步骤2中解析得到配置信息相关内容时将更新步骤1中的配置信息并根据新的配置信息进行重新配置。如果没有获取新的配置信息，则采用默认的配置进行后续操作。

优选的，所述更新配置过程动态编辑完毕后即时生效。不需要重新编译重新启动。这样提高了效率减少了等待的时间。

优选的，所述过滤规则配置具体方法为：配置白名单和黑名单，两者均包含：数据库、数据表、操作类型、字段名、字段条件及条件值；从binlog得到数据库变更时包含以上信息，根据白名单配置进行匹配，排除黑名单中的配置，从而得到一个过滤后的数据记录。

优选的，所述匹配内容包括匹配库、表、操作类型、字段条件。排除无效信息，仅对指定匹配内容进行处理，有效提高了处理的效率。

优选的，每次黑名单和白名单配置完毕后进行校验，当发现黑名单和白名单内存在重复内容时进行标识警告，处理完警告信息后方能完成白名单和黑名单的配置。这样可以避免本公开在实施时出现逻辑上的错误。

优选的，步骤4中进行结构转化完成后加入时间标签。这样在后期检查或者追溯时，有迹可循，可以根据时间线有条理的进行分析和检查。

优选的，至少包括存储器，所述存储器中存有监听配置模块、binlong解析模块以及数据过滤、解析、路由模块，所述存储器连接在数据库服务器上，并通过消息队列组件进行输出。

优选的，所述监听配置模块中执行过滤配置、输出结构模板配置以及发布消息主题配置。

优选的，故障解析模块自动存储多次发生的故障信息。当发现发布消息主题配置和预期不符时，通过故障解析模块进行校验，从而找到问题所在对最初的配置进行调整。对于经常出现的故障将进行记载并梯形维护人员及早处理。

本公开通过这样的技术方案，带来了以下有益效果：

1.快速配置，无代码开发即可实现数据库数据监听，作为消息触发源。而且一次配置完成后可以快速复制到其他数据库。

2.灵活配置，根据实际业务应用过滤数据，组装任意数据结构，发布到任意消息主题。

3.配置过程动态，即配即用，及时生效，不需要重新编译重新启动。

4.配置准确，通过黑名单和白名单的相互校验以及故障解析模块的设置，减少了配置过程中出现错误需要人工参与的频率。

本公开还通过控制装置确保配置、监听等工作能够顺利完成。

附图说明

附图示出了本公开的示例性实施方式，并与其说明一起用于解释本公开的原理，其中包括了这些附图以提供对本公开的进一步理解，并且附图包括在本说明书中并构成本说明书的一部分。

图1是本公开的流程图。

图2是本公开涉及的控制装置示意图。

图3是本公开配置并发布的一个具体实施例示意图。

具体实施方式

下面结合附图和实施方式对本公开作进一步的详细说明。可以理解的是，此处所描述的具体实施方式仅用于解释相关内容，而非对本公开的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本公开相关的部分。

需要说明的是，在不冲突的情况下，本公开中的实施方式及实施方式中的特征可以相互组合。下面将参考附图并结合实施方式来详细说明本公开。

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

如图1所示，本公开包括一种自定义监听数据库变化产生自定义消息结构的方法，包括以下步骤：

步骤1：配置阶段，包括过滤规则配置、输出结构模板配置、路由配置以及发布消息主题配置；

步骤2：从Mysql订阅binlog日志数据，解析binlog从而得到数据库的库名、表名及变更内容；解析得到配置信息相关内容时将更新步骤1中的配置信息并根据新的配置信息进行重新配置。所述更新配置过程动态编辑完毕后即时生效。

步骤3：根据库表的过滤规则配置，过滤匹配操作类型，字段，以及字段条件值；所述过滤规则配置具体方法为：配置白名单和黑名单，两者均包含：数据库、数据表、操作类型、字段名、字段条件及条件值；从binlog得到数据库变更时包含以上信息，根据白名单配置进行匹配，排除黑名单中的配置，从而得到一个过滤后的数据记录。所述匹配内容包括匹配库、表、操作类型、字段条件。每次黑名单和白名单配置完毕后进行校验，当发现黑名单和白名单内存在重复内容时进行标识警告，处理完警告信息后方能完成白名单和黑名单的配置。。

步骤4：将步骤3中过滤得到的数据配置到预设的输出结构模板中进行结构转换得到全新的数据结构；步骤4中进行结构转化完成后加入时间标签。

步骤5：根据路由配置，可将步骤4中获取的数据结构的数据发布到消息队列的不同主题去。

通过这样的方案，根据配置好的模板，自动进行数据过滤、解析、路由

如图2所示，本公开还包括一种控制装置，自定义监听数据库变化产生自定义消息结构的方法，至少包括存储器，所述存储器中存有监听配置模块、binlong解析模块以及数据过滤、解析、路由模块，所述存储器连接在数据库服务器上，并通过消息队列组件进行输出。所述监听配置模块中执行过滤配置、输出结构模板配置以及发布消息主题配置。还包括故障解析模块。故障解析模块自动存储多次发生的故障信息，便于维护人员修复，同时也能减少维护的频率。

如图3所示，是本公开的一个实施例，从图中可以看出整个过程自动监听Mysql数据库库表变化。其中第一个框内记载的是从Mysql订阅binlog日志数据，第二框内设置的是解析配置文件，解析binlog从而得到数据库的库名、表名及变更内容，转换得到输出所需要的结构；最终经过路由模块分发到消息队列组件中。

从中可见本公开直接实现了结构的变更消息通知，不需要额外开发软件，达到了良好的效果。

在本说明书的描述中，参考术语“一个实施例/方式”、“一些实施例/方式”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例/方式或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例/方式或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例/方式或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例/方式或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例/方式或示例以及不同实施例/方式或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

本领域的技术人员应当理解，上述实施方式仅仅是为了清楚地说明本公开，而并非是对本公开的范围进行限定。对于所属领域的技术人员而言，在上述公开的基础上还可以做出其它变化或变型，并且这些变化或变型仍处于本公开的范围内。

Claims (10)

1.一种自定义监听数据库变化产生自定义消息结构的方法，其特征在于：包括以下步骤：

步骤1：配置阶段，包括过滤规则配置、输出结构模板配置、路由配置以及发布消息主题配置；

步骤2：从Mysql订阅binlog日志数据，解析binlog从而得到数据库的库名、表名及变更内容；

步骤3：根据库表的过滤规则配置，过滤匹配操作类型，字段，以及字段条件值；

步骤4：将步骤3中过滤得到的数据配置到预设的输出结构模板中进行结构转换得到全新的数据结构；

步骤5：根据路由配置，可将步骤4中获取的数据结构的数据发布到消息队列的不同主题去。

2.如权利要求1所述的一种自定义监听数据库变化产生自定义消息结构的方法，其特征在于：步骤2中解析得到配置信息相关内容时将更新步骤1中的配置信息并根据新的配置信息进行重新配置。

3.如权利要求2所述的一种自定义监听数据库变化产生自定义消息结构的方法，其特征在于：所述更新配置过程动态编辑完毕后即时生效。

4.如权利要求1所述的一种自定义监听数据库变化产生自定义消息结构的方法，其特征在于：所述过滤规则配置具体方法为：配置白名单和黑名单，两者均包含：数据库、数据表、操作类型、字段名、字段条件及条件值；从binlog得到数据库变更时包含以上信息，根据白名单配置进行匹配，排除黑名单中的配置，从而得到一个过滤后的数据记录。

5.如权利要求4所述的一种自定义监听数据库变化产生自定义消息结构的方法，其特征在于：所述匹配内容包括匹配库、表、操作类型、字段条件。

6.如权利要求4或5所述的一种自定义监听数据库变化产生自定义消息结构的方法，其特征在于：每次黑名单和白名单配置完毕后进行校验，当发现黑名单和白名单内存在重复内容时进行标识警告，处理完警告信息后方能完成白名单和黑名单的配置。

7.如权利要求1所述的一种自定义监听数据库变化产生自定义消息结构的方法，其特征在于：步骤4中进行结构转化完成后加入时间标签。

8.一种控制装置，用于实现权利要求1-4任一所述的自定义监听数据库变化产生自定义消息结构的方法，其特征在于：至少包括存储器，所述存储器中存有监听配置模块、binlong解析模块以及数据过滤、解析、路由模块，所述存储器连接在数据库服务器上，并通过消息队列组件进行输出。

9.如权利要求8所述的控制装置，其特征在于：所述监听配置模块中执行过滤配置、输出结构模板配置以及发布消息主题配置。

10.如权利要求8所述的控制装置，其特征在于：还包括故障解析模块，故障解析模块自动存储多次发生的故障。

Images