日志处理方法、装置、电子设备及存储介质

技术领域

本公开涉及计算机技术领域，具体而言，涉及一种日志处理方法、装置、电子设备和存储介质。

背景技术

日志是指在应用程序或系统中记录事件、活动或状态的记录。它是开发人员和系统管理员常用的工具，用于故障排查、监控以及性能分析，通过日志记录和分析策略，可以加快故障排查以及进行性能优化。

相关技术中，通常采用ProtoBuffer(PB)传输协议对日志进行编码，并将编码后的日志存储到服务端，然而，此种方式在传输过程中，服务端需要对编码后的日志的全部内容进行解码，以获取存储地址，并将编码后的日志存储至相应的存储地址，由于日志的数据量较大，导致获取存储地址的过程所占用开销较大。

发明内容

本公开实施例至少提供一种日志处理方法、装置、电子设备及存储介质，可以降低服务端获取目标日志的存储地址的过程所占用开销。

本公开实施例提供了一种日志处理方法，包括：

接收客户端发送的目标日志；所述目标日志为所述客户端基于预设的日志传输协议对预设字段类型的原始日志进行编码后得到；所述目标日志的日志结构包括头部区域以及内容区域，所述头部区域包括路由字段区，所述路由字段区用于存储日志的存储属性信息，所述内容区域用于存储日志内容；

基于所述预设的日志传输协议，对所述路由字段区进行解码，以获取所述目标日志的存储属性信息，并基于所述目标日志的存储属性信息确定所述目标日志的存储地址，将所述目标日志存储到所述存储地址内。

本公开实施例中，由于编码得到目标日志的日志结构中包括路由字段区和内容区域，其中，路由字段区用于存储日志的存放位置，内容区域用于存储日志内容，这样，服务端在接收到目标日志后，即可对路由字段区进行解码，从而确定目标日志对应的存储地址，与相关技术中通过PB传输协议进行传输的方法相比，服务端无需对日志全部进行解码来获取目标日志的存储地址，如此，有利于降低获取存储地址的过程中所占用的开销。此外，由于路由字段区所占用的空间较小，还可以提升获取存储地址的效率。

在一种可能的实施方式中，所述基于所述目标日志的存储属性信息确定所述目标日志的存储地址，包括：

基于所述目标日志的存储属性信息，从预先构建的存储属性信息与存储地址的对应关系中，查找与所述目标日志的存储属性信息对应的目标存储地址，并将所述目标存储地址确定为所述目标日志的存储地址，其中，所述目标日志为所述客户端运行的目标微服务被调用所产生的日志，所述存储属性信息包括微服务的名称、微服务对应的主机名称以及微服务对应的主机网络地址中的至少一个。

本公开实施例中，所述存储属性信息可以上述目标微服务的名称、目标微服务对应的主机名称或者目标微服务对应的主机网络地址中的至少一种，通过基于预设的存储属性信息与存储地址的对应关系，确定目标日志的存储地址，如此，可以提升确定目标日志的存储地址的准确度。

在一种可能的实施方式中，所述头部区域还包括索引字段区，所述索引字段区包括多个索引字段；所述目标日志包括多条子日志，每条子日志对应至少一个索引字段，所述方法还包括：

针对每条子日志，确定所述子日志的日志属性信息，并将所述子日志的日志属性信息，存储到对应的索引字段中；所述日志属性信息用于查询对应的子日志。

本公开实施例中，由于每条子日志具有相应的日志属性信息，通过将每条子日志的日志属性信息存储到对应的索引字段中，这样，在查询时，即可对索引字段区中的索引字段进行遍历，而无需对日志内容进行查询，如此，可以减小查询范围，从而可以提升查询效率。

在一种可能的实施方式中，所述基于所述目标日志的存储属性信息确定所述目标日志的存储地址，将所述目标日志存储到所述存储地址内之后，所述方法还包括：

接收客户端发送的日志查询请求，所述日志查询请求携带待查询的日志信息；

基于所述待查询的日志信息，查找与所述待查询的日志信息对应的目标日志内容，并将所述目标日志内容发送至所述客户端。

本公开实施例中，服务端在接收到客户端的日志查询请求后，即可基于日志查询请求，查找与所述待查询的日志信息对应的目标日志内容，并将目标日志内容返回至客户端，从而实现日志内容的查询，并且用户可以通过客户端直观地查看目标日志内容。

在一种可能的实施方式中，所述待查询的日志信息包括待查询的日志属性信息或者待查询的日志内容信息；所述头部区域还包括索引字段区，所述索引字段区包括多个索引字段，所述索引字段用于存储日志属性信息；所述基于所述待查询的日志信息，查询与所述待查询的日志信息对应的目标日志内容，包括：

基于待查询的日志属性信息，从所述索引字段区中查找与所述待查询的日志属性信息匹配的目标日志属性信息，并基于所述目标日志属性信息，从所述存储地址内查找与所述目标日志属性信息关联的目标日志内容；或者，

基于所述待查询的日志内容信息，从所述存储地址内查找与所述待查询的日志内容信息匹配的目标日志内容。

本公开实施例中，服务端可以通过上述两种方式实现目标日志内容的查找，如此，可以提升日志内容查找方式的多样性，提升用户的日志查找体验。此外，通过将待查询的日志属性信息与索引字段区中存储的目标日志属性信息进行匹配，从而实现索引查找，如此，可以提升查找效率，基于待查询的日志内容信息查找目标日志内容，可以提升日志内容查找的准确度。

在一种可能的实施方式中，所述目标日志包括多条子日志；所述基于所述待查询的日志内容信息，从所述存储地址内查找与所述待查询的日志内容信息匹配的目标日志内容，包括：

