CN113760845A - 一种日志处理方法、***、装置、客户端及存储介质 - Google Patents

Abstract

本发明实施例公开了一种日志处理方法、***、装置、客户端及存储介质。该方法应用于日志处理客户端，该方法包括：基于中间件获取变更操作日志，其中，变更操作日志是日志获取服务端在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时发送的相应的日志；根据变更操作日志中各消息体的类型从变更操作日志中筛选出隶属于同一事务的目标消息体，对目标消息体进行处理，并将处理结果存储于日志数据库中，处理结果包括变更操作前的数据和变更操作后的数据。本发明实施例的技术方案，达到了同时获取到变更操作前的数据和变更操作后的数据的效果。

Description

一种日志处理方法、***、装置、客户端及存储介质

技术领域

本发明实施例涉及计算机应用技术领域，尤其涉及一种日志处理方法、***、装置、客户端及存储介质。

背景技术

目前各大***多是采用MySQL来管理数据，如商品***对应的MySQL中存储有上亿数据，这些数据涵盖了商品信息、类目信息等等。面对如此大量的数据，为了清晰记录用户对这些数据的操作过程，商品日志处理***应运而生。

目前已有的商品日志***的架构是ELK(Elasticsearch+Logstash+Kibana)架构，其中，Logstash作为管道从MySQL读取日志数据，并将读取结果存储于Elasticsearch中，Kibana是一个基于Web的图形界面，其可将存储在Elasticsearch中的日志数据进行可视化。

在实现本发明的过程中，发明人发现现有技术中存在以下技术问题：现有的商品日志处理***无法获取到变更操作前的数据，用户体验较差。

发明内容

本发明实施例提供了一种日志处理方法、***、装置、客户端及存储介质，解决了日志处理***无法获取到变更操作前的数据的问题。

第一方面，本发明实施例提供了一种日志处理方法，应用于日志处理客户端，该方法可以包括：

基于中间件获取变更操作日志，其中，变更操作日志是日志获取服务端在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时发送的相应的日志；

根据变更操作日志中各消息体的类型从变更操作日志中筛选出隶属于同一事务的目标消息体，对目标消息体进行处理，并将处理结果存储于日志数据库中，处理结果包括变更操作前的数据和变更操作后的数据。

第二方面，本发明实施例还提供了一种日志处理***，可包括：日志数据库、以及配置有中间件的日志处理客户端和日志获取服务端，其中，日志处理客户端，用于执行本发明任意实施例所提供的日志处理方法。

第三方面，本发明实施例还提供了一种日志处理装置，配置于日志处理客户端，该装置可以包括：

日志获取模块，用于基于中间件获取变更操作日志，其中，变更操作日志是日志获取服务端在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时发送的相应的日志；

日志处理模块，用于根据变更操作日志中各消息体的类型从变更操作日志中筛选出隶属于同一事务的目标消息体，对目标消息体进行处理，并将处理结果存储于日志数据库中，处理结果包括变更操作前的数据和变更操作后的数据。

第四方面，本发明实施例还提供了一种日志处理客户端，可以包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现本发明任意实施例所提供的日志处理方法。

第五方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现本发明任意实施例所提供的日志处理方法。

本发明实施例的技术方案，通过中间件获取到变更操作日志后，可以根据该变更操作日志中各消息体的类型从该变更操作日志中筛选出隶属于同一事务的目标消息体，并对该目标消息体进行处理，由此可以分别得到变更操作前的数据和变更操作后的数据，其中，上述变更操作日志可以是日志获取服务端在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时，获取后发送的相应的日志。上述技术方案，基于中间件从二进制日志中获取出现日志变更的变更操作日志，并对从该变更操作日志中筛选出的隶属于同一事务的目标消息体进行处理，达到了同时获取到变更操作前后的数据的效果，进而提升了用户的使用体验。

附图说明

图1是本发明实施例一中的一种日志处理方法的流程图；

图2是本发明实施例二中的一种日志处理***的结构示意图；

图3是本发明实施例三中的一种日志处理***的结构示意图；

