日志数据的存储方法、装置、客户端及服务器
技术领域
本说明书一个或多个实施例涉及计算机技术领域,尤其涉及一种日志数据的存储方法、装置、客户端及服务器。
背景技术
传统技术中,服务器通常会采用结构化的方式存储客户端采集到的日志数据,如,将日志数据存储到mysql数据库中。当通过结构化的方式存储日志数据时,具有关联关系的日志数据(简称关联日志)可能会分布在不同数据表的多行记录中。从而业务系统在查询上述关联日志时,需要关联查询数据库的多张数据表,之后再将查询到的多条日志数据进行拼装,以得到上述关联日志。
因此,需要提供一种日志数据的存储方法,以提高日志数据的读取效率。
发明内容
本说明书一个或多个实施例描述了一种日志数据的存储方法、装置、客户端及服务器,可以提高日志数据的读取效率。
第一方面,提供了一种日志数据的存储方法,包括:
服务器获取格式化处理后的日志数据;所述格式化处理包括为原始日志数据添加用于构造行键rowkey的关键信息以及动态列名;
对所述格式化处理后的日志数据进行解析,以获取所述关键信息以及所述动态列名;
根据所述关键信息,生成所述rowkey;
根据所述rowkey以及所述动态列名,将所述原始日志数据写入Hbase数据库的对应位置。
第二方面,提供了一种日志数据的存储方法,包括:
客户端采集原始日志数据;
确定与所述原始日志数据对应的用于构造行键rowkey的关键信息以及动态列名;
根据所述关键信息以及所述动态列名,对所述原始日志数据进行格式化处理;
向服务器发送格式化处理后的日志数据,以使所述服务器对所述格式化处理后的日志数据进行解析,获取所述关键信息以及所述动态列名,并根据所述关键信息,生成所述rowkey;还使所述服务器根据所述rowkey以及所述动态列名,将所述原始日志数据写入Hbase数据库的对应位置。
第三方面,提供了一种日志数据的存储装置,包括:
获取单元,用于获取格式化处理后的日志数据;所述格式化处理包括为原始日志数据添加用于构造行键rowkey的关键信息以及动态列名;
解析单元,用于对所述获取单元获取的所述格式化处理后的日志数据进行解析,以获取所述关键信息以及所述动态列名;
生成单元,用于根据所述关键信息,生成所述rowkey;
写入单元,用于根据所述生成单元生成的所述rowkey以及所述动态列名,将所述原始日志数据写入Hbase数据库的对应位置。
第四方面,提供了一种日志数据的存储装置,包括:
采集单元,用于采集原始日志数据;
确定单元,用于确定与所述采集单元采集的所述原始日志数据对应的用于构造行键rowkey的关键信息以及动态列名;
处理单元,用于根据所述确定单元确定的所述关键信息以及所述动态列名,对所述原始日志数据进行格式化处理;
发送单元,用于向服务器发送所述处理单元格式化处理后的日志数据,以使所述服务器对所述格式化处理后的日志数据进行解析,获取所述关键信息以及所述动态列名,并根据所述关键信息,生成所述rowkey;还使所述服务器根据所述rowkey以及所述动态列名,将所述原始日志数据写入Hbase数据库的对应位置。
第五方面,提供了一种服务器,包括:
接收器,用于获取格式化处理后的日志数据;所述格式化处理包括为原始日志数据添加用于构造行键rowkey的关键信息以及动态列名;
至少一个处理器,用于对所述格式化处理后的日志数据进行解析,以获取所述关键信息以及所述动态列名;根据所述关键信息,生成所述rowkey;根据所述rowkey以及所述动态列名,将所述原始日志数据写入Hbase数据库的对应位置。
第六方面,提供了一种客户端,包括:
至少一个处理器,用于采集原始日志数据;确定与所述原始日志数据对应的用于构造行键rowkey的关键信息以及动态列名;根据所述关键信息以及所述动态列名,对所述原始日志数据进行格式化处理;
发送器,用于向服务器发送格式化处理后的日志数据,以使所述服务器对所述格式化处理后的日志数据进行解析,获取所述关键信息以及所述动态列名,并根据所述关键信息,生成所述rowkey;还使所述服务器根据所述rowkey以及所述动态列名,将所述原始日志数据写入Hbase数据库的对应位置。
本说明书一个或多个实施例提供的日志数据的存储方法、装置、客户端及服务器,客户端采集原始日志数据。为原始日志数据添加对应的用于构造行键rowkey的关键信息以及动态列名,得到格式化处理后的日志数据。向服务器发送格式化处理后的日志数据。服务器对格式化处理后的日志数据进行解析,以获取上述关键信息以及动态列名。根据关键信息,生成rowkey。根据rowkey以及动态列名,将原始日志数据写入Hbase数据库的对应位置。需要说明的是,关联日志通常具有相同的关键信息,从而构造的rowkey可以是相同的。由于关联日志的rowkey相同,所以本说明书的日志数据的存储方法可以确保关联日志存储在Hbase数据库的同一行。由此,可以提高关联日志的读取效率。
附图说明
为了更清楚地说明本说明书实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1为本说明书提供的日志数据的存储方法的应用场景示意图;
图2为本说明书一个实施例提供的日志数据的存储方法流程图;
图3为本说明书另一个实施例提供的日志数据的存储方法流程图;
图4为本说明书再一个实施例提供的日志数据的存储方法信息交互图;
图5为本说明书一个实施例提供的日志数据的存储装置示意图;
图6为本说明书另一个实施例提供的日志数据的存储装置示意图;
图7为本说明书提供的服务器示意图;
图8为本说明书提供的客户端示意图。
具体实施方式
下面结合附图,对本说明书提供的方案进行描述。
本说明书一个或多个实施例提供的日志数据的存储方法可以应用于如图1所示的场景中。图1中,客户端用于采集业务系统的日志数据。对采集到的日志数据,客户端可以进行格式化处理,如,为日志数据添加用于生成行键(rowkey)的关键信息以及动态列名。客户端可以将格式化处理后的日志数据输出到日志文件中。之后,将该日志文件通过传输媒介发送至服务器。
服务器在接收到日志文件之后,对该日志文件中的每行格式化处理后的日志数据,可以对其进行解析,以获取对应的关键信息和动态列名。之后,根据关键信息,生成rowkey,并根据rowkey以动态列名,将原始日志数据写入Hbase数据库的对应位置。至此,就可以实现将关联日志存储到Hbase数据库的同一行的不同列。此处,可以将关联日志存储在Hbase数据库的同一行,是因为关联日志通常具有相同的关键信息,如,具有相同的跟踪标识traceID或者业务标识,进而生成的rowkey是相同的,而rowkey为Hbase数据库的一行数据的唯一标识。此外,由于关联日志可以具有不同的动态列名,如,在多线程场景下,可以将日志数据对应的线程名作为动态列名,所以可以保证其分布在同一行的不同列。
由于关联日志存储在Hbase数据库的同一行,所以业务系统根据待读取的关联日志所对应的rowkey,就可以读取到上述关联日志,无需进行关联查询,也无需对日志数据进行拼装,从而可以提高关联日志的读取效率。
图2为本说明书一个实施例提供的日志数据的存储方法流程图。所述方法的执行主体可以为图1中的服务器。如图2所示,所述方法具体可以包括:
步骤202,服务器获取格式化处理后的日志数据。
具体地,在业务系统处理业务时,会得到相应的业务数据。客户端可以从中筛选感兴趣的业务数据并记录。此处,客户端记录的感兴趣的业务数据即为采集到的原始日志数据。
在采集到原始日志数据之后,客户端可以结合当前场景来确定用于构建rowkey的关键信息以及动态列名。具体地,如果当前场景为多线程场景,则可以将业务系统当前所处理业务的业务标识作为上述关键信息。需要说明的是,在多线程场景下,当业务系统调用多个线程并行处理同一业务时,客户端所采集到的各条原始日志数据的业务标识相同。在本说明书中,具有相同业务标识的多条原始日志数据可以称为关联日志。对于上述关联日志,为了对其进行相互区分,可以将对应的线程名作为动态列名。如,某条原始日志数据是在执行线程A所采集到时,可以将该原始日志数据的动态列名确定为线程A。
如果当前场景为远程过程调用(Remote Procedure Call,RPC)场景,可以将traceID作为上述关键信息。需要说明的是,在RPC场景下,执行一次RPC调用,客户端所采集到的各条原始日志数据的traceID是相同的。在本说明书中,具有相同traceID的多条原始日志数据也可以称为关联日志。同样地,为了对该场景下的关联日志进行相互区分,可以将服务器标识作为动态列名。如,某条原始日志数据是在调用服务器X所采集到时,可以将该原始日志数据的动态列名确定为服务器X的标识。
在确定用于构造行键rowkey的关键信息以及动态列名之后,客户端可以为原始日志数据添加上述关键信息以及动态列名,以得到格式化处理后的日志数据:<rowkeyInfo><dynamicColName><rawLogData>,其中,rowkeyInfo可以为用于构建rowkey的关键信息;dynamicColName可以为动态列名;rawLogData可以为原始日志数据。
应理解,上述只是一种格式化处理的实现方式。在其它实施方式中,也可以将“<>”替换为“()”或者“{}”等其它特殊字符。或者,也可以将上述关键信息或者动态列名添加到原始日志数据之后等,本说明书对此不作限定。
在得到上述格式化处理后的日志数据之后,可以将该格式化处理后的日志数据输出到日志文件中。当该日志文件的大小达到阈值大小时,可以将该日志文件通过传输媒介发送至服务器。此处的传输媒介可以是一种可以实时传输数据的介质。
当服务器接收到日志文件时,步骤202具体可以为:从日志文件中读取一行格式化处理后的日志数据。
步骤204,对格式化处理后的日志数据进行解析,以获取上述关键信息以及动态列名。
具体地,可以根据服务器与客户端预先协商好的解析规则,来对格式化处理后的日志数据进行解析。如,该解析规则可以为:第一个“<>”的内容用于表示上述关键信息,第二个“<>”的内容用于表示上述动态列名,第三个“<>”的内容用于表示原始日志数据等。
应理解,上述解析规则仅为了示例性的目的,并且本说明书决不被限制于这里描述的特殊示例性实施例。
步骤206,根据关键信息,生成rowkey。
如,可以将关键信息作为rowkey。
步骤208,根据rowkey以及动态列名,将原始日志数据写入Hbase数据库的对应位置。
在一种实现方式中,可以基于rowkey、动态列名以及原始日志数据构造put对象。之后,通过执行该put对象的写入操作,来实现原始日志数据的写入。
可以理解的是,当日志文件中包括多行格式化处理后的日志数据时,上述步骤202、步骤204、步骤206以及步骤208可以是重复执行的。
本说明书上述实施例描述的日志数据的存储方法可以确保关联日志存储在Hbase数据库的同一行。由此,可以提高关联日志的读取效率。
图3为本说明书另一个实施例提供的日志数据的存储方法流程图。所述方法的执行主体可以为图1中的客户端。如图3所示,所述方法具体可以包括:
步骤302,客户端采集原始日志数据。
具体地,在业务系统处理业务时,会得到相应的业务数据。客户端可以从中筛选感兴趣的业务数据并记录。此处,客户端记录的感兴趣的业务数据即为采集到的原始日志数据。
步骤304,确定与原始日志数据对应的用于构造行键rowkey的关键信息以及动态列名。
在一种实现方式中,客户端可以结合当前场景来确定上述关键信息以及动态列名。具体地,如果当前场景为多线程场景,则可以将业务系统当前所处理业务的业务标识作为上述关键信息。需要说明的是,在多线程场景下,当业务系统调用多个线程并行处理同一业务时,客户端所采集到的各条原始日志数据的业务标识相同。在本说明书中,具有相同业务标识的多条原始日志数据可以称为关联日志。对于上述关联日志,为了对其进行相互区分,可以将对应的线程名作为动态列名。如,某条原始日志数据是在执行线程A所采集到时,可以将该原始日志数据的动态列名确定为线程A。
如果当前场景为远程过程调用(Remote Procedure Call,RPC)场景,可以将traceID作为上述关键信息。需要说明的是,在RPC场景下,执行一次RPC调用,客户端所采集到的各条原始日志数据的traceID是相同的。在本说明书中,具有相同traceID的多条原始日志数据也可以称为关联日志。同样地,为了对该场景下的关联日志进行相互区分,可以将服务器标识作为动态列名。如,某条原始日志数据是在调用服务器X所采集到时,可以将该原始日志数据的动态列名确定为服务器X的标识。
步骤306,根据关键信息以及动态列名,对原始日志数据进行格式化处理。
在一种实现方式中,上述格式化处理可以包括为原始日志数据添加用于构造行键rowkey的关键信息以及动态列名。对原始日志数据进行格式化处理之后,可以得到格式化处理后的日志数据。如,格式化处理后的日志数据可以为:<rowkeyInfo><dynamicColName><rawLogData>,其中,rowkeyInfo可以为用于构建rowkey的关键信息;dynamicColName可以为动态列名;rawLogData可以为原始日志数据。
应理解,上述只是一种格式化处理的实现方式。在其它实施方式中,也可以将“<>”替换为“()”或者“{}”等其它特殊字符。或者,也可以将上述关键信息或者动态列名添加到原始日志数据之后等,本说明书对此不作限定。
可以理解的是,当客户端采集到多条原始日志数据时,上述步骤302,步骤304以及步骤306可以是重复执行的。
步骤308,向服务器发送格式化处理后的日志数据。
此处,可以将格式化处理后的日志数据输出到日志文件中。当该日志文件的大小达到阈值大小时,可以将该日志文件通过传输媒介发送至服务器。此处的传输媒介可以是一种可以实时传输数据的介质。
服务器从日志文件中依次读取各行格式化处理后的日志数据。解析格式化处理后的日志数据,以获取关键信息以及动态列名。具体地,可以根据服务器与客户端预先协商好的解析规则,来对格式化处理后的日志数据进行解析。如,该解析规则可以为:第一个“<>”的内容用于表示上述关键信息,第二个“<>”的内容用于表示上述动态列名,第三个“<>”的内容用于表示原始日志数据等。
应理解,上述解析规则仅为了示例性的目的,并且本说明书决不被限制于这里描述的特殊示例性实施例。
之后,服务器可以根据关键信息,生成rowkey。如,可以将关键信息作为rowkey。根据rowkey以及动态列名,将原始日志数据写入Hbase数据库的对应位置。在一种实现方式中,可以基于rowkey、动态列名以及原始日志数据构造put对象。之后,通过执行该put对象的写入操作,来实现原始日志数据的写入。
本说明书上述实施例描述的日志数据的存储方法可以实现对日志数据进行格式化处理,从而服务器通过对该格式化处理后的日志数据进行解析,来得到用于生成rowkey的关键信息以及动态列名。之后,根据rowkey以及动态列名,将关联日志存储在Hbase数据库的同一行。由此,可以提高关联日志的读取效率。
图4为本说明书再一个实施例提供的日志数据的存储方法信息交互图。如图4所示,所述方法具体可以包括:
步骤402,客户端采集原始日志数据。
具体地,在业务系统处理业务时,会得到相应的业务数据。客户端可以从中筛选感兴趣的业务数据并记录。此处,客户端记录的感兴趣的业务数据即为采集到的原始日志数据。
步骤404,确定与原始日志数据对应的用于构造行键rowkey的关键信息以及动态列名。
在一种实现方式中,客户端可以结合当前场景来确定上述关键信息以及动态列名。具体地,如果当前场景为多线程场景,则可以将业务系统当前所处理业务的业务标识作为上述关键信息。需要说明的是,在多线程场景下,当业务系统调用多个线程并行处理同一业务时,客户端所采集到的各条原始日志数据的业务标识相同。在本说明书中,具有相同业务标识的多条原始日志数据可以称为关联日志。对于上述关联日志,为了对其进行相互区分,可以将对应的线程名作为动态列名。如,某条原始日志数据是在执行线程A所采集到时,可以将该原始日志数据的动态列名确定为线程A。
如果当前场景为远程过程调用(Remote Procedure Call,RPC)场景,可以将traceID作为上述关键信息。需要说明的是,在RPC场景下,执行一次RPC调用,客户端所采集到的各条原始日志数据的traceID是相同的。在本说明书中,具有相同traceID的多条原始日志数据也可以称为关联日志。同样地,为了对该场景下的关联日志进行相互区分,可以将服务器标识作为动态列名。如,某条原始日志数据是在调用服务器X所采集到时,可以将该原始日志数据的动态列名确定为服务器X的标识。
步骤406,根据关键信息以及动态列名,对原始日志数据进行格式化处理。
在一种实现方式中,上述格式化处理可以包括为原始日志数据添加用于构造行键rowkey的关键信息以及动态列名。对原始日志数据进行格式化处理之后,可以得到格式化处理后的日志数据。如,格式化处理后的日志数据可以为:<rowkeyInfo><dynamicColName><rawLogData>,其中,rowkeyInfo可以为用于构建rowkey的关键信息;dynamicColName可以为动态列名;rawLogData可以为原始日志数据。
应理解,上述只是一种格式化处理的实现方式。在其它实施方式中,也可以将“<>”替换为“()”或者“{}”等其它特殊字符。或者,也可以将上述关键信息或者动态列名添加到原始日志数据之后等,本说明书对此不作限定。
可以理解的是,当客户端采集到多条原始日志数据时,上述步骤404以及步骤406可以是重复执行的。
步骤408,通过传输媒介向服务器发送日志文件。
在得到上述格式化处理后的日志数据之后,可以将该格式化处理后的日志数据输出到日志文件中。当该日志文件的大小达到阈值大小时,可以将该日志文件通过传输媒介发送至服务器。此处的传输媒介可以是一种可以实时传输数据的介质。
步骤410,从日志文件中读取一行格式化处理后的日志数据。
步骤412,解析格式化处理后的日志数据,以获取关键信息以及动态列名。
具体地,可以根据服务器与客户端预先协商好的解析规则,来对格式化处理后的日志数据进行解析。如,该解析规则可以为:第一个“<>”的内容用于表示上述关键信息,第二个“<>”的内容用于表示上述动态列名,第三个“<>”的内容用于表示原始日志数据等。
应理解,上述解析规则仅为了示例性的目的,并且本说明书决不被限制于这里描述的特殊示例性实施例。
步骤414,根据关键信息,生成rowkey。
如,可以将关键信息作为rowkey。
步骤416,根据rowkey以及动态列名,将原始日志数据写入Hbase数据库的对应位置。
在一种实现方式中,可以基于rowkey、动态列名以及原始日志数据构造put对象。之后,通过执行该put对象的写入操作,来实现原始日志数据的写入。
可以理解的是,当日志文件中包括多行格式化处理后的日志数据时,上述步骤410、步骤412、步骤414以及步骤416可以是重复执行的。
需要说明的是,由于关联日志具有相同的关键信息,如,具有相同的traceID或者业务标识,进而生成的rowkey是相同的。而rowkey为Hbase数据库的一行数据的唯一标识。因此,本说明书的存储方法可以将关联日志存储在Hbase数据库的同一行。此外,由于关联日志可以具有不同的动态列名,从而可以保证其分布在同一行的不同列。
综上,本说明书一个实施例或者多个实施例提供的日志数据的存储方法,可以将关联日志存储在Hbase数据库的同一行,从而业务系统在读取关联日志时,只需读取一次即可,这可以提高日志数据的读取效率。
与上述日志数据的存储方法对应地,本说明书一个实施例还提供的一种日志数据的存储装置,如图5所示,该装置可以包括:
获取单元502,用于获取格式化处理后的日志数据。此处的格式化处理可以包括为原始日志数据添加用于构造行键rowkey的关键信息以及动态列名。
获取单元502具体可以用于:
通过传输媒介接收客户端发送的日志文件。该日志文件中可以包括多行格式化处理后的日志数据。
从日志文件中读取一行格式化处理后的日志数据。
上述关键信息可以包括但不限于业务标识或者跟踪标识traceID。此外,上述动态列名可以是根据线程名或者服务器标识确定的。
解析单元504,用于对获取单元502获取的格式化处理后的日志数据进行解析,以获取关键信息以及动态列名。
生成单元506,用于根据关键信息,生成rowkey。
写入单元508,用于根据生成单元506生成的rowkey以及动态列名,将原始日志数据写入Hbase数据库的对应位置。本说明书上述实施例装置的各功能模块的功能,可以通过上述方法实施例的各步骤来实现,因此,本说明书一个实施例提供的装置的具体工作过程,在此不复赘述。
本说明书一个实施例提供的日志数据的存储装置,获取单元502获取格式化处理后的日志数据。解析单元504对格式化处理后的日志数据进行解析,以获取关键信息以及动态列名。生成单元506根据关键信息,生成rowkey。写入单元508根据rowkey以及动态列名,将原始日志数据写入Hbase数据库的对应位置。由此,可以提高日志数据的读取效率。
本说明书一个实施例提供的日志数据的存储装置可以为图1中服务器的一个模块或者单元。
与上述日志数据的存储方法对应地,本说明书一个实施例还提供的一种日志数据的存储装置,如图6所示,该装置可以包括:
采集单元602,用于采集原始日志数据。
确定单元604,用于确定与采集单元602采集的原始日志数据对应的用于构造行键rowkey的关键信息以及动态列名。
处理单元606,用于根据确定单元604确定的关键信息以及动态列名,对原始日志数据进行格式化处理。
处理单元606具体可以用于:
为原始日志数据添加用于构造行键rowkey的关键信息以及动态列名。
发送单元608,用于向服务器发送处理单元606格式化处理后的日志数据,以使服务器对格式化处理后的日志数据进行解析,获取关键信息以及动态列名,并根据关键信息,生成rowkey。还使服务器根据rowkey以及动态列名,将原始日志数据写入Hbase数据库的对应位置。
可选地,该装置还可以包括:
输出单元610,用于将格式化处理后的日志数据输出到日志文件中。
发送单元608具体可以用于:
通过传输媒介向服务器发送日志文件。
本说明书上述实施例装置的各功能模块的功能,可以通过上述方法实施例的各步骤来实现,因此,本说明书一个实施例提供的装置的具体工作过程,在此不复赘述。
本说明书一个实施例提供的日志数据的读取装置,可以提高日志数据的读取效率。
本说明书一个实施例提供的日志数据的存储装置可以为图1中客户端的一个模块或者单元。
与上述日志数据的存储方法对应地,本说明书实施例还提供了一种服务器,如图7所示,该服务器可以包括:
接收器702,用于获取格式化处理后的日志数据。该格式化处理包括为原始日志数据添加用于构造行键rowkey的关键信息以及动态列名。
至少一个处理器704,用于对格式化处理后的日志数据进行解析,以获取关键信息以及动态列名。根据关键信息,生成rowkey。根据rowkey以及动态列名,将原始日志数据写入Hbase数据库的对应位置。
本说明书一个实施例提供的服务器,可以提高日志数据的读取效率。
与上述日志数据的存储方法对应地,本说明书实施例还提供了一种客户端,如图8所示,该客户端可以包括:
至少一个处理器802,用于采集原始日志数据。确定与原始日志数据对应的用于构造行键rowkey的关键信息以及动态列名。根据关键信息以及动态列名,对原始日志数据进行格式化处理。
发送器804,用于向服务器发送格式化处理后的日志数据,以使服务器对格式化处理后的日志数据进行解析,获取关键信息以及动态列名,并根据关键信息,生成rowkey。还使服务器根据rowkey以及动态列名,将原始日志数据写入Hbase数据库的对应位置。
本说明书一个实施例提供的客户端,可以提高日志数据的读取效率。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于服务器或者客户端实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
结合本说明书公开内容所描述的方法或者算法的步骤可以硬件的方式来实现,也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成,软件模块可以被存放于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外,该ASIC可以位于服务器中。当然,处理器和存储介质也可以作为分立组件存在于服务器中。
本领域技术人员应该可以意识到,在上述一个或多个示例中,本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时,可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质,其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
以上所述的具体实施方式,对本说明书的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本说明书的具体实施方式而已,并不用于限定本说明书的保护范围,凡在本说明书的技术方案的基础之上,所做的任何修改、等同替换、改进等,均应包括在本说明书的保护范围之内。