对所述目标日志进行解码，得到与每条子日志对应的原始子日志，每个原始子日志包括多个日志内容；

针对每条原始子日志的每个日志内容，确定所述每个日志内容在内存中的指针；

基于各个指针对应的日志内容，确定与所述待查询的日志内容信息匹配的目标指针，从所述目标指针所述指示的存储地址中查找所述目标日志内容。

本公开实施例中，由于目标日志的解码过程是在内存中完成的，因此，在解码得到每个原始子日志的日志内容后，会将日志内容存储在内存中，同时生成日志内容在内存中的指针，从而基于指针查找对应的目标日志内容，与相关技术中PB传输协议需要将各个日志内容(字节形式)复制为string对象的方案进行解析相比，有利于节约内存空间，同时还可以缩减解码开销。

在一种可能的实施方式中，所述目标日志的日志结构还包括协议头，所述协议头用于存储协议信息，所述协议信息包括所述日志传输协议的版本号、日志压缩算法类型、日志长度以及协议校验信息；所述协议信息包括所述日志传输协议的版本号、日志压缩算法类型、日志长度以及协议校验信息中的至少一项，其中，所述日志传输协议的版本号用于表征生成所述目标日志所使用的日志传输协议的版本；所述日志压缩算法类型是指对所述原始日志进行压缩所使用的压缩算法；所述日志长度用于指示进行编码的日志的最大数据量；所述协议校验信息用于校验所述目标日志相对于所述原始日志是否存在错误。

本公开实施例中，由于日志传输协议的协议头包括日志传输协议的版本号、日志压缩算法类型、日志长度以及协议校验信息等元数据信息部分，以便客户端和服务端能够对日志进行正确解析和处理，其中，协议校验信息能够验证目标日志在客户端和服务端的传输过程中是否发生了损坏或篡改，可以确保日志的完整性和正确性。

本公开实施例提供了一种日志处理方法，包括：

获取原始日志，并基于预设的日志传输协议，对所述原始日志进行编码，得到目标日志；所述目标日志的日志结构包括头部区域以及内容区域，所述头部区域包括路由字段区，所述路由字段区用于存储日志的存储属性信息，所述内容区域用于存储日志内容

将所述目标日志发送到服务器，以使所述服务器基于所述路由字段区中的存储属性信息确定所述目标日志的存储地址，并所述目标日志存储到所述存储地址内。

本公开实施例中，由于目标日志的日志结构中包括路由字段区和内容区域，其中，路由字段区用于存储日志的存储属性信息，内容区域用于存储日志内容，这样，客户端基于日志传输协议对原始日志编码后，即可得到目标日志并将目标日志发送给服务端，这样，服务端在接收到目标日志后，即可对路由字段区进行解码，从而确定目标日志对应的存储地址，与相关技术中通过PB传输协议进行传输的方法相比，服务端无需对日志全部进行解码来获取目标日志的存储地址，如此，有利于降低获取存储地址的过程中所占用的开销。此外，由于路由字段区所占用的空间较小，还可以提升获取存储地址的效率。

在一种可能的实施方式中，所述原始日志包括多个原始子日志，所述原始子日志包括多个键值对，所述键值对包括关键字以及键值；所述基于预设的日志传输协议，对所述原始日志进行编码，得到目标日志，包括：

针对所述多个原始子日志，确定存在于所述多个原始子日志中的至少一个相同的原始关键字；

针对每个相同的原始关键字，将所述原始关键字替换为目标关键字，得到新的多个原始子日志，并对所述新的多个原始子日志进行编码，其中，所述目标关键字的字节长度小于所述原始关键字的字节长度。

本公开实施例中，通过将字节长度较小的目标关键字，对各个原始子日志中的每个相同的原始关键字进行替换，如此，可以降低原始日志的存储空间，达到日志压缩的目的，从而有利于提升编码效率。此外，在后续步骤对目标日志进行传输时，还可以节约传输带宽。

在一种可能的实施方式中，所述方法还包括：

响应于查询操作，生成日志查询请求；所述日志查询请求携带待查询的日志信息；

将所述日志查询请求发送至所述服务器；所述日志查询请求用于查找与所述待查询的日志信息对应的目标日志内容；

接收所述服务器发送的与所述待查询的日志信息对应的目标日志内容。

本公开实施例中，客户端可以发送日志查询请求至服务端，如此，可以从服务端获取到与日志查询请求携带的待查询的日志信息对应的目标日志内容，从而用户可以对目标日志内容进行查看，便于问题锁定和处理。

本公开实施例提供了一种日志处理装置，包括：

日志接收模块，用于接收客户端发送的目标日志；所述目标日志为所述客户端基于预设的日志传输协议对预设字段类型的原始日志进行编码后得到；所述目标日志的日志结构包括头部区域以及内容区域，所述头部区域包括路由字段区，所述路由字段区用于存储日志的存储属性信息，所述内容区域用于存储日志内容；

日志存储模块，用于基于所述预设的日志传输协议，对所述路由字段区进行解码，以获取所述目标日志的存储属性信息，并基于所述目标日志的存储属性信息确定所述目标日志的存储地址，将所述目标日志存储到所述存储地址内。

在一种可能的实施方式中，所述日志存储模块具体用于：

基于所述目标日志的存储属性信息，从预先构建的存储属性信息与存储地址的对应关系中，查找与所述目标日志的存储属性信息对应的目标存储地址，并将所述目标存储地址确定为所述目标日志的存储地址，其中，所述目标日志为所述客户端运行的目标微服务被调用所产生的日志，所述存储属性信息包括微服务的名称、微服务对应的主机名称以及微服务对应的主机网络地址中的至少一种。