图4是本发明实施例三中的一种日志处理***的应用示意图；

图5是本发明实施例四中的一种日志处理装置的结构框图；

图6是本发明实施例五中的一种日志处理客户端的结构示意图。

具体实施方式

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

实施例一

图1是本发明实施例一中提供的一种可应用于日志处理客户端的日志处理方法的流程图。本实施例可适用于对获取到的变更操作日志进行处理以分别得到变更操作前后的数据的情况。该方法可以由本发明实施例提供的日志处理装置来执行，该装置可以由软件和/或硬件的方式实现。

参见图1，本发明实施例的方法具体包括如下步骤：

S110、基于中间件获取变更操作日志，其中，变更操作日志是日志获取服务端在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时发送的相应的日志。

其中，关系型数据库是一种建立在关系模型基础上的数据库，如MySQL、SQLServer、oracle、Access、interbase等等。对存储于关系型数据库中的数据进行变更操作时涉及到的相关信息可以记录在二进制日志(binlog)中，binlog是一种二进制格式的日志文件，该相关信息可以包括变更操作前的数据、变更操作后的数据、操作库名、操作表名、表类型、表主键、操作类型、操作时间、操作来源、操作人、操作ip等等，其中，操作库名是该变更操作对应的数据库的名字，操作表名是该变更操作对应的表的名字，表类型是表的类型如商品表、类目(sku)表等等，表主键是业务主键即ID，操作类型可以是更新(update)、删除(delete)、***(insert)等等。在此基础上，可选的，操作人和操作ip可以记录在binlog或是op_log表中，当它们的记录路径不同时，日志处理***可以从相应的记录路径中读取到操作人和操作ip。

日志获取服务端上可以配置有需要记录变更操作日志的数据库及其对应的表的地址，以便根据该地址对相应的二进制日志进行监听。由此，日志获取服务端在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时，可以从该二进制日志中获取到出现日志变更的并更操作日志，并将该变更操作日志发送给亦配置有该中间件的日志处理客户端。可选的，当日志获取服务端需要记录变更操作日志的数据库和/或表出现新增和/或删除时，可以在该日志获取服务端进行相应配置，以便该日志获取服务端对新增的数据库和/或表对应的binlog进行监听、和/或对删除的数据库和/或表对应的binlog不再进行监听。

示例性的，以关系型数据库是MySQL且中间件是canal为例，对日志获取服务端的读取过程进行示例性说明。其中，MySQL的工作原理是，MySQL中存在主(master)从(slave)关系，master将变更操作日志记录到binlog中，这些记录可以称为二进制日志事件(binarylog events)，其可以通过show binlog events进行查看；slave将master的binary logevents拷贝到自己的中继日志(relay log)中；slave重做中继日志中的事件以将变更操作日志反映它自己的数据。由此，canal可以模拟MySQL的slave的交互协议，将自己伪装为slave以向MySQL的master发送dump请求；master在收到dump请求后将binlog中的变更操作日志推送给canal，以使配置有canal的日志获取服务端获取到变更操作日志。

S120、根据变更操作日志中各消息体的类型从变更操作日志中筛选出隶属于同一事务的目标消息体，对目标消息体进行处理，并将处理结果存储于日志数据库中，其中，处理结果包括变更操作前的数据和变更操作后的数据。

其中，由于变更操作日志可能涉及到多个事务，为确保后续的日志处理过程是针对一个完整的事务进行处理，日志处理客户端在接收到日志获取服务端发送来的变更操作日志之后，可以根据变更操作日志中各消息体的类型从变更操作日志中筛选出隶属于同一事务的目标消息体，例如，该类型可以是事务开启、变更操作前后的数据和事务结束，即事务开启的消息体、变更操作前后的数据的消息体和事务结束的消息体可以构成一个完整的事务，这些消息体是隶属于同一事务的目标消息体。

