消息配置方法、电子装置和可读存储介质与流程

[0001]
本发明涉及计算机的技术领域，具体而言，涉及消息配置方法、电子装置和可读存储介质。


背景技术：

[0002]
在系统间的异步交互过程中，常用的方式为发送消息，实现消息的发送通常的为在业务代码中写完业务数据之后加入消息发送的代码进行消息发送，存在系统耦合度高、消息中间件出问题直接会影响到业务系统的运行的问题，并且，在业务方众多的情况下，如果每个业务方都要求只接收自己的需要的字段变更的消息，存在定制化开发周期长，上线繁琐的问题。


技术实现要素：

[0003]
本发明旨在解决上述技术问题的至少之一。
[0004]
为此，本发明的第一目的在于提供一种消息配置方法。
[0005]
本发明的第二目的在于提供一种电子装置。
[0006]
本发明的第三目的在于提供一种可读存储介质。
[0007]
为实现本发明的第一目的，本发明的技术方案提供了一种消息配置方法，包括：获取数据库中变更的数据库数据；对变更的数据库数据进行合并操作，得到合并后的数据库数据；获取合并后的数据库数据对应消息所在表格的字段；根据消息需要的字段，配置消息的内容。
[0008]
本技术方案中，获取合并后的数据库数据对应消息所在表格的字段，根据需要的字段，进行消息内容的配置，实现了消息的字段级配置，进而实现字段级消息的可定制化配置以及上线，不会增加业务代码的复杂程度，使得业务系统维护简单，并且，上线不需要重启服务，对业务系统的运行没有影响。
[0009]
另外，本发明上述技术方案还可以具有如下附加技术特征：
[0010]
上述技术方案中，获取数据库中变更的数据库数据，包括：构建日志解析服务；通过日志同步解析服务，获取变更的数据库数据。
[0011]
通过构建日志解析服务，配置关注数据库的变更，获取变更的数据库数据，通过上述方式仅需要获取少量变更的数据库数据，编写代码简单，节约cpu资源。
[0012]
上述任一技术方案中，日志解析服务尊从主从协议。
[0013]
构建的日志解析服务尊从数据库的主从协议，通过采用主从协议，对数据库中变更的数据库数据进行同步，节约了cpu资源。
[0014]
上述任一技术方案中，对变更的数据库数据进行合并操作，得到合并后的数据库数据，包括：解析变更的数据库数据的前值和后值；根据前值和后值，进行合并操作，得到合并后的数据库数据的前值和后值，获取合并后的数据库数据。
[0015]
通过合并操作，简化数据表中字段值的变更过程，降低代码的复杂程度，方便后续
进行系统维护
[0016]
上述任一技术方案中，对变更的数据库数据进行合并操作时，获取数据库数据采用单线程处理。
[0017]
合并操作需要采用单线程处理，确保可以获取每次字段值的变化，进而识别字段值连续变更的过程，实现合并操作。
[0018]
上述任一技术方案中，消息配置方法还包括：日志解析服务将处理的位点持久化至分布式应用程序协调服务上。
[0019]
通过对监控任务运行情况，提高日志解析服务的准确性，针对出现问题的情况，通过报警进行提示，使得提示更加直观，便于发现。
[0020]
上述任一技术方案中，获取合并后的数据库数据对应消息所在表格的字段，包括：根据配置文件生成任务；获取合并后的数据库数据触发的任务；获取任务对应消息所在表格的字段。
[0021]
本技术方案中，通过获取合并后的数据库数据触发的任务，得到任务对应消息所在表格的字段，基于得到的消息，根据需要的字段，进行消息内容的配置，消息与业务代码进行分离，不存在耦合情况，在消息中间件出现问题时，不影响业务系统的正常运行，提高了业务系统的运行的稳定性，并且，上线不需要重启服务，对业务系统的运行没有影响。
[0022]
上述任一技术方案中，消息配置方法还包括：对日志解析服务配置主库和从库；基于主库中断运行，从库切换为主库进行运行，切换过程中位点前推目标时间。
[0023]
通过设置主库和从库，在遇到异常情况终端运行时，可以通过从库切换为主库继续运行，提高了系统运行的稳定性，进行切换时，换的过程中位点自动前推目标时间，保证不丢失数据，以及数据的准确。
[0024]
为实现本发明的第二目的，本发明的技术方案提供了一种电子装置，包括：存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序；其中，处理器在执行计算机程序时，实现如本发明任一技术方案的消息配置方法的步骤。
[0025]
本发明技术方案提供的电子装置实现如本发明任一技术方案的消息配置方法的步骤，因而其具有如本发明任一技术方案的消息配置方法的全部有益效果，在此不再赘述。
[0026]
为实现本发明的第三目的，本发明的技术方案提供了一种可读存储介质，可读存储介质存储有计算机程序，计算机程序被执行时，实现上述任一技术方案的消息配置方法的步骤。
[0027]
本发明技术方案提供的可读存储介质实现如本发明任一技术方案的消息配置方法的步骤，因而其具有如本发明任一技术方案的消息配置方法的全部有益效果，在此不再赘述。
[0028]
本发明的附加方面和优点将在下面的描述部分中变得明显，或通过本发明的实践了解到。
附图说明
[0029]
本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：
[0030]
图1为本发明一个实施例的消息配置方法流程图之一；
[0031]
图2为本发明一个实施例的消息配置方法流程图之二；
[0032]
图3为本发明一个实施例的消息配置方法流程图之三；
[0033]
图4为本发明一个实施例的消息配置方法流程图之四；
[0034]
图5为本发明一个实施例的消息配置方法流程图之五；
[0035]
图6为本发明一个实施例的消息配置方法流程图之六；
[0036]
图7为本发明一个实施例的电子装置示意图；
[0037]
图8为本发明一个系统技术架构示意图；
[0038]
其中，图7至图8中附图标记与部件名称之间的对应关系为：
[0039]
110：数据库，120：数据库日志变更增量获取服务，130：数据库变更数据合并服务，140：任务计算和消息生成发送服务，150：配置文件，160：分布式应用程序协调服务，170：中间件，200：电子装置，210：存储器，220：处理器。
具体实施方式
[0040]
为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。
[0041]
在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。
[0042]
下面参照图1至图8描述本发明一些实施例的消息配置方法、电子装置200和可读存储介质。
[0043]
实施例1：
[0044]
如图1所示，本实施例提供了一种消息配置方法，包括以下步骤：
[0045]
步骤s102，获取数据库中变更的数据库数据；
[0046]
步骤s104，对变更的数据库数据进行合并操作，得到合并后的数据库数据；
[0047]
步骤s106，获取合并后的数据库数据对应消息所在表格的字段；
[0048]
步骤s108，根据消息需要的字段，配置消息的内容。
[0049]
本实施例中，数据库可以采用mysql数据库，下述以mysql数据库为例，进行说明。
[0050]
首先，本实施例获取mysql数据库中变更的数据库数据，数据库数据为binlog(二进制日志文件数据)，对变更的数据库数据进行合并操作，得到合并后的数据库数据，然后，根据合并后的数据库数据，确定对应消息所在表格的字段，最后，根据消息需要的字段，配置消息的内容。本实施例中，消息与业务代码进行分离，不存在耦合情况，在于消息中间件出现问题时，不影响业务系统的正常运行，提高了业务系统的运行的稳定性。
[0051]
相关技术中，当一个业务数据的变化需要给多个业务方发送消息并且需要的消息字段不一样时，业务代码会变得复杂，造成难以维护的问题，本实施例中，获取合并后的数据库数据对应消息所在表格的字段，根据需要的字段，进行消息内容的配置，实现了消息的字段级配置，进而实现字段级消息的可定制化配置以及上线，不会增加业务代码的复杂程度，使得业务系统维护简单，并且，上线不需要重启服务，对业务系统的运行没有影响。
[0052]
本实施例中，通过将binlog的位点回调到指定的位置发送指定时间后的消息，使
得重发消息非常简便可行。
[0053]
实施例2：
[0054]
如图2所示，除上述实施例的技术特征以外，本实施例进一步地包括了以下技术特征：
[0055]
获取数据库中变更的数据库数据，包括以下步骤：
[0056]
步骤s202，构建日志解析服务；
[0057]
步骤s204，通过日志同步解析服务，获取变更的数据库数据。
[0058]
具体而言，可以将mysql数据库的binlog模式设置为row模式，构建日志解析服务，举例而言，日志解析服务包括数据库日志变更增量获取服务(canal-server服务)和数据库变更数据合并服务(canal-client服务)。
[0059]
通过构建canal-server服务，配置关注mysql数据库的变更，获取变更的binlog，通过上述方式仅需要获取少量变更的binlog，编写代码简单，节约cpu资源。
[0060]
canal-client服务用于数据合并。
[0061]
实施例3：
[0062]
除上述实施例的技术特征以外，本实施例进一步地包括了以下技术特征：
[0063]
日志解析服务尊从主从协议。
[0064]
构建的canal-server服务尊从mysql数据库的主从协议，通过尊从主从协议，将canal-server服务伪装为mysql数据库的从库，然后配置关注mysql数据库中变更的表，mysql数据库将变更的binlog通过至canal-server服务，通过采用主从协议，对mysql数据库中变更的binlog进行同步，采用较少的cpu资源获取binlog，节约了cpu资源。
[0065]
实施例4：
[0066]
如图3所示，除上述实施例的技术特征以外，本实施例进一步地包括了以下技术特征：
[0067]
对变更的数据库数据进行合并操作，得到合并后的数据库数据，包括以下步骤：
[0068]
步骤s302，解析变更的数据库数据的前值和后值；
[0069]
步骤s304，根据前值和后值，进行合并操作，得到合并后的数据库数据的前值和后值，获取合并后的数据库数据。
[0070]
构建的canal-client服务，实时获取mysql数据库中表数据的变更，解析前值和后值，进行必要的合并操作(merge)，举例而言，数据表t的字段x值由a变更为b，再由b变更为c，当变更抓取到同一个批次里，对于下游用户而言，字段x值只是由a变更为c，则可以进行一次merge合并操作，通过合并操作，简化数据表中字段值的变更过程，降低代码的复杂程度，方便后续进行系统维护。
[0071]
实施例5：
[0072]
除上述实施例的技术特征以外，本实施例进一步地包括了以下技术特征：
[0073]
对变更的数据库数据进行合并操作时，获取数据库数据采用单线程处理。
[0074]
具体而言，合并操作需要采用单线程处理，确保可以获取每次字段值的变化，进而识别字段值连续变更的过程，实现合并操作，如果采用多线程处理，会造成无法识别字段值连续变更的情况。
[0075]
举例而言，数据表t的字段x值由a变更为b，再由b变更为c，当采用单线程时，可以
识别数据表t的字段x值由a变更为b，再由b变更为c，进而进行合并操作，使得字段x值只是由a变更为c，如果采用多线程，则无法识别数据表t的字段x值由a变更为b，再由b变更为c，造成无法进行合并操作。
[0076]
实施例6：
[0077]
如图4所示，除上述实施例的技术特征以外，本实施例进一步地包括了以下技术特征：
[0078]
消息配置方法还包括以下步骤：
[0079]
步骤s402，日志解析服务将处理的位点持久化至分布式应用程序协调服务上。
[0080]
日志解析服务将处理的位点持久化至分布式应用程序协调服务上。
[0081]
canal-server服务和canal-client服务将处理的位点持久化到分布式应用程序协调服务(zookeeper)上，并且，额外增加监控界面监控任务运行情况，并可配置报警，通过对监控任务运行情况，提高日志解析服务的准确性，针对出现问题的情况，通过报警进行提示，使得提示更加直观，便于发现。
[0082]
实施例7：
[0083]
如图5所示，除上述实施例的技术特征以外，本实施例进一步地包括了以下技术特征：
[0084]
获取合并后的数据库数据对应消息所在表格的字段，包括以下步骤：
[0085]
步骤s502，根据配置文件生成任务；
[0086]
步骤s504，获取合并后的数据库数据触发的任务；
[0087]
步骤s506，获取任务对应消息所在表格的字段。
[0088]
举例而言，将合并的结果同步远程过程调用(rpc)请求到任务计算和消息生成发送服务(worker)，worker得到数据后，根据xml配置文件(xml配置文件内配置了变更字段跟具体任务的关系、任务跟具体topic的关系、任务跟需要的业务表的关系、任务跟消息结果字段的关系)生成具体的任务(task)，任务进行处理，根据xml配置文件，运行计算出当前批次binlog合并完的结果会触发的任务，得到这些任务对应消息(topic)所在表格的字段，获取某个topic需要的表的数据，通过topic的需要字段按需配置具体topic的内容，进而，完成消息的从触发到组装到发送。
[0089]
本实施例中，获取任务对应消息所在表格的字段，具体而言，是指从配置里读取要发送消息的名称或者叫主题，还包括，从配置中读取消息对应的返回结果，返回结果包含字段(从配置中读取结果字段需要的具体表格和具体字段)。当一个消息topic需要多个表的数据时，其中，产生变更的为其中至少一个时，产生变更的表，通过表变化的前值和后值获取，另外没有发生变更的表数据，通过一次或者多次反查数据库获取。举例而言，假设一个消息topic需要3个表的数据，但只变更了3个表中的1个表，此时，得到1个表变化的前值和后值，另外2个表数据需要反查数据库。
[0090]
本实施例中，通过获取合并后的binlog触发的任务，得到任务对应消息所在表格的字段，基于得到的消息，根据需要的字段，进行消息内容的配置，消息与业务代码进行分离，不存在耦合情况，在消息中间件出现问题时，不影响业务系统的正常运行，提高了业务系统的运行的稳定性，并且，上线不需要重启服务，对业务系统的运行没有影响。
[0091]
实施例8：
[0092]
如图6所示，除上述实施例的技术特征以外，本实施例进一步地包括了以下技术特征：
[0093]
消息配置方法还包括以下步骤：
[0094]
步骤s602，对日志解析服务配置主库和从库；
[0095]
步骤s604，基于主库中断运行，从库切换为主库进行运行，切换过程中位点前推目标时间。
[0096]
canal-server服务和canal-client服务可以配置主库(master)和从库(slave)进行运行，同一时刻只有一个实例在运行，当运行的实例因异常情况中断运行，slave就会自动切换为master进行运行，切换的过程中位点自动前推目标时间，目标时间根据情况进行选择，举例而言，可以为一分钟。
[0097]
通过设置主库和从库，在遇到异常情况终端运行时，可以通过slave切换为master继续运行，提高了系统运行的稳定性，进行切换时，切换的过程中位点自动前推目标时间，保证不丢失数据，以及数据的准确。
[0098]
实施例9：
[0099]
如图7所示，本实施例提供了一种电子装置200，包括：存储器210和处理器220，存储器210存储有程序或指令，处理器220执行程序或指令；其中，处理器220在执行程序或指令时，实现如本发明任一实施例的消息配置方法的步骤。
[0100]
实施例10：
[0101]
本实施例提供了一种可读存储介质，可读存储介质存储有程序或指令，程序或指令被处理器执行时，实现上述任一实施例的消息配置方法的步骤。
[0102]
具体实施例：
[0103]
传统消息开发及发送方式有几个缺点：(1)耦合度高，消息发送逻辑与业务代码耦合在一起，一旦消息中间件出现问题，会导致业务系统不可用。(2)定制化困难，如果一个业务数据的变化需要给多个业务方发送消息并且需要的消息字段不一样的情况下，业务代码会变得复杂难以维护。(3)上线需要重启实例发布服务。(4)消息的重发困难，需要实现特定的业务逻辑查数据库进行重发消息。
[0104]
本实施例通过mysql数据库的binlog机制，可以实现消息的字段级配置化开发及上线。消息系统与业务代码完全分离，即使消息中间件出现问题不会影响业务的运行。可定制化配置开发上线，并且上线不需要重启服务，消息的重发方便，可以将binlog的位点回调到指定的位置发送指定时间后的消息。
[0105]
本实施例提供了一种消息配置方法，系统技术架构如图8所示，数据库110采用mysql数据库，数据库110设有n个database(数据库1至数据库n)，具体的包括：
[0106]
(1)将数据库110的binlog模式设置为row模式，可以借助一些开源的工具(典型的代表有阿里开源的canal等)，编写数据库日志变更增量获取服务120(canal-server服务)，该服务尊从数据库110的主从协议，将自己伪装为数据库110的从库，配置关注数据库110的发生变更的表，数据库110给数据库日志变更增量获取服务120同步binlog。
[0107]
(2)数据库变更数据合并服务130(canal-client服务)实时取到数据库110的表数据的变更，解析前值和后值，进行必要merge合并操作，例如，数据表t的字段x值由a至b至c的变更别抓取到同一个批次里，对于下游用户来说值只是由a至c的变更，则可以进行一次
merge合并操作。如果有业务上的表合并，也是在这一步进行操作，这步骤取binlog的过程采用单线程处理，不能使用多线程，保证取到的数据处理完之后再进行后续处理。
[0108]
(3)将合并的结果同步rpc请求到任务计算和消息生成发送服务140(worker)，任务计算和消息生成发送服务140拿到数据的根据配置文件150生成具体的task任务，任务进行处理。配置文件150采用xml配置文件，一个简单的xml配置文件如下：
[0109]
数据库字段与任务的映射关系配置：
[0110][0111]
关注数据库表中变化的字段值发生变更后，会产生哪些任务，上述计算机语言表述为：t1表的field1变更会产生001和002两个任务，后面经过业务处理过之后001和002两个任务最终产生2条消息。
[0112]
任务与topic的映射关系：
[0113][0114]
上述计算机语言表述为：001任务对应topic1消息，002任务对应topic2消息，其中，topic1和topic2泛指的消息名字。
[0115]
任务与关联标的对应关系(在反查的时候需要)：
[0116][0117]
例如，消息topic1的消息体需要3个表t1，t2，t3中的字段，如果数据库中只有表t1的字段值改变，t2，t3表的值没有发生变化，则可以从数据库变更的日志中抓到t1表的前值和后值，但是没有t2和t3表的值，结果中需要的t2和t3表中的值，则去数据库中进行查询，获取t2表和t3表的最新值。则上述计算机语言表述为：针对001任务，比较t1、t2、t3这3个表格的binlog抓取的数据变更，对于抓取到的数据变更，不用查询，针对没有抓取的数据变更，进行查表获取。举例而言，例如t2表变更抓到了，则t1和t3表的数据需要反查数据库，例如t2和t3表的同时抓到了，此时，只缺少t1表，则的就只查询t1表的，又如果t1、t2、t3在一批binlog里都抓取到了，则不用反查。
[0118]
消息返回结果的定制配置：
[0119][0120]
根据xml的配置运行计算出当前批次binlog合并完的结果会触发哪些任务，这些任务会关联到哪些topic，某个topic需要哪些表的数据(针对某个topic关注多个表的情况下，结果如果需要多个表的变更数据，本次只有一个表变更的时候需要反查数据的特殊情况)。通过topic的需要字段按需配置具体topic的内容，完成了消息的从触发到组装到发送。上述计算机语言表述为：针对任务001，进行消息的结果拼装的配置，将001任务对应的消息的结果需要的表格的字段数据取出，并进行拼装。t1.column1为t1表的column1列，t1.column2为t1表的column2列，t1.column5为t1表的column5列，t2.column3为t1表的column3列。
[0121]
worker最终把消息生成之后发送到消息平台上，通过中间件170实现。
[0122]
(4)在数据库变更数据合并服务130请求任务计算和消息生成发送服务140运行任务的时候需要使用同步请求，在任务计算和消息生成发送服务140中配置对应的线程池计算运行当前的任务，运行完成之后统一返回给数据库变更数据合并服务130结果。
[0123]
(5)对于任务的监控具体为：数据库日志变更增量获取服务120和数据库变更数据合并服务130会将处理的位点持久化到分布式应用程序协调服务160上，可以额外增加监控界面监控任务运行情况，并可配置报警。
[0124]
(6)还可以采用高可用配置，数据库日志变更增量获取服务120和数据库变更数据合并服务130可以配置master和slave进行运行，同一时刻只有一个实例在运行，当运行的实例因异常情况中断运行，slave就会自动切换为master进行运行，切换的过程中位点自动前推1分钟保证数据完全的准确不丢失。
[0125]
本实施例在单worker(8c8g)可承载至少3w每秒的topic生产和发送，并且通过配置可无限制扩展，特别适用于大量数据变更的场景。
[0126]
本实施例产生的有益效果为：
[0127]
(1)实现了消息系统与业务系统的解耦，消息中间件异常完全不会影响业务系统的运行。
[0128]
(2)高度的字段级可配置化：通过配置字段级的配置任务给不同的业务方进行精准的消息定制。
[0129]
(3)节约了cpu等资源，仅需要mysql主从同步的少量io。
[0130]
(4)上线可不重启服务，配置化上线。
[0131]
综上，本发明实施例的有益效果为：
[0132]
1.本实施例中，消息与业务代码进行分离，不存在耦合情况，在于消息中间件出现问题时，不影响业务系统的正常运行，提高了业务系统的运行的稳定性。
[0133]
2.本实施例中，获取合并后的binlog对应消息所在表格的字段，根据需要的字段，进行消息内容的配置，实现了消息的字段级配置，进而实现字段级消息的可定制化配置以及上线，不会增加业务代码的复杂程度，使得业务系统维护简单。
[0134]
3.本实施例中，上线不需要重启服务，对业务系统的运行没有影响。
[0135]
在本发明中，术语“第一”、“第二”、“第三”仅用于描述的目的，而不能理解为指示或暗示相对重要性；术语“多个”则指两个或两个以上，除非另有明确的限定。术语“安装”、“相连”、“连接”、“固定”等术语均应做广义理解，例如，“连接”可以是固定连接，也可以是可拆卸连接，或一体地连接；“相连”可以是直接相连，也可以通过中间媒介间接相连。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。
[0136]
本发明的描述中，需要理解的是，术语“上”、“下”、“左”、“右”、“前”、“后”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或单元必须具有特定的方向、以特定的方位构造和操作，因此，不能理解为对本发明的限制。
[0137]
在本说明书的描述中，术语“一个实施例”、“一些实施例”、“具体实施例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或实例。而且，描述的具体特征、结构、材料或特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
[0138]
以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。