在一种可能的实施方式中，所述头部区域还包括索引字段区，所述索引字段区包括多个索引字段；所述目标日志包括多条子日志，每条子日志对应至少一个索引字段，所述日志存储模块还用于：

针对每条子日志，确定所述子日志的日志属性信息，并将所述子日志的日志属性信息，存储到对应的索引字段中；所述日志属性信息用于查询对应的子日志。

在一种可能的实施方式中，所述装置还包括请求接收模块，所述请求接收模块用于：

接收客户端发送的日志查询请求，所述日志查询请求携带待查询的日志信息；

基于所述待查询的日志信息，查找与所述待查询的日志信息对应的目标日志内容，并将所述目标日志内容发送至所述客户端。

在一种可能的实施方式中，所述待查询的日志信息包括待查询的日志属性信息或者待查询的日志内容信息；所述头部区域还包括索引字段区，所述索引字段区包括多个索引字段，所述索引字段用于存储日志属性信息；所述请求接收模块具体用于：

基于待查询的日志属性信息，从所述索引字段区中查找与所述待查询的日志属性信息匹配的目标日志属性信息，并基于所述目标日志属性信息，从所述存储地址内查找与所述目标日志属性信息关联的目标日志内容；或者，

基于所述待查询的日志内容信息，从所述存储地址内查找与所述待查询的日志内容信息匹配的目标日志内容。

在一种可能的实施方式中，所述请求接收模块具体用于：

对所述目标日志进行解码，得到与每条子日志对应的原始子日志，每个原始子日志包括多个日志内容；

针对每条原始子日志的每个日志内容，所述日志内容在内存中的指针；

基于各个指针对应的日志内容，确定与所述待查询的日志内容信息匹配的目标指针，从所述目标指针所述指示的存储地址中查找所述目标日志内容。

在一种可能的实施方式中，所述目标日志的日志结构还包括协议头，所述协议头用于存储协议信息，所述协议信息包括所述日志传输协议的版本号、日志压缩算法类型、日志长度以及协议校验信息中的至少一项，其中，所述日志传输协议的版本号用于表征生成所述目标日志所使用的日志传输协议的版本；所述日志压缩算法类型是指对所述原始日志进行压缩所使用的压缩算法；所述日志长度用于指示进行编码的日志的最大数据量；所述协议校验信息用于校验所述目标日志相对于所述原始日志是否存在错误。

本公开实施例还提供了另一种日志处理装置，包括：

日志获取模块，用于获取原始日志，并基于预设的日志传输协议，对所述原始日志进行编码，得到目标日志；所述目标日志的日志结构包括头部区域以及内容区域，所述头部区域包括路由字段区，所述路由字段区用于存储日志的存储属性信息，所述内容区域用于存储日志内容

日志发送模块，用于将所述目标日志发送到服务器，以使所述服务器基于所述路由字段区中的存储属性信息确定所述目标日志的存储地址，并所述目标日志存储到所述存储地址内。

在一种可能的实施方式中，所述原始日志包括多个原始子日志，所述原始子日志包括多个键值对，所述键值对包括关键字以及键值；所述日志获取模块具体用于：

针对所述多个原始子日志，确定存在于所述多个原始子日志中的至少一个相同的原始关键字；

针对每个相同的原始关键字，将所述原始关键字替换为目标关键字，得到新的多个原始子日志，并对所述新的多个原始子日志进行编码，其中，所述目标关键字的字节长度小于所述原始关键字的字节长度。

在一种可能的实施方式中，所述装置还包括请求发送模块，所述请求发送模块具体用于：

响应于查询操作，生成日志查询请求；所述日志查询请求携带待查询的日志信息；

将所述日志查询请求发送至所述服务器；所述日志查询请求用于查找与所述待查询的日志信息对应的目标日志内容；

接收所述服务器发送的与所述待查询的日志信息对应的目标日志内容。

本公开实施例提供了一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述任一实施方式中所述的日志处理方法。

本公开实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述任一实施方式中所述的日志处理方法。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开实施例所提供的一种日志处理方法的流程图；

图2示出了本公开实施例所提供的一种日志传输协议的协议结构的示意图；

图3示出了本公开实施例所提供的另一种日志处理方法的流程图；

图4示出了本公开实施例所提供的一种日志处理装置的结构示意图；

图5示出了本公开实施例所提供的另一种日志处理装置的结构示意图；

图6示出了本公开实施例所提供的又一种日志处理装置的结构示意图；

图7示出了本公开实施例所提供的再一种日志处理装置的结构示意图；

图8示出了本公开一些实施例所提供的电子设备的示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

本文中术语“和/或”，仅仅是描述一种关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

可以理解的是，在使用本公开各实施例公开的技术方案之前，均应当依据相关法律法规通过恰当的方式对本公开所涉及个人信息的类型、使用范围、使用场景等告知用户并获得用户的授权。

日志是指在应用程序或系统中记录事件、活动或状态的记录。它是开发人员和系统管理员常用的工具，用于故障排查、监控以及性能分析，通过日志记录和分析策略，可以加快故障排查以及进行性能优化。为了便于对日志的管理，通常会将日志传输到服务端进行存储，由于日志的传输链路较长，在客户端产生日志后，会经过服务端的网关层、消费层以及存储层依次进行传输，最终完成日志的存储。

相关技术中，通常采用ProtoBuffer(PB)传输协议对日志进行编码，并将编码后的日志存储到服务端，然而，此种方式在传输过程中，需要对编码后的日志的全部内容进行解码，以获取存储地址，并将编码后的日志存储至相应的存储地址，由于日志的数据量较大，导致获取存储地址的过程所耗费的解码开销较大。