进一步，对该目标消息体进行处理，即对隶属于同一事务的各消息体一起进行处理，由此避免出现将半个变更操作记录下来的情况。其中，上述处理过程可以根据实际的业务场景进行选择，例如，若变更操作日志包括多个字段，则可以将该多个字段中与日志处理***无关的字段进行过滤，示例性的，该与日志处理***无关的字段可以是那些未出现变更操作的数据，如多个字段是keyVlue^keyVlue^keyVlue^…，每个keyVlue均包括变更操作前的数据和变更操作后的数据，由此可以在各keyVlue的内部进行分析以从中过滤出未出现变更操作的数据所在的字段，即仅保留那些出现变更操作的数据所在的字段；再如，可以对该多个字段中的特殊字段进行特殊处理且对通用字段进行通用处理，该特殊处理可以是根据具体的业务场景自定义的处理逻辑；等等。在此基础上，经由上述处理过程处理后的目标消息体(即，处理结果)可以包含变更操作前的数据、变更操作后的数据、操作库名、操作表名、表类型、表主键、操作类型、操作时间、操作来源、操作人、操作ip等等信息。

再进一步，可以将处理结果发送给日志数据库以将它们存储于该日志数据库中，该日志数据库可以是Elasticsearch、Hbase等等，其中，Hbase是支持海量数据存储的数据库。在此以Hbase为例，上述存储过程可以是将处理结果封装为包含变更操作前的数据、变更操作后的数据、操作库名、操作表名、表类型、表主键、操作类型、操作时间、操作来源、操作人、操作ip等等信息的对象，并将该对象存入Hbase中。可选的，假设某个目标消息体中出现变更操作的数据所在的字段的数量是至少两个，则可以将这些字段封装为不同的对象以在Hbase中分别进行存储，由此提高了数据存储的清晰度。

本发明实施例的技术方案，通过中间件获取到变更操作日志后，可以根据该变更操作日志中各消息体的类型从该变更操作日志中筛选出隶属于同一事务的目标消息体，并对该目标消息体进行处理，由此可以分别得到变更操作前的数据和变更操作后的数据，其中，上述变更操作日志可以是日志获取服务端在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时，获取后发送的相应的日志。上述技术方案，基于中间件从二进制日志中获取出现日志变更的变更操作日志，并对从该变更操作日志中筛选出的隶属于同一事务的目标消息体进行处理，达到了同时获取到变更操作前后的数据的效果，进而提升了用户的使用体验。

一种可选的技术方案，关系型数据库中各表的表信息封装在common包中且common包配置在日志处理客户端中，表信息包括表名，对目标消息体进行处理，具体可以包括：从各表名中筛选出与目标消息体对应的目标表名，并基于common包中记录的目标表名对应的处理策略对目标消息体进行处理。

其中，为了使关系型数据库和其中的表具有灵活的可扩展性，可以将表的相关信息封装在独立的common包，如将各种关系型数据库以及每个关系型数据库中的各种表的相关信息封装在一个common包中，且在日志处理客户端直接引入该common包，即将该common包配置在日志处理客户端上，此时无需再日志处理客户端重新定义表的相关信息，且可通过该common对表的相关信息进行处理，即在需要新增和/或删减表、或新增、变更和/或删减表的相关信息时，直接在conmon包中进行相应变更即可，并在日志处理客户端重新引入该common包即可，而无需在日志处理客户端上进行代码修改。上述common包相当于一个工具包，其可包含表名(即，表类型)、表编号、表主键、表字段以及描述等等信息。

在此基础上，在对目标消息体进行处理时，可以先从common包中的各表名中筛选出与目标消息体对应的目标表名，如目标消息体中可以包含其对应的表名，但根据该目标消息体的表名无法确定其对应的表是个什么样的表，此时可以根据已经引入的common包中的各表名确定其是个什么样的表，即根据与目标消息体的表名相对应的common包中的目标表名确定其是个什么样的表；由此，可以根据这样的表对应的处理策略对目标消息体进行处理，以便对一些需要特殊处理的表按照自定义逻辑进行特殊处理。

一种可选的技术方案，日志数据库包括Hbase；将处理结果存储于日志数据库中，具体可以包括：根据处理结果确定行键计算因素，并根据行键计算因素计算出行键，将处理结果存储在Hbase中与行键相应的存储区间中。其中，Hbase是nosql(not only sql)数据库，在增删改查过程中，行键(rowkey)充当了主键的作用，其可以唯一地标识一行数据。行键计算因素是用于计算rowkey的因素，其具体选择、以及根据行键计算因素计算rowkey的具体过程均可以根据实际的业务场景而定，示例性的，该行键计算因素可以包括目标消息体的表类型、表主键、操作时间戳和操作版本号中的至少一个，根据该行键计算因素可以预先设置一个rowkey规则来计算rowkey。由此，可以将处理结果存储在Hbase中的与行键相应的存储区间中。示例性的，以行键计算因素包括表类型、反转的表主键、64位有符号最大值、操作时间戳和操作版本号为例，64位有符号最大值是预设数值，操作时间戳是更新操作日志的操作时间对应的时间戳，操作版本号是在将处理结果封装为一个对象时，该对象对应的版本号，基于预先设置的rowkey规则生成的rowkey是由按照表类型+反转的业务主键+(64位有符号最大值-操作时间戳-操作版本号)的二进制数组组成。在此基础上，可选的，为了使不同的处理结果分散到Hbase的不同的存储区间中，在计算得到rowkey之后，可以重新计算一下它的哈希值，并处理结果存储在Hbase中与哈希值相应的存储区间中，由此避免了热点数据的出现。

一种可选的技术方案，上述日志处理方法，还可以包括：从分布式服务中读取操作时间，将操作时间和当前时间进行比较，并反馈比较结果，其中，操作时间是接入至分布式服务中的日志获取服务端从变更操作日志中获取到后写入分布式服务中的时间。其中，分布式服务可以是一个分布式的、开放源码的分布式应用程序协调服务，其可以封装好复杂易出错的关键服务，并将简单易用的接口提供给用户应用；操作时间是变更操作日志出现的时间，当前时间是日志处理客户端在执行上述步骤时的时间。可选的，上述分布式服务可以是zookeeper。

考虑到本发明实施例可能涉及到的应用场景，该分布式服务可以用于记录关系型数据库的操作位点，该操作位点即为变更操作日志的操作时间。由此，当日志获取服务端和日志处理客户端上均配置有该分布式服务的地址以接入该分布式服务的注册中心时，日志获取服务端可以从变更操作日志中获取到操作时间，并将该操作时间写入该分布式服务中；进而，日志处理客户端可以从该分布式服务中获取到该操作时间，并根据该操作时间和当前时间的比较结果执行其余操作，比如，根据比较结果确定是否需要对某些技术进行优化、监控日志处理***的当前工作状态是否存在异常等等。

示例性的，当日志处理客户端在对某变更操作日志进行处理时，其可以将操作时间和当前时间进行比较，若二者差异较大则说明该变更操作日志未进行及时处理，这可能是由于日志获取服务端未及时获取到该变更操作日志、日志处理客户端因待处理的变更操作日志较多而致使当前正在处理的变更操作日志未能得到及时处理等等原因造成的；再示例性的，当日志处理客户端在将处理结果存储到Hbase中时，其可以将操作时间和当前时间进行比较，若二者差异较大则说明该变更操作日志未进行及时存储，这可能是由于日志获取服务端未及时获取到该变更操作日志、日志处理客户端因待处理的变更操作日志较多而致使当前正在处理的变更操作日志未能得到及时处理、日志处理客户端因待存储的处理结果较多而致使当前正在存储的处理结果未能得到及时存储等等原因造成的。换言之，在根据比较结果确定存在延时现象时，可以进行原因排查以进行技术优化、确定日志处理***的当前工作状态是否存在异常等等。

实施例二