基于上述研究，本公开实施例提供一种日志处理方法，首先接收客户端发送的目标日志；所述目标日志为所述客户端基于预设的日志传输协议对预设字段类型的原始日志进行编码后得到；所述目标日志的日志结构包括头部区域以及内容区域，所述头部区域包括路由字段区，所述路由字段区用于存储日志的存储属性信息，所述内容区域用于存储日志内容；基于所述预设的日志传输协议，对所述路由字段区进行解码，以获取所述目标日志的存储属性信息，并基于所述目标日志的存储属性信息确定所述目标日志的存储地址，将所述目标日志存储到所述存储地址内，也即，本公开实施例中，在确定存储地址时，只需要对路由字段区进行解码，无需对目标日志的全部内容进行解码，有利于降低获取存储地址过程所占用的开销。

为便于对本实施例进行理解，首先对本公开实施例所提供的日志处理方法的执行主体进行详细介绍。本公开实施例所提供的日志处理方法的执行主体为服务端，所述服务端可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云存储、大数据和人工智能平台等基础云计算服务的云服务器。其他实施方式中，该日志处理方法还可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

下面结合附图对本申请实施例所提供的日志处理方法进行详细说明。参见图1所示，为本公开实施例提供的一种日志处理方法的流程图，该日志处理方法包括以下S101～S102：

S101，接收客户端发送的目标日志；所述目标日志为基于预设的日志传输协议对预设字段类型的原始日志进行编码后得到；所述目标日志的日志结构包括头部区域以及内容区域，所述头部区域包括路由字段区，所述路由字段区用于存储日志的存储属性信息，所述内容区域用于存储日志内容。

这里，客户端会生成原始日志，并对原始日志进行编码和压缩得到目标日志，并将目标日志发送至服务端。

其中，目标日志可以为基于预设的日志传输协议对预设字段类型的原始日志进行编码压缩后得到日志，其中，原始日志可以是微服务的日志，这里，所述微服务的日志是指微服务被调用所产生的日志，所述微服务是一种软件开发技术-面向服务的体系结构(SOA)架构样式的一种变体，它将单个应用程序划分成许多松散耦合且可独立部署的较小组件或服务，每个微服务运行在其独立的进程中。

示例性地，客户端运行有十个微服务，每个微服务对应一千条日志，则将每个微服务对应的一千条日志进行编码，得到十个目标日志，客户端会将将这十个目标日志以日志流的形式发送到服务器端。

应当理解，由于原始日志可能是不间断产生的，因此，客户端会将预设数量的原始日志进行编码压缩，得到目标日志，因此，所述目标日志可以包括多条子日志。

下面针对目标日志的日志结构进行详细说明，这里，需要说明的是，由于目标日志是基于日志传输协议对原始日志编码得到的，因此，目标日志的日志结构与日志传输协议的协议结构是类似的，因此，本实施方式中，首先对预设的日志传输协议进行详细介绍。

请参见图2，为本公开实施例提供的一种日志传输协议的协议结构示意图。如图2中所示，所述日志传输协议的协议结构包括协议头(ProtoHeaders)、头部区域(HeaderRegion)、内容区域(LogContents)以及临时区域(PaddingRegion)。

其中，所述协议头(ProtoHeaders)用于存储协议信息，所述协议信息包括所述日志传输协议的版本号、日志压缩算法类型、日志长度以及协议校验信息。这里，应当理解，日志传输协议可以具有多个版本，不同版本的版本号之间互不相同，例如V1版本、V2版本等，其中，不同客户端所使用的日志传输协议的版本可能不同，为了使得服务端能够对客户端发送的目标日志进行解码，需要在日志传输协议中约定好版本号。

所述日志压缩算法类型是指对原始日志进行压缩所使用的算法，本实施方式中，所述日志压缩算法可以是ZSTD(Zstandard)压缩算法，其中，ZSTD压缩算法具有高压缩比、高性能、可调节压缩率以及支持流式压缩和解压缩的优点，在其他实施方式中，还可以是无损压缩算法(例如LZ77或者LZ78压缩算法)、快速压缩算法(例如Snappy压缩算法或者LZ4压缩算法)等，在此并不限定。

所述日志长度是指该传输协议可以编码的日志的最大数据量，应当理解，由于日志通常是流式的，也即日志是不间断产生的，因此，通过设置日志长度，可以避免压缩的原始日志的数据量较大，占用较大的带宽和压缩开销。

所述协议校验信息用于对协议的全部内容进行校验，具体的，在日志传输协议中，校验信息用于验证传输过程中数据的完整性，以确保服务端可以检测到传输过程中可能出现的错误或篡改，也即，可以检测出目标日志相对于原始日志是否存在错误，本实施方式中，可以采用循环冗余校验CRC32进行校验，在其他实施方式中，还可以是采用其他校验方式，例如通过校验和进行校验或者基于散列函数进行校验，在此不做限定。

所述头部区域(HeaderRegion)包括字典字段Pattern、路由字段区CommonHeaders、索引字段区LogHeaders。本实施方式中，为了使得该头部区域的精简，所述头部区域的字段长度不大于256Byte，在其他实施方式中，头部区域的字段长度还可以是其他长度，在此不做限定。

其中，字典字段Pattern用于将协议中的重复字符串进行字典化，具体的，一些字符串的字节较多，并且这些字符串在日志中的显示频次较高，因此，可以对其进行字典化，通过字节数较少的字符串替换原字符串，例如，每条原始日志都有“message”字段，则可以将“message”字典化为数字“1”，再比如，每条原始日志都有“Level”字段，则可以将“level”字典化为数字“2”，这样，可以提升日志的压缩率。