在介绍实施例二之前，先对现有技术中的ELK架构再次进行详细分析：首先，Logstash在运行时因占用CPU和内存较高而资源消耗较高；另外，其是从MySQL的表中读取日志数据，这一读取过程会对MySQL产生较大压力、且读取结果仅是操作更新后的数据(即，增量更新)，其亦无法对读取结果直接进行操作。其次，Elasticsearch可以提供日志数据的搜集、分析和存储这三大功能，它更适合于在读取操作较多的应用场景中应用，而日志处理***中大多涉及的是写入操作，读取操作多是在排查问题这种少量场景下才会出现。再次，Kibana的可视化功能在以日志数据的记录为主的日志处理***中更是显得无关紧要。

相应的，图2是本发明实施例二中提供的一种日志处理***的结构示意图。本实施例可适用于对关系型数据库中的变更操作进行记录的情况。参见图2，本发明实施例的日志处理***，可以包括：

配置有中间件的日志获取服务端20、配置有中间件的日志处理服务端21以及日志数据库22，其中，日志获取服务端20，用于在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时，获取相应的变更操作日志，并将变更操作日志发送给日志处理服务端21；日志处理服务端21，用于根据变更操作日志中各消息体的类型从变更操作日志中筛选出隶属于同一事务的目标消息体，并对目标消息体进行处理，将处理结果存储于日志数据库22中，其中，处理结果包括变更操作前的数据和变更操作后的数据。

需要说明的是，本发明实施例所述的日志处理***是基于中间件从binlog中读取变更操作日志，这能做到接近实时的变更操作日志的同步，且即使面临海量数据也不会对关系型数据库造成压力而对线上业务造成影响，这亦可以对读取结果直接进行操作以分别得到变更操作前后的数据，该变更操作前后的数据是日志处理***中不可缺少的关键数据。由此，上述日志处理***，在面对海量数据时，依然可以准确且实时记录这些海量数据相关的变更操作，在提升日志处理***的性能和稳定性的同时，降低了资源消耗成本。

本发明实施例的技术方案，通过日志获取服务端在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时，获取相应的变更操作日志，并将该变更操作日志发送给配置有中间件的日志处理客户端；该日志处理客户端可以根据该变更操作日志中各消息体的类型从中筛选出隶属于同一事务的目标消息体，并对该目标消息体进行处理，将处理结果存储于日志数据库中，该处理结果可以包括变更操作前的数据和变更操作后的数据。上述技术方案，基于中间件从二进制日志中获取出现日志变更的变更操作日志，并对从该变更操作日志中筛选出的隶属于同一事务的目标消息体进行处理，达到了同时获取到变更操作前后的数据的效果，提升了用户的使用体验。

实施例三

图3是本发明实施例三中提供的一种日志处理***的结构示意图。本实施例以上述各技术方案为基础进行优化。在本实施例中，可选的，上述日志处理***，还可以包括日志搜索服务端，用于根据接收到的用户输入的搜索条件在日志数据库中进行搜索，并将搜索到的与搜索条件匹配的目标数据进行返回。其中，与上述各实施例相同或相应的术语的解释在此不再赘述。

参见图3，本实施例的日志处理***，可以包括：配置有中间件的日志获取服务端30、配置有中间件的日志处理客户端31、日志数据库32、以及日志搜索服务端33，其中，日志获取服务端30，用于在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时，获取相应的变更操作日志，并将变更操作日志发送给日志处理客户端31；日志处理客户端31，用于根据变更操作日志中各消息体的类型从变更操作日志中筛选出隶属于同一事务的目标消息体，并对目标消息体进行处理，将处理结果存储于日志数据库32中，其中，处理结果包括变更操作前的数据和变更操作后的数据；日志搜索服务端33，用于根据接收到的用户输入的搜索条件在日志数据库32中进行搜索，并将搜索到的与搜索条件匹配的目标数据进行返回。

其中，日志搜索服务端33可以提供一个前端页面以便用户根据在该前端页面中输入搜索条件，由此，其在接收到用户输入的搜索条件之后，可以根据该搜索条件在日志数据库32中进行搜索，以搜索出与该搜索条件相匹配的目标数据，并将该目标数据返回给前端页面来展示给用户。示例性的，考虑到本发明实施例可能涉及到的应用场景，该前端页面(即web页面)可以基于vm和/或js实现，其可以实现表类型、表主键、操作时间的时间段、关键字等内容的选择功能和/或输入功能，由此，日志搜索服务端33根据用户的选择内容和/或输入内容可以构成搜索条件，并根据该搜索条件在日志数据库32中进行搜索以将与该搜索条件相匹配的目标数据进行返回。

需要说明的是，Elasticsearch提供的搜索功能所搜索出来的搜索结果是一串字符串，该字符串中包括各种类型的数据，这样的搜索结果对于用户而言可读性较差，用户很难从这堆叠在一起的各种数据中找到数据间的关联性。相应的，基于本发明实施例所述的日志搜索服务端搜索出来的目标数据可以将各种类型的数据分开呈现，如将变更操作前的数据摆放在页面左侧且将变更操作后的数据摆放在页面右侧，由此提高了搜索结果的可读性。

本发明实施例的技术方案，通过日志搜索服务端接收用户输入的搜索条件，并根据该搜索条件在日志数据库中搜索出相匹配的目标数据进行返回，达到了对存储于日志数据库中的数据进行快速且精准搜索的效果。

在此基础上，可选的，日志数据库包括Hbase，日志搜索服务端，具体用于根据接收到的用户输入的搜索条件计算出行键，并将Hbase中与行键相应的存储区间中的目标数据进行返回。其中，正如上文所述，当日志数据库是Hbase时，其存储的具体的存储区间与计算出的rowkey有关。因此，在根据搜索条件于Hbase中进行搜索时，也可以先根据搜索条件计算出rowkey，在将Hbase中与该rowkey相应的存储区间中存储的数据作为目标数据。需要说明是，若搜索条件中的操作时间是一个时间段，则可以根据该时间段的起始时间和结束时间分别计算出一个rowkey，并将这两个rowkey所在的存储区间以及位于这两个存储区间中间的存储区间中的数据作为目标数据。

进一步，可选的，搜索条件包括关键字，关系型数据库中各表的表信息封装在common包中且common包配置在日志搜索服务端中，表信息包括表的各属性信息间的映射关系；日志搜索服务端，还用于根据关键字和映射关系对目标数据进行筛选，并根据筛选结果更新目标数据。其中，rowkey所在的存储区间中的数据不一定都是用户需要的目标数据，此时可以通过用户输入的关键字对其进行再次筛选。需要说明的是，每个数据可以由多个字段构成，关键字所在的字段可能只是这多个字段中的一个，因此，为根据关键字这一个字段确定出其余的相应字段，可以将每个表的各属性信息间的映射关系封装在common包中，并将该common包配置在日志搜索服务端，以便日志搜索服务端根据common包中的映射关系确定出与关键字匹配的其余属性信息，每个属性信息可以占据至少一个字段。示例性的，可以将表类型和表编号映射为一个HashMap，将表类型和表主键映射为一个HashMap，将表编号和表主键映射为一个HashMap，且将表类型和表描述信息映射为一个HashMap。以关键字是表编号为例，根据上述HashMap可以确定与该表编号相应的其余属性信息，根据这些属性信息可以对搜索结果再次进行筛选。

为了更好地理解上述日志处理***的具体工作过程，下面结合具体示例，对本实施例的日志处理***进行示例性的说明。例如，如图4所示，该日志处理***可包括canalserver(即，配置有中间件canal的日志获取服务端)、canalclient(即，配置有中间件canal的日志处理客户端)、Log Search Web(即，提供前端页面的日志搜索服务端)和Hbase，其中，canal server基于canal从MySQL抓取到变更操作日志，并将抓取结果发送给canalclient；进而，canal client对接收到的变更操作日志进行分析过滤等等一系列处理，并将处理结果存储于Hbase中；由此，后续Log Search Web可以根据用户输入的搜索条件在Hbase中找到匹配的目标数据，由此实现了变更操作日志的实时获取和精确搜索的效果。

实施例四