所述路由字段区用于存储日志的存储属性信息，所述存储属性信息可以包括微服务的名称(service-name)、微服务对应的主机名称(hostname)以及微服务对应的主机网络地址(ip)中的至少一个。

应当理解，客户端将目标日志发送到服务端后，服务端需要对目标日志进行存储，因此，可以基于路由字段区中所存储的存储属性信息，将不同目标日志进行存储，这样，在后续步骤中对目标日志进行存储时，则无需对目标日志的全部内容进行解码，只需要对路由字段区进行解码即可，如此，可以提升解码效率。

其中，所述路由字段区可以包括多个路由字段(又称公共字段)，所述路由字段用于存储日志的存储属性信息，例如，路由字段1的内容为“service-name：1”，其中，所述路由字段区中的路由字段可以是客户端预先配置的，例如，客户端1可以设置将微服务的名称作为路由字段，客户端2可以将主机名称作为路由字段，客户端3还可以将微服务的名称和主机名称作为路由字段。

这里，需要说明的是，由于微服务是以分布式结构运行在不同主机上的，比如微服务1运行于主机A、B、C，微服务2运行于主机A和B，则服务1和服务2具有相同的主机名称为A和B，若以主机名称作为路由字段，则不同微服务对应的日志可以存储到同一存储地址中。

所述索引字段区LogHeaders包括多个索引字段，所述索引字段用于存储日志的属性信息，其中，所述属性信息可以包括时间戳Timestamp、日志标识LogID等，在其他实施方式中，所述属性信息还可以包括日志级别Log-level等，在此不做限定。

这里，所述预设字段类型包括字符串类型(String)、数值类型(例如long、int、double)以及复合类型(例如UUID、IPv4、IPv6)中的至少一种，其中，UUID(UniversallyUnique Identifier)是一种标准化的128位标识符，用于跟踪和标识日志记录，其具有高度唯一性和低重复率的优点；IPv4(Internet Protocol version 4)是互联网协议的第4个版本，它是目前广泛使用的IP地址格式，IPv4地址由32位二进制组成，通常以点分十进制表示。在日志中，IPv4地址常用于记录网络连接、客户端请求和服务器访问等信息；IPv6(Internet Protocol version 6)是互联网协议的第6个版本，它是IPv4的升级版，IPv6地址由128位二进制组成，通常以冒号分隔的十六进制表示，IPv6地址以其更大的地址空间和更好的网络支持，逐渐取代IPv4成为未来互联网的基础，在日志中，IPv6地址可以记录网络连接、IP流量和网络设备的信息。上述预设字段类型还可以根据客户端的实际需求进行填充或者缩减，在此不做限定，由于日志传输协议还支持上述字段类型中的至少一种，如此，可以提升日志处理的灵活性、提供日志的丰富性以及可扩展性，适应各种日志处理需求，并提供更可靠、可扩展和易于理解的数据传输和处理机制。

所述内容区域(LogContents)用于存储日志内容，所述日志内容可以包括message或者stack内容等，message是指日志条目中实际的文本消息或描述，堆栈信息stack记录了函数调用的层级关系和位置的信息，以及在出现错误或异常时，记录错误发生的堆栈轨迹。这里，所述内容区域包括多个内容字段，由于日志内容通常是以键值对的形式存在的，因此，可以将日志内容的键值对存储到内容字段中。由于日志内容的数据量较大，这里针对内容区域的字段长度不做限制。

所述临时区域(PaddingRegion)包括至少一个临时字段，在一些实施方式中，所述临时字段在进行日志存储时，可以用于填零对齐。

因此，基于上述分析可知，在基于上述日志传输协议对原始日志进行编码后，即可得到目标日志，因此，目标日志中也会包括协议头、头部区域、内容区域以及临时区域，因此，基于上述日志传输协议进行编码所得到的目标日志即可包括头部区域以及内容区域，其中，所述路由字段区用于存储所述目标日志的存储属性信息，所述内容区域用于存储所述目标日志的日志内容。

S102，基于所述预设的日志传输协议，对所述路由字段区进行解码，以获取所述目标日志的存储属性信息，并基于所述目标日志的存储属性信息确定所述目标日志的存储地址，将所述目标日志存储到所述存储地址内。

应当理解，在前文中介绍到所述路由字段区用于存储日志的存储属性信息，因此，目标日志的路由字段区则会存储所述目标日志的存储属性信息，服务器在接收到目标日志后，由于目标日志是基于预设的日志传输协议对原始日志编码得到的，需要基于预设的日志传输协议对路由字段区进行解码，如此，可以获取到所述目标日志的存储属性信息，并基于所述存储属性信息确定所述目标日志的存储地址，从而将目标日志存储到所述存储地址中，如此，有利于降低获取存储地址的过程中所占用的开销。

此外，由于路由字段区所占用的空间较小，还可以提升获取存储地址的效率。

需要说明的是，这里服务器在对目标日志进行存储时，通常是基于服务器的网关接收客户端发送的目标日志，然后网关通过对路由字段区中的路由字段进行定点解析，从而可以获取该目标日志的存储属性信息。

在一些实施方式中，在基于所述存储属性信息确定所述目标日志的存储地址时，可以基于预设的存储属性信息与存储地址的对应关系，确定所述目标日志的存储地址，具体的，基于所述目标日志的存储属性信息，从预先构建的存储属性信息与存储地址的对应关系中，查找与所述目标日志的存储属性信息对应的目标存储地址，并将所述目标存储地址确定为所述目标日志的存储地址。