图5为本发明实施例四提供的日志处理装置的结构框图，该装置可配置于日志处理客户端，该装置用于执行上述实施例一所提供的日志处理方法。该装置与上述实施例一的日志处理方法属于同一个发明构思，在日志处理装置的实施例中未详尽描述的细节内容，可以参考上述日志处理方法的实施例。参见图5，该装置具体可包括：日志获取模块410和日志处理模块420。

其中，日志获取模块410，用于基于中间件获取变更操作日志，其中，变更操作日志是日志获取服务端在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时发送的相应的日志；

日志处理模块420，用于根据变更操作日志中各消息体的类型从变更操作日志中筛选出隶属于同一事务的目标消息体，对目标消息体进行处理，并将处理结果存储于日志数据库中，其中，处理结果包括变更操作前的数据和变更操作后的数据。

可选的，关系型数据库中各表的表信息封装在common包中且common包配置在日志处理客户端中，表信息包括表名；

相应的，日志处理模块420，具体可以包括：

日志处理单元，用于从各表名中筛选出与目标消息体对应的目标表名，并基于common包中记录的目标表名对应的处理策略对目标消息体进行处理。

可选的，日志数据库包括Hbase，日志处理模块420，具体可包括：

日志存储单元，用于根据处理结果确定行键计算因素，并根据行键计算因素计算出行键，将处理结果存储在Hbase中与行键相应的存储区间中；

其中，行键计算因素包括目标消息体的表类型、表主键、操作时间戳和操作版本号中的至少一个。

可选的，日志存储单元，还可以用于：重新计算行键的哈希值，并根据计算结果更新行键。

可选的，在上述装置的基础上，该装置还可包括：

时间比较模块，用于从分布式服务中读取操作时间，将操作时间和当前时间进行比较，并反馈比较结果，其中，操作时间是接入至分布式服务中的日志获取服务端从变更操作日志中获取到后写入分布式服务中的时间。

本发明实施例四提供的日志处理装置，日志获取模块和日志处理模块相互配合，通过中间件获取到变更操作日志后，可以根据该变更操作日志中各消息体的类型从该变更操作日志中筛选出隶属于同一事务的目标消息体，并对该目标消息体进行处理，由此可以分别得到变更操作前的数据和变更操作后的数据，其中，上述变更操作日志可以是日志获取服务端在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时，获取后发送的相应的日志。上述装置，基于中间件从二进制日志中获取出现日志变更的变更操作日志，并对从该变更操作日志中筛选出的隶属于同一事务的目标消息体进行处理，达到了同时获取到变更操作前后的数据的效果，进而提升了用户的使用体验。

本发明实施例所提供的日志处理装置可执行本发明任意实施例所提供的日志处理方法，具备执行方法相应的功能模块和有益效果。

值得注意的是，上述日志处理装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本发明的保护范围。

实施例五

图6为本发明实施例五提供的一种日志处理客户端的结构示意图，如图6所示，该日志处理客户端包括存储器510、处理器520、输入装置530和输出装置540。日志处理客户端中的处理器520的数量可以是一个或多个，图6中以一个处理器520为例；日志处理客户端中的存储器510、处理器520、输入装置530和输出装置540可以通过总线或其它方式连接，图6中以通过总线550连接为例。

存储器510作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的日志处理方法对应的程序指令/模块(例如，日志处理装置中的日志获取模块410和日志处理模块420)。处理器520通过运行存储在存储器510中的软件程序、指令以及模块，从而执行日志处理客户端的各种功能应用以及数据处理，即实现上述的日志处理方法。

存储器510可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序；存储数据区可存储根据日志处理客户端的使用所创建的数据等。此外，存储器510可以包括高速随机存取存储器，还可以包括非易失性存储器，如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器510可进一步包括相对于处理器520远程设置的存储器，这些远程存储器可以通过网络连接至设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置530可用于接收输入的数字或字符信息，以及产生与装置的用户设置以及功能控制有关的键信号输入。输出装置540可包括显示屏等显示设备。

实施例六

本发明实施例六提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种日志处理方法，该方法应用于日志处理客户端，该方法可以包括：

基于中间件获取变更操作日志，其中，变更操作日志是日志获取服务端在基于中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时发送的相应的日志；

根据变更操作日志中各消息体的类型从变更操作日志中筛选出隶属于同一事务的目标消息体，对目标消息体进行处理，并将处理结果存储于日志数据库中，其中，处理结果包括变更操作前的数据和变更操作后的数据。

当然，本发明实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本发明任意实施例所提供的日志处理方法中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。依据这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (12)

1.一种日志处理方法，其特征在于，应用于日志处理客户端，包括：

基于中间件获取变更操作日志，其中，所述变更操作日志是日志获取服务端在基于所述中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时发送的相应的日志；

根据所述变更操作日志中各消息体的类型从所述变更操作日志中筛选出隶属于同一事务的目标消息体，对所述目标消息体进行处理，并将处理结果存储于日志数据库中，所述处理结果包括变更操作前的数据和变更操作后的数据。

2.根据权利要求1所述的方法，其特征在于，所述关系型数据库中各表的表信息封装在common包中且所述common包配置在所述日志处理客户端中，所述表信息包括表名，所述对所述目标消息体进行处理，包括：

从各所述表名中筛选出与所述目标消息体对应的目标表名，并基于所述common包中记录的所述目标表名对应的处理策略对所述目标消息体进行处理。

3.根据权利要求1所述的方法，其特征在于，所述日志数据库包括Hbase，所述将处理结果存储于日志数据库中，包括：

根据处理结果确定行键计算因素，并根据所述行键计算因素计算出行键，将所述处理结果存储在Hbase中与所述行键相应的存储区间中；

其中，所述行键计算因素包括所述目标消息体的表类型、表主键、操作时间戳和操作版本号中的至少一个。

4.根据权利要求3所述的方法，其特征在于，在所述根据所述行键计算因素计算出行键之后，还包括：

重新计算所述行键的哈希值，并根据计算结果更新所述行键。

5.根据权利要求1所述的方法，其特征在于，还包括：

从分布式服务中读取操作时间，将所述操作时间和当前时间进行比较，并反馈比较结果，其中，所述操作时间是接入至所述分布式服务中的所述日志获取服务端从所述变更操作日志中获取到后写入所述分布式服务中的时间。

6.一种日志处理***，其特征在于，包括：日志数据库、及配置有中间件的日志处理客户端和日志获取服务端，其中，所述日志处理客户端，用于执行权利要求1-5中任一项所述的日志处理方法。

7.根据权利要求6所述的***，其特征在于，还包括：

日志搜索服务端，用于根据接收到的用户输入的搜索条件在所述日志数据库中进行搜索，并将搜索到的与所述搜索条件匹配的目标数据进行返回。

8.根据权利要求7所述的***，其特征在于，所述日志数据库包括Hbase；

所述日志搜索服务端，具体用于根据接收到的用户输入的搜索条件计算出行键，并将Hbase中与所述行键相应的存储区间中的目标数据进行返回。

9.根据权利要求8所述的***，其特征在于，所述搜索条件包括关键字，所述关系型数据库中各表的表信息封装在common包中且所述common包配置在所述日志搜索服务端中，所述表信息包括所述表的各属性信息间的映射关系；

所述日志搜索服务端，还用于根据所述关键字和所述映射关系对所述目标数据进行筛选，并根据筛选结果更新所述目标数据。

10.一种日志处理装置，其特征在于，配置于日志处理客户端，包括：

日志获取模块，用于基于中间件获取变更操作日志，其中，所述变更操作日志是日志获取服务端在基于所述中间件监听到预先设置的关系型数据库的二进制日志进行日志变更时发送的相应的日志；

日志处理模块，用于根据所述变更操作日志中各消息体的类型从所述变更操作日志中筛选出隶属于同一事务的目标消息体，对所述目标消息体进行处理，并将处理结果存储于日志数据库中，其中，所述处理结果包括变更操作前的数据和变更操作后的数据。

11.一种日志处理客户端，其特征在于，包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-5中任一所述的日志处理方法。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-5任一所述的日志处理方法。

Images