也即，客户端可以预先构建存储属性信息与存储地址的对应关系，比如，若存储属性信息为微服务的名称，则可以针对该微服务名称，为其预先划分对应的存储地址，例如，为微服务1划分对应的存储地址为A，为微服务2划分对应的存储地址为B。需要说明的是，不同客户端所创建的存储属性信息与存储地址的对应关系可以是相同的，也可以是不同的，比如，客户端S1是基于微服务名称创建的对应关系，客户端S2是基于微服务所在主机的主机名称创建的对应关系，客户端S2还可以是基于微服务名称和微服务所在主机的主机名称共同创建的对应关系。

应当理解，由于路由字段区只能用于确定将目标日志存储到哪个存储地址中，而由于目标日志存储到服务器后，用户还可能需要对目标日志进行查询，因此，在一些实施方式中，还可以针对目标日志中的每条子日志，确定所述子日志的日志属性信息，并将所述子日志的日志属性信息，存储到对应的索引字段中，这样，客户端即可基于日志属性信息查询对应的子日志的日志内容。

这里，由于各条子日志之间是相互独立的，因此，每条子日志具有对应的属性信息，其中，所述属性信息可以包括时间戳、日志标识等信息，属性信息可以是键值对的形式，例如，子日志1的属性信息为Timestamp：2023-08-14 14:00:00或者LogID：1234；子日志2的属性信息为Timestamp：2023-08-14 14:01:00或者LogID：1237。

具体的，服务器可以接收任一客户端发送的日志查询请求，其中，所述日志查询请求携带待查询的日志信息，然后基于所述待查询的日志信息，确定与所述待查询的日志信息对应的目标日志内容，并将所述目标日志内容发送至所述客户端。

其中，所述日志查询请求携带的待查询的日志信息可以是指客户端需要查询的日志信息，比如，可以是时间戳、日志标识。

可以理解，客户端侧可以响应于用户的查询操作，通过客户端输入日志查询请求，并将该日志查询请求发送到服务器，这样，服务器在接收到客户端的日志查询请求后，即可基于日志查询请求中的待查询的日志信息，确定与待查询的日志信息对应的目标日志内容，这里，由于不同客户端输入的待查询的日志信息的不同，则确定的目标日志内容的内容也是不同的，这样，在确定目标日志内容后，即可将目标日志内容发送至客户端。

在一些实施方式中，由于所述待查询的日志信息可以包括待查询的日志属性信息，因此，在基于所述待查询的日志信息，查询与所述待查询的日志信息对应的目标日志内容时，可以基于待查询的日志属性信息，从所述索引字段区中查找与所述待查询的日志属性信息匹配的目标日志属性信息，并基于所述目标日志属性信息，从所述存储地址内查找与所述目标日志属性信息关联的目标日志内容。

这里，目标日志的日志属性信息与存储地址之间是预先关联好的。

可以理解，在将每个子日志的日志属性信息，存储到索引字段区中的索引字段中后，用户即可基于待查询的日志属性信息对任一子日志的日志内容进行查询，其中，待查询的日志属性信息可以是日志属性信息中的一种，还可以不包含于所述日志属性信息中，这里，若待查询的日志属性信息不包含于所述日志属性信息中，则服务端会返回空值，比如，用户可以输入针对时间戳Timestamp的查询语句(查询表达式)或者查询条件，从而服务器根据输入的查询语句或者查询条件返回相应的日志内容。也即，通过待查询的日志信息能够提高日志查询的速度和效率，减少查询耗时。

在另一些实施方式中，所述待查询的日志信息还可以包括待查询的日志内容信息，因此，在基于所述待查询的日志信息，查询与所述待查询的日志信息对应的目标日志内容时，还可以基于待查询的日志内容信息，从所述存储地址内查找与所述待查询的日志内容信息匹配的目标日志内容，并将目标日志内容发送至所述客户端。

与前述实施方式类似，用户还可以直接查询日志内容，具体的，用户可以在客户端输入待查询的日志内容信息生成日志查询请求并将日志查询请求发送至服务端，此时，服务端会基于日志查询请求中携带的待查询的日志内容信息，确定要查找的目标日志，然后，对该目标日志全部进行解码并对其进行遍历，得到与待查询的日志内容信息匹配的目标日志内容，并将目标日志内容返回至客户端。

这里，在基于所述待查询的日志内容信息，从所述存储地址内查找与所述待查询的日志内容信息匹配的目标日志内容时，可以先在内存中对所述目标日志进行解码，得到与每条子日志对应的原始子日志，其中，每个原始子日志包括多个日志内容，并针对每条原始子日志的每个日志内容，确定所述每个日志内容在内存中的指针，然后，基于各个指针对应的日志内容，确定与所述待查询的日志内容信息匹配的目标指针，并从所述目标指针所述指示的存储地址中查找所述目标日志内容。

这里，在对目标日志进行解码的过程是在内存中实现的，因此，在得到与每条子日志对应的原始子日志的日志内容后，会将日志内容存储在内存空间中，并针对每个日志内容，确定所述日志内容在内存中的指针，这样，即可基于各个指针对应的日志内容，确定与所述待查询的日志内容信息匹配的目标指针，从所述目标指针所述指示的存储地址中查找对应的目标日志内容，而在PB传输协议的编码规则中，字符串类型的字段是以字节形式进行编码的，当解析字节数据，并将其转换为字符串类型时，PB传输协议会通过将字节数据复制到新的String对象中来进行解析，当频繁解析大量字符串时，每次都要创建一个新的String对象，可能会造成内存中的空隙，并逐渐增加内存碎片化的程度，另一方面，这种拷贝操作可能会影响解析性能，对于大量的字符串拷贝操作，尤其是在频繁解析大量字符串时，拷贝整个字符串的操作涉及内存的分配、数据的复制，以及相关的内存管理开销，因此，相较于PB传输协议，本实施方式可以提升解码的效率。

请参见图3，为本公开实施例提供的另一种日志处理方法的流程图。该日志处理方法应用于客户端，所述客户端运行有至少一个微服务，其中，所述客户端可以运行于终端设备，该终端设备还可以为移动设备、用户终端、终端、手持设备、计算设备、车载设备、可穿戴设备等，在此不做限定。

如图3中所示，该日志处理方法包括以下步骤S301～S302：

S301，获取原始日志，并基于预设的日志传输协议，对所述原始日志进行编码，得到目标日志；所述目标日志的日志结构包括头部区域以及内容区域，所述头部区域包括路由字段区，所述路由字段区用于存储日志的存储属性信息，所述内容区域用于存储日志内容

这里，所述原始日志可以是指运行在上述客户端上的微服务被应用程序调用所产生的日志，所述原始日志包括多个原始子日志。

应当理解，在客户端产生原始日志后，即可基于预设的日志传输协议对所述原始日志进行编码，得到目标日志，这里，所述日志传输协议以及目标日志的相关描述已在前述实施例中说明，在此不做赘述。

可选的，在对原始日志进行编码时，可以通过不同模式进行编码，所述模式可以包括High-Level模式和Low-level模式，其中，High-Level模式通过预设的接口界面添加各个键值对，并调用Serialize接口来将各个键值对序列化为连续内存；Low-level模式通过将键值对追加到缓冲区中，最终调用Finish接口来填充协议头信息，从而完成日志编码。

S302，将所述目标日志发送到服务器，以使所述服务器基于所述路由字段区中的存储属性信息确定所述目标日志的存储地址，并所述目标日志存储到所述存储地址内。

可以理解，在得到编码后的目标日志后，即可将目标日志发送到服务器进行存储，从而可以对目标日志进行统一管理，这里，服务器对目标日志进行存储的存储过程请参见上述实施例中的描述内容，在此不做赘述。

在一些实施方式中，由于原始日志包括多个原始子日志，每个原始子日志包括多个键值对，且所述多个原始子日志中通常会包含较多重复的关键字，比如关键字message、关键字timestamp等，在编码时，这些相同的关键字会被多次编码，需要占用较大的开销，基于此，本实施方式中，在基于预设的日志传输协议，对所述原始日志进行编码，得到目标日志时，针对所述多个原始子日志，确定存在于所述多个原始子日志中的至少一个相同的原始关键字，并针对每个相同的原始关键字，将所述原始关键字替换为目标关键字，得到新的多个原始子日志，并对所述新的多个原始子日志进行编码，其中，所述目标关键字的字节长度小于所述相同的关键字的字节长度。

其中，针对每个相同的原始关键字，其对应的目标关键字是唯一的，且目标关键字的形式可以是英文，还可以是数字，在此不做限定。

示例性的，类似于关键字“message”，其字节长度为7，可以其替换为目标关键字“a”，可以看出“a”的字节长度为1，再比如，关键字“LogID”可以替换为目标关键字“b”，这样，使得字节长度由5变为1，如此，可以降低原始日志占用的存储空间，还可以降低编码过程中所占用的开销和带宽。

这里，所述传输协议的头部区域中包括Pattern字段，可以将字典化的原始关键字和目标关键字进行存储，这样，即可实现关键字的字典化。

可选的，在将目标日志存储到服务器后，用户可以基于客户端对服务器存储的目标日志进行查询，具体的，可以响应于查询操作，生成日志查询请求，其中，所述日志查询请求携带待查询的日志信息，然后客户端可以将日志查询请求发送至服务器，由于日志查询请求中携带待查询的日志信息，因此，服务器可以根据待查询的日志信息查找与该待查询的日志信息对应的日志内容。

这里，由于本申请中的日志传输协议的协议结构中的索引字段中存储有日志属性信息，所述内容区域中存储有日志内容信息，因此，所述待查询的日志信息可以包括待查询的日志属性信息或者待查询的日志内容信息，如此，用户可以基于待查询的日志属性信息或者待查询的日志内容信息进行日志查询，如此，可以提升查询方式的多样性。

示例性地，以待查询的日志属性信息LogID进行查询，其对应的查询语句可以是以下形式：

select*from table_name

where LogID＝'123456'

limit 1000；

基于上述查询语句，即可查找到前1000条日志中的LogID为“123456”的日志内容。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一技术构思，本公开实施例中还提供了与日志处理方法对应的日志处理装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述日志处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图4所示，为本公开实施例提供的一种日志处理装置的示意图，所述装置400包括：

日志接收模块401，用于接收客户端发送的目标日志；所述目标日志为所述客户端基于预设的日志传输协议对预设字段类型的原始日志进行编码后得到；所述目标日志的日志结构包括头部区域以及内容区域，所述头部区域包括路由字段区，所述路由字段区用于存储日志的存储属性信息，所述内容区域用于存储日志内容；

日志存储模块402，用于基于所述预设的日志传输协议，对所述路由字段区进行解码，以获取所述目标日志的存储属性信息，并基于所述目标日志的存储属性信息确定所述目标日志的存储地址，将所述目标日志存储到所述存储地址内。

在一种可能的实施方式中，所述日志存储模块402具体用于：

基于所述目标日志的存储属性信息，从预先构建的存储属性信息与存储地址的对应关系中，查找与所述目标日志的存储属性信息对应的目标存储地址，并将所述目标存储地址确定为所述目标日志的存储地址，其中，所述目标日志为所述客户端运行的目标微服务被调用所产生的日志，所述存储属性信息包括微服务的名称、微服务对应的主机名称以及微服务对应的主机网络地址中的至少一个。

在一种可能的实施方式中，所述日志传输协议的头部区域还包括索引字段区，所述索引字段区包括多个索引字段；所述目标日志包括多条子日志，每条子日志对应至少一个索引字段，所述日志存储模块402还用于：

针对每条子日志，确定所述子日志的日志属性信息，并将所述子日志的日志属性信息，存储到对应的索引字段中；所述日志属性信息用于查询对应的子日志。

参照图5所示，为本公开实施例所提供的另一种日志处理装置的示意图，所述装置400还包括请求接收模块403，所述请求接收模块403用于：

接收客户端发送的日志查询请求，所述日志查询请求携带待查询的日志信息；

基于所述待查询的日志信息，查找与所述待查询的日志信息对应的目标日志内容，并将所述目标日志内容发送至所述客户端。

在一种可能的实施方式中，所述待查询的日志信息包括待查询的日志属性信息或者待查询的日志内容信息，所述头部区域还包括索引字段区，所述索引字段区包括多个索引字段，所述索引字段用于存储日志属性信息；所述请求接收模块403具体用于：

基于待查询的日志属性信息，从所述索引字段区中查找与所述待查询的日志属性信息匹配的目标日志属性信息，并基于所述目标日志属性信息，从所述存储地址内查找与所述目标日志属性信息关联的目标日志内容；或者，

基于所述待查询的日志内容信息，从所述存储地址内查找与所述待查询的日志内容信息匹配的目标日志内容。

在一种可能的实施方式中，所述目标日志包括多条子日志；所述请求接收模块403具体用于：

对所述目标日志进行解码，得到与每条子日志对应的原始子日志，每个原始子日志包括多个日志内容；

针对每条原始子日志的每个日志内容，确定所述每个日志内容在内存中的指针；

基于各个指针对应的日志内容，确定与所述待查询的日志内容信息匹配的目标指针，从所述目标指针所述指示的存储地址中查找所述目标日志内容。

在一种可能的实施方式中，所述目标日志的日志结构还包括协议头，所述协议头用于存储协议信息，所述协议信息包括所述日志传输协议的版本号、日志压缩算法类型、日志长度以及协议校验信息中的至少一项，其中，所述日志传输协议的版本号用于表征生成所述目标日志所使用的日志传输协议的版本；所述日志压缩算法类型是指对所述原始日志进行压缩所使用的压缩算法；所述日志长度用于指示进行编码的日志的最大数据量；所述协议校验信息用于校验所述目标日志相对于所述原始日志是否存在错误。

参见图6所示，为本公开实施例提供的又一种日志处理装置的示意图，所述装置600包括：

日志获取模块601，用于获取原始日志，并基于预设的日志传输协议，对所述原始日志进行编码，得到目标日志；所述目标日志的日志结构包括头部区域以及内容区域，所述头部区域包括路由字段区，所述路由字段区用于存储日志的存储属性信息，所述内容区域用于存储日志内容

日志发送模块602，用于将所述目标日志发送到服务器，以使所述服务器基于所述路由字段区中的存储属性信息确定所述目标日志的存储地址，并所述目标日志存储到所述存储地址内。

在一种可能的实施方式中，所述原始日志包括多个原始子日志，所述原始子日志包括多个键值对，所述键值对包括关键字以及键值；所述日志获取模块601具体用于：

针对所述多个原始子日志，确定存在于所述多个原始子日志中的至少一个相同的原始关键字；

针对每个相同的原始关键字，将所述原始关键字替换为目标关键字，得到新的多个原始子日志，并对所述新的多个原始子日志进行编码，其中，所述目标关键字的字节长度小于所述原始关键字的字节长度。

参见图7所示，为本公开实施例提供的再一种日志处理装置的示意图，所述装置600还包括请求发送模块603，所述请求发送模块603具体用于：

响应于查询操作，生成日志查询请求；所述日志查询请求携带待查询的日志信息；

将所述日志查询请求发送至所述服务器；所述日志查询请求用于查找与所述待查询的日志信息对应的目标日志内容；

接收所述服务器发送的与所述待查询的日志信息对应的目标日志内容。

关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

基于同一技术构思，本公开实施例还提供了一种电子设备。参照图8所示，为本公开实施例提供的电子设备800的结构示意图，包括处理器801、存储器802、和总线803。其中，存储器802用于存储执行指令，包括内存8021和外部存储器8022；这里的内存8021也称内存储器，用于暂时存放处理器801中的运算数据，以及与硬盘等外部存储器8022交换的数据，处理器801通过内存8021与外部存储器8022进行数据交换。

本申请实施例中，存储器802具体用于存储执行本申请方案的应用程序代码，并由处理器801来控制执行。也即，当电子设备800运行时，处理器801与存储器802之间通过总线803通信，使得处理器801执行存储器802中存储的应用程序代码，进而执行前述任一实施例中所述的方法。

其中，存储器802可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read－Only Memory，PROM)，可擦除只读存储器(Erasable Programmable Read－Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read－Only Memory，EEPROM)等。

处理器801可能是一种集成电路芯片，具有信号的处理能力。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(NetworkProcessor，NP)等；还可以是数字信号处理器(DSP，Digital Signal Processing)、专用集成电路(ASIC，Application Specific Integrated Circuit)、现场可编程门阵列(FPGA，Field Programmable Gate Array)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备800的具体限定。在本申请另一些实施例中，电子设备800可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中的日志处理方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例还提供一种计算机程序产品，该计算机程序产品承载有程序代码，所述程序代码包括的指令可用于执行上述方法实施例中的日志处理方法的步骤，具体可参见上述方法实施例，在此不再赘述。

其中，上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。