CN112751726A - 一种数据处理方法、装置、电子设备和存储介质 - Google Patents

Abstract

本公开关于一种数据处理方法、装置、电子设备和存储介质，其中，数据处理方法包括：通过设置的中间件设备可以对存储在消息队列的输入主题中的待分析数据进行类型识别，得到待分析数据的指标类型；其中，消息队列包括多个输入主题，各输入主题中存储有多个待分析数据；根据指标类型确定待分析数据的处理方式和处理对象，其中，处理对象包括目标服务组中的至少一个服务实例，目标服务组为预存服务组中与处理方式相匹配的服务组；利用至少一个服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据。通过上述设置中间件设备的方法可以至少解决服务器因为计算过程延迟导致的数据采样频率出错的问题。

Description

一种数据处理方法、装置、电子设备和存储介质

技术领域

本公开涉及互联网技术领域，尤其涉及一种数据处理方法、装置、电子设备和存储介质。

背景技术

Prometheus是一套开源的系统监控报警框架。作为新一代的云原生监控系统，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型，是当前使用最为广泛的开源指标收集和监控的解决方案。

Prometheus生态系统中包含了多个组件，包括：Prometheus服务器、网关PushGateway和报警管理设备Alert manager。其中，Prometheus服务器定时从push gateway获取指标数据，再根据监控规则计算得出指标结果。一般情况下，Prometheus服务器每隔预设时间就把push gateway上数据都拉去到自身服务器的内存中进行计算和存储，但由于Prometheus服务器为单点服务，当Prometheus面临计算过程有延迟时，这种单点服务会导致数据采样的频率出现错误，影响后续过程。

发明内容

本公开提供一种数据处理方法、装置、电子设备和存储介质，以至少解决相关技术中Prometheus服务器由于计算过程延迟导致的数据采样频率出错的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种数据处理方法，包括：

对存储在消息队列的输入主题中的待分析数据进行类型识别，得到待分析数据的指标类型；其中，消息队列包括多个输入主题，各输入主题中存储有多个待分析数据；

根据指标类型确定待分析数据的处理方式和处理对象，其中，处理对象包括目标服务组中的至少一个服务实例，目标服务组为预存服务组中与处理方式相匹配的服务组；

利用至少一个服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据；

将汇总数据存储至消息队列的输出主题中，用于触发汇总数据收集模块将汇总数据传输至系统做监控报警比对处理；其中，输出主题与输入主题相对应。

可选的，在得到汇总数据之后，方法还包括：

获取当前报警需求信息；当前报警需求信息用于判断汇总数据中数据的有效性；

根据当前报警需求信息确定汇总数据中的无效数据，从汇总数据中删除无效数据，得到处理后的汇总数据；

将汇总数据存储至消息队列的输出主题中包括：

将处理后的汇总数据存储至消息队列的输出主题中。

可选的，根据指标类型确定待分析数据的处理方式和处理对象包括：

获取指标类型处理方式映射表；

从指标类型处理方式映射表确定指标类型对应的处理方式，并将处理方式确定为待分析数据的处理方式；

根据待分析数据的处理方式从预存服务组中确定出目标服务组；目标服务组中的至少一个服务实例为处理对象。

可选的，对存储在消息队列的输入主题中的待分析数据进行类型识别之前，还包括：

从监控数据源处实时获取待分析数据；待分析数据携带有监控数据源的标识信息；

获取数据分配预设规则；数据分配预设规则至少用于记录各输入主题与监控数据源的标识信息的对应关系；

按照对应关系，将待分析数据分配至监控数据源的标识信息对应的输入主题。

可选的，服务组的数量和/或一个服务组中的服务实例的数量是基于消息队列中的输入主题的数量和/或输入主题中待分析数据的数据量动态调整的。

可选的，利用至少一个服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据之前，还包括：

若待分析数据的数据量大于等于第一预设数据量，增加目标服务组中的服务实例个数，得到扩容后的目标服务组；

利用至少一个服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据包括：

利用扩容后的目标服务组内的所有服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据。

可选的，利用至少一个服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据之前，还包括：

若待分析数据的数据量小于等于第二预设数据量，减少目标服务组中的服务实例个数，得到缩容后的目标服务组；

利用至少一个服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据包括：

利用缩容后的目标服务组内的所有服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据；

第二预设数据量小于第一预设数据量。

根据本公开实施例的第二方面，提供一种数据处理装置，包括：

识别单元，被配置为执行对存储在消息队列的输入主题中的待分析数据进行类型识别，得到待分析数据的指标类型；其中，消息队列包括多个输入主题，各输入主题中存储有多个待分析数据；

确定单元，被配置为执行根据指标类型确定待分析数据的处理方式和处理对象，其中，处理对象包括目标服务组中的至少一个服务实例，目标服务组为预存服务组中与处理方式相匹配的服务组；

处理单元，被配置为执行利用至少一个服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据；

输出单元，被配置为执行将汇总数据存储至消息队列的输出主题中，用于触发汇总数据收集模块将汇总数据传输至系统做监控报警比对处理；其中，输出主题与输入主题相对应。

可选的，装置还包括获取单元和过滤单元；

获取单元，被配置为执行获取当前报警需求信息；当前报警需求信息用于判断汇总数据中数据的有效性；

过滤单元，被配置为执行根据当前报警需求信息确定汇总数据中的无效数据，从汇总数据中删除无效数据，得到处理后的汇总数据；

输出单元，被配置为执行将处理后的汇总数据存储至消息队列的输出主题中。

可选的，确定单元，包括：

获取子单元，被配置为执行获取指标类型处理方式映射表；

第一确定子单元，被配置为执行从指标类型处理方式映射表确定指标类型对应的处理方式，并将处理方式确定为待分析数据的处理方式；

第二确定子单元，被配置为执行根据待分析数据的处理方式从预存服务组中确定出目标服务组；目标服务组中的至少一个服务实例为处理对象。

可选的，装置还包括分配单元；

获取单元，被配置为执行从监控数据源处实时获取待分析数据；待分析数据携带有监控数据源的标识信息；获取数据分配预设规则；该数据分配预设规则至少用于记录各输入主题与监控数据源的标识信息的对应关系；

分配单元，被配置为执行按照对应关系，将待分析数据分配至监控数据源的标识信息对应的输入主题。

可选的，服务组的数量和/或一个服务组中的服务实例的数量是基于消息队列中的输入主题的数量和/或输入主题中待分析数据的数据量动态调整的。

可选的，装置还包括容量更改单元；

容量更改单元，被配置为执行若待分析数据的数据量大于等于第一预设数据量，增加目标服务组中的服务实例个数，得到扩容后的目标服务组；

处理单元，被配置为执行利用扩容后的目标服务组内的所有服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据。

可选的，容量更改单元，被配置为执行若待分析数据的数据量小于等于第二预设数据量，减少目标服务组中的服务实例个数，得到缩容后的目标服务组；

处理单元，被配置为执行利用缩容后的目标服务组内的所有服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据；

第二预设数据量小于第一预设数据量。

根据本公开实施例的第三方面，提供一种数据处理方法，包括：

通过网关按照预设的推送频率接收汇总数据收集模块推送的汇总数据；汇总数据是基于确定的处理方式和处理对象对待分析数据进行汇总处理得到，并存储至消息队列的输出主题中的，用于触发汇总数据收集模块从输出主题中获取；其中，确定的处理方式和处理对象是基于待分析数据的指标类型确定的；处理对象包括目标服务组中的至少一个服务实例，目标服务组为预存服务组中与处理方式相匹配的服务组；

通过服务器按照预设的获取频率从网关获取汇总数据；获取频率大于推送频率；

在汇总数据满足报警规则的情况下，通过报警管理设备接收服务器发送的汇总数据对应的报警指令；

在预设时间段内接收到多个汇总数据对应的报警指令的情况下，向警报接收设备发送报警信息。

根据本公开实施例的第四方面，提供一种数据处理装置，包括：

接收单元，被配置为执行通过网关按照预设的推送频率接收汇总数据收集模块推送的汇总数据；汇总数据是基于确定的处理方式和处理对象对待分析数据进行汇总处理得到，并存储至消息队列的输出主题中的，用于触发汇总数据收集模块从输出主题中获取；其中，确定的处理方式和处理对象是基于待分析数据的指标类型确定的；处理对象包括目标服务组中的至少一个服务实例，目标服务组为预存服务组中与处理方式相匹配的服务组；

获取单元，被配置为执行通过服务器按照预设的获取频率从网关获取汇总数据；获取频率大于推送频率；

接收单元，被配置为执行在汇总数据满足报警规则的情况下，通过报警管理设备接收服务器发送的汇总数据对应的报警指令；

发送单元，被配置为执行在预设时间段内接收到多个汇总数据对应的报警指令的情况下，向警报接收设备发送报警信息。

根据本公开实施例的第五方面，提供一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行指令，以实现如上述第一方面或者第三方面中任一项的方法。

根据本公开实施例的第六方面，提供一种存储介质，当存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行本公开实施例的第一方面或者第三方面中任一方法。

根据本公开实施例的第七方面，提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行本公开实施例的第一方面或者第三方面中任一方法。

根据本公开实施例的第八方面，提供一种系统，包括：

网关，用于按照预设的推送频率接收汇总数据收集模块推送的汇总数据；汇总数据是基于确定的处理方式和处理对象对待分析数据进行汇总处理得到，并存储至消息队列的输出主题中的，用于触发汇总数据收集模块从输出主题中获取；其中，确定的处理方式和处理对象是基于待分析数据的指标类型确定的；处理对象包括目标服务组中的至少一个服务实例，目标服务组为预存服务组中与处理方式相匹配的服务组；

服务器，用于按照预设的获取频率从网关获取汇总数据；获取频率大于推送频率；

报警管理设备，用于在汇总数据满足报警规则的情况下，接收服务器发送的汇总数据对应的报警指令；在预设时间段内接收到多个汇总数据对应的报警指令的情况下，向警报接收设备发送报警信息。

本公开的实施例提供的技术方案至少带来以下有益效果：

通过设置的中间件设备可以对存储在消息队列的输入主题中的待分析数据进行类型识别，得到待分析数据的指标类型；其中，消息队列包括多个输入主题，各输入主题中存储有多个待分析数据；根据指标类型确定待分析数据的处理方式和处理对象，其中，处理对象包括目标服务组中的至少一个服务实例，目标服务组为预存服务组中与处理方式相匹配的服务组；利用至少一个服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据。可以至少解决服务器因为计算过程延迟导致的数据采样频率出错的问题，进一步地，还可以解决监控数据指标的准确性下降等问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种Prometheus系统的示意图；

图2是根据一示例性实施例示出的一种应用环境的示意图；

图3是根据一示例性实施例示出的一种数据处理方法的流程图；

图4是根据一示例性实施例示出的一种结构示意图；

图5是根据一示例性实施例示出的一种汇总数据的处理流程示意图；

图6是根据一示例性实施例示出的一种数据处理方法的流程图；

图7是根据一示例性实施例示出的一种数据处理方法的流程图；

图8是根据一示例性实施例示出的一种数据处理装置的框图；

图9是根据一示例性实施例示出的一种数据处理装置的框图；

图10是根据一示例性实施例示出的一种用于数据处理的电子设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

相关技术中，如图1所示，Prometheus是一套开源的系统监控报警框架。作为新一代的云原生监控系统，其对传统监控系统的测试和告警模型进行了彻底的颠覆，形成了基于中央化的规则计算、统一分析和告警的新模型，是当前使用最为广泛的开源指标收集和监控的解决方案。

Prometheus生态系统中包含了多个组件，如图1所示，其中重要的组件包括：Prometheus服务器、网关Push Gateway和报警管理设备Alert manager。其中，Prometheus服务器负责指标数据的分析、计算和存储；Push Gateway可以被认为是推送网关，负责指标数据的收集，服务层面的指标可以直接向Push Gateway推送指标数据，Prometheus服务器定时从Push Gateway拉取最新的指标数据；Alert manager提供告警管理服务，当Prometheus服务器发现指标异常需要告警时，会将告警数据推送给Alert manager，其会进行去除重复数据、分组、并发出报警。常见的接收方式有：电子邮件，pagerduty，OpsGenie，webhook等。

由于Prometheus服务器定时从push gateway获取指标数据，再根据监控规则计算得出指标结果。一般情况下，Prometheus服务器每隔预设时间就把push gateway上数据都拉去到自身服务器的内存中进行计算和存储，也就是每隔预设时间进行数据采样，然而由于Prometheus服务器为单点服务，原生技术框架下无法集群化，这样使得Prometheus单点服务在面临大数据处理的情况下会有计算上的性能瓶颈，同时，如果计算过程有延迟，会影响数据采样的频率，从而进一步影响监控数据指标的准确性，出现恶性循环。为了解决上述出现的问题，本公开提供一种设备框架已经基于该设备框架的技术方法。

请参阅图2，图2根据一示例性实施例示出的一种应用环境的示意图，如图2所示，包括监控数据源01，中间件设备02和Prometheus系统03。其中，Prometheus系统03包括网关Push Gateway031、Prometheus服务器032和报警管理设备Alert manager033。可选的，监控数据源01，中间件设备02和Prometheus系统03可以通过无线链路连接。可选的，监控数据源01，中间件设备02和Prometheus系统03也可以通过有线链链路连接。

在一个可选的实施例中，监控数据源01可以用于向中间件设备02发送待分析数据或者向Prometheus系统03发送待分析数据。具体的，监控数据源01可以是独立的物理设备，也可以是多个物理设备构成的设备集群或者分布式系统。可选的，该监控数据源01上运行的操作系统可以包括但是不限于IOS、Linux、Windows、Unix系统等。

在一个可选的实施例中，中间件设备02可以是在方式实施逻辑上处于监控数据源01和Prometheus系统03之间的设备，用于接收来自监控数据源01的待分析数据，并对待分析数据进行处理，得到汇总数据。

在一个可选的实施例中，Prometheus系统03接收来自中间设备02中包含的汇总数据收集模块发送的汇总数据或者接收来自监控数据源01的待分析数据，并根据汇总数据和报警规则的对比结果，或者待分析数据得到的汇总数据和报警规则的对比结果来确定是否需要报警。

图3是根据一示例性实施例示出的一种数据处理方法的流程图，如图3所示，该数据处理方法用于中间件设备，该中间件设备可以是服务器或者电子设备，包括以下步骤：

在步骤S301中，对存储在消息队列的输入主题中的待分析数据进行类型识别，得到待分析数据的指标类型；其中，消息队列包括多个输入主题，各输入主题中存储有多个待分析数据。

图4是根据一示例性实施例示出的一种结构示意图，如图4所示，该结构示意图包括监控数据源和中间件设备，其中，监控数据源可以是独立的电子设备，服务器(比如应用服务器)，也可以是如图所示的多个电子设备或者服务器构成的集群或者分布式系统。

在一个可选的实施中，监控数据源中每个监控数据源(包括监控数据源1，监控数据源2……监控数据源n)都可以是数据的生产者，也可以是数据的收集者，或者是数据的生产者和收集者的结合。

在一个可选的实施例中，数据包括电子设备的CPU利用率，卡顿数据，响应时间、请求失败次数、内存/磁盘利用率和吞吐量等等。以CPU利用率为例，监控数据源可以实时或者隔段时间输出CPU利用率，并进行记录，以便可以后续推送给中间件设备。监控数据源也可以收集其他电子设备的CPU利用率，后续推送给中间件设备。

本公开实施例中，在对存储在消息队列的输入主题中的待分析数据进行类型识别之前，中间件设备可以从监控数据源处实时获取待分析数据。也就是说，监控数据源处的数据可以作为待分析数据实时或者按照预设的时间间隔由监控数据源发送给中间件设备。中间件设备接收到该待分析数据后，可以存储在中间件设备中的存储区域。

在一种可选的实施方式中，如图4所示，存储区域可以包括消息队列存储模块，输入主题模块和输出主题模块。可选的，该消息队列存储模块，输入主题模块和输出主题模块三者是分离的。可选的，该消息队列存储模块，输入主题模块和输出主题模块三者是集成的，其中，输入主题模块和输出主题模块可以集成在消息队列存储模块中。

可选的，消息队列存储模块可以包括一个消息队列或者多个消息队列，输入主题模块中可以存在不同的输入主题，输出主题模块也可以存在不同的输出主题。不同的待分析数据可以所属于不同的输入主题，便于提供给订阅该输入主题中待分析数据的服务组。

在一个可选的实施方式中，消息队列存储模块中存在一个消息队列，可以接收来自不同监控数据源的待分析数据，不同的待分析数据都按照到达消息队列存储模块的时间顺序排在该消息队列中。每个来自不同监控数据源的待分析数据可以携带有监控数据源的标识信息。一种可选的实施方式中，中间件设备可以从监控数据源处实时获取待分析数据，其中，待分析数据携带有监控数据源的标识信息。当中间件设备获取待分析数据后，可以获取数据分配预设规则，其中，数据分配预设规则至少用于记录各输入主题与监控数据源的标识信息的对应关系。按照该对应关系将待分析数据分配至监控数据源的标识信息对应的输入主题。

举个例子，若存在3个输入主题，比如输入主题1，输入主题2和输入主题3。每个输入主题可以对应着不同的标识信息，比如输入主题1对应着标识信息A和B，表示来自标识信息A和B标识的监控数据源a和b的待分析数据可以分配至输入主题1。输入主题2对应着标识信息C，表示来自标识信息C标识的监控数据源c的待分析数据可以分配至输入主题2。输入主题3对应着标识信息D，表示来自标识信息D标识的监控数据源d的待分析数据可以分配至输入主题3。

可选的，该数据分配预设规则是提前设置在中间设备中的。

为了便于描述，本公开实施例，将中间件设备接收到的每种数据(CPU利用率，卡顿数据，响应时间、请求失败次数、内存/磁盘利用率和吞吐量等)称为待分析数据。来自同一输入主题的不同种类数据也是不同的待分析数据。

可选的，一种待分析数据(比如CPU利用率)可以只被分到一个输入主题(topic 1)中，或者一种待分析数据(比如响应时间)可以被分到多个输入主题(topic 2、topic 4)中，或者多种待分析数据(比如内存/磁盘利用率和吞吐量)可以被分到一个输入主题(topic3)中。

在一个可选的实施例中，当待分析数据被中间件设备分配到各个对应的输入主题后，可以对待分析数据进行类型识别，得到待分析数据的指标类型，该指标类型用于指示输入主题中的待分析数据应该被分配到什么样的计算任务中进行处理，也就是说，该待分析数据应该被贴上什么样的计算标签来进行处理。

在步骤S303中，根据指标类型确定待分析数据的处理方式和处理对象，其中，处理对象包括目标服务组中的至少一个服务实例，目标服务组为预存服务组中与处理方式相匹配的服务组。

在一个可选的实施例中，由于每个服务组所拥有的处理方式是不一样的，也就是说，并不是每个服务组都可以处理所有的计算过程，因此，可以从指标类型确定待分析数据的处理方式，从满足该处理方式的多个预存服务组中确定出处理该待分析数据的目标服务组，处理该待分析数据的目标服务组中的至少一个服务实例为处理对象。

可选的，中间件设备可以获取指标类型处理方式映射表，从指标类型处理方式映射表确定指标类型对应的处理方式，并将处理方式确定为待分析数据的处理方式，根据待分析数据的处理方式从预存服务组中确定出目标服务组；目标服务组中的至少一个服务实例为处理对象。

在一个可选的实施例中，在确定待分析数据的处理方式为第一处理方式后，可以先确定每个预存服务组的处理方式，若所有的预存服务组中只有一个预存服务组(甲)的处理方式为第一处理方式或者包括第一处理方式，则确定该预存服务组(甲)为目标服务组。

在一个可选的实施例中，在确定待分析数据的处理方式为第一处理方式后，可以先确定每个预存服务组的处理方式，若所有的预存服务组中存在两个预存服务组(甲和已)的处理方式为第一处理方式或者包括第一处理方式，则进一步确定这两个预存服务组(甲和已)当前的数据处理状态，若预存服务器(甲)正在处理数据，预存服务器(乙)空闲，则将预存服务器(乙)确定为目标服务器组。可选的，若两个预存服务组(甲和已)当前都在处理数据，则预估两个预存服务器还需完成数据处理的时间值，将还需数据处理的时间值较短的预存服务组作为目标服务器组。

其中，上述的预存服务组中每个服务组可以被称为消费者组，消费者组是一种可扩展且具有容错性的消费者机制，在组内可以具有多个服务实例(也可以被称为消费者实例)，多个服务实例共享一个公共的身份标识，该身份标识可以被称为Group ID。消费者组内的所有服务实例协调在一起消费订阅的输入主题(Subscribed Topics)的所有分区，当然一个分区只能有同一个消费者组的一个服务实例消费。服务实例是用来对待分析数据进行处理的设备，比如，包括但不限于是服务器，终端设备等等。

在另一个可选的实施例中，还可以从指标类型确定出处理周期，比如是按照一天的待分析数据的数据量进行处理(一天处理一次)，还是按照一周的待分析数据的数据量进行处理(一周处理一次)，若确定计算周期后，则确定待分析数据的处理方式，从满足该处理方式的多个预存服务组中确定出处理该待分析数据的目标服务组，给该目标服务组发送获取指令，以使该目标服务组在预设的时间点获取累积一天或者累积一周的待分析数据。

在一个可选的实施例中，处理方式包括计算方法和从输入主题内收集到的待分析数据的分解方法，计算方法可以包括但不限于求平均值，计数，求和，求最大值或者最小值等等。分解方法是指基于获取的待分析数据的数据量将其分成几个计算部分，以使得目标服务组中的服务实例能够更好的处理。

可选的，为了避免计算资源的浪费，每个输入主题中的待分析数据可以由一个目标服务组内的服务实例进行计算处理。其中，服务组的数量和/或一个服务组中的服务实例的数量是基于消息队列中的输入主题的数量和/或输入主题中待分析数据的数据量动态调整的。本公开实施例中，扩容可以表示增加数据处理的服务组的数量，以及增加一个或者多个服务组中服务实例的数量。缩容可以表示减少数据处理的服务组的数量，以及减少一个或者多个服务组中服务实例的数量。

在一个可选的实施例中，若待分析数据的数据量大于等于第一预设数据量，增加处理对象所在目标服务组中的服务实例个数，得到扩容后的目标服务组；并利用扩容后的目标服务组内的所有服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据。举个例子，假设该目标服务组中存在N个服务实例，假设待分析数据的数据量大于等于第一预设数据量，将该目标服务组内的服务实例增加至M个，M大于N，得到扩容后的目标服务组，并利用M个服务实例对待分析数据进行汇总处理，其中，增加的服务实例的个数是根据原有的服务实例的个数以及第一待分析数量的实际数据量确定的。

在另一个可选的实施例中，若待分析数据的数据量小于等于第二预设数据量，减少处理对象所在目标服务组中的服务实例个数，得到缩容后的目标服务组；并利用缩容后的目标服务组内的所有服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据；第二预设数据量小于第一预设数据量。举个例子，假设该目标服务组中存在N个服务实例，假设待分析数据的数据量小于等于第二预设数据量，将该目标服务组内的服务实例减少至L个，L小于N，得到缩容后的目标服务组，并利用L个服务实例对待分析数据进行处理，其中，减少的服务实例的个数是根据原有的服务实例的个数以及第一待分析数量的实际数据量确定的。

在一个可选的实施例中，若输入主题的数量大于等于第一阈值，增加预存服务组的个数。若输入主题的数量小于等于第二阈值，减少预存服务组的个数，其中，第一阈值大于第二阈值。随着来自监控数据源的数据量的增大，以及各个待分析数据的多场景应用，可能存在一种待分析数据需要分配到不同的输入主题中，单独或者结合其他的待分析数据进行不同的汇总运算，基于此种考虑，则需要增加输入主题的数量，然而随着输入主题数量的增加，为此服务的服务组的工作量可能存在超负荷情况，因此，可以基于输入主题的数量动态增减预存服务组的个数，使得预存服务组可以依按照时间顺序处理不同输入主题中的待分析数据，而不是同时进行数据处理。

上文中的确定输入主题中的待分析数据的处理对象、处理方法(计算方法和分解方法)和处理周期都是中间件设备对待分析数据进行处理前的任务确定步骤，为后续的任务汇总处理步骤做准备。

在步骤S305中，利用至少一个服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据。

一种可选的实施例中，可以获取输入主题中的待分析数据，并对其进行聚合处理，该聚合处理是指按照确定的计算方法对待分析数据进行求平均值，计数，求和，求最大值或者最小值中的一种或者多种处理，得到汇总数据。

另一种可选的实施例中，可以定期从输入主题中获取待分析数据，将多次获取的待分析数据先进行汇总处理，删除掉一些明显不符合数据规则的待分析数据，随后，并对其进行聚合处理，该聚合处理是指按照确定的计算方法对待分析数据进行求平均值，计数，求和，求最大值或者最小值中的一种或者多种处理，得到汇总数据。

在步骤S307中，将汇总数据存储至消息队列的输出主题中，用于触发汇总数据收集模块将汇总数据传输至系统做监控报警比对处理；其中，输出主题与输入主题相对应。

本公开实施例中，由于可能存在得到的汇总数据在当前时段内并不是后期Prometheus系统关注的数据，因此可以在得到汇总数据之后对其进行删选处理，请参考图5，图5是根据一示例性实施例示出的一种汇总数据的处理流程示意图，如图5所示，包括：

在步骤S501中，获取当前报警需求信息；当前报警需求信息用于判断汇总数据中数据的有效性。

可选的，当前报警需求信息是用来指示哪些汇总数据是当前有效的，哪些汇总数据是当前无效的。当前报警需求信息可以是预先设置在中间件设备中的，也可以是根据从Prometheus系统获取的报警规则动态生成的。

在步骤S502中，根据当前报警需求信息确定汇总数据中的无效数据，从汇总数据中删除无效数据，得到处理后的汇总数据。

本公开实施例中，可以确定当前报警需求信息中包含的目标输入主题标识，并确定汇总数据携带的输入主题标识，若该汇总数据携带的输入主题标识不属于目标输入主题标识，则确定汇总数据是无效的。

在一个可选的实施例中，由于每个输入主题中都只包含同一种待分析数据进行相同的数据处理，该种情况下，该输入主题内所有的待分析数据的指标类型是一致的。因此，当待分析数据进入目标服务组进行处理的前后，都会携带有该输入主题的标识。换句话说，得到的汇总数据携带有该输入主题的标识，假设该输入主题的标识为TA。若获取的当前报警需求信息中包括的输入主题的标识为TB，TC和TD，则表明只有携带有TB，TC和TD标识的汇总数据是有效的，那么携带有TA标识的汇总数据当前是无效的，可以被过滤掉。

本公开实施例中，可以确定当前报警需求信息中包含的目标输入主题标识以及每个目标输入主题标识对应的目标指标类型，并确定汇总数据携带的输入主题标识以及汇总数据的指标类型。只有在该汇总数据携带的输入主题标识为目标输入主题标识，以及指标类型也和该目标输入主题标识对应的目标指标类型一样，才能确定汇总数据是有效的，否则就判定无效。

在一个可选的实施例中，由于部分输入主题可能包含多种待分析数据，且每种待分析数据的指标类型是不同的，因此，可以在每种待分析数据进入目标服务组进行数据处理的前后，都携带有输入主题标识和自己的指标类型。如此，当获取当前报警需求信息后，可以将从当前报警需求信息中得到目标输入主题标识以及每个目标输入主题标识对应的目标指标类型和汇总数据的输入主题标识和自己的指标类型作对比，以确定该汇总数据是否有效。

在步骤S503中，将处理后的汇总数据存储至消息队列的输出主题中。

在一个可选的实施例中，汇总数据收集模块可以集成在中间件设备中，以使中间件设备将汇总数据存储至输出主题中，就可以由输出主题推送至消息队列，再由消息队列推送至汇总数据收集模块。或者，在输出主题模块也集成在消息队列存储模块上时，一旦汇总数据存储至消息队列的输出主题上，就可以推送至汇总数据收集模块。不同的汇总数据可以所属于不同的输出主题，便于提供给订阅该输出主题中汇总数据的汇总数据收集模块，该输入主题和对应的输出主题可以基于发布订阅机制构建的。可以将输出主题内的汇总数据发送给订阅该数据的任一下级应用。

图6是根据一示例性实施例示出的一种数据处理方法的流程图，如图3所示，数据处理方法用于Prometheus系统，该Prometheus系统包括网关，Prometheus服务器和报警管理设备，该方法包括：

在步骤S309中，通过网关按照预设的推送频率接收汇总数据收集模块推送的汇总数据；汇总数据是基于确定的处理方式和处理对象对待分析数据进行汇总处理得到，并存储至消息队列的输出主题中的，用于触发汇总数据收集模块从输出主题中获取；其中，确定的处理方式和处理对象是基于待分析数据的指标类型确定的；处理对象包括目标服务组中的至少一个服务实例，目标服务组为预存服务组中与处理方式相匹配的服务组。

在步骤S311中，通过服务器按照预设的获取频率从网关获取汇总数据；获取频率大于推送频率。

本公开实施例中，由于网关push gateway主要是用来存储短期存在的数据，可能每隔几秒旧的数据就被新接收到的数据覆盖掉了，因此，每当服务器来push gateway拉取数据时，得到的数据是不完整的。而中间件设备的消息队列，或者说和消息队列集成在一起的输出主题的数据传输方式是：一有数据到达，就会被推送走，因此，必须要有一个设于网关push gateway和消息队列两者中间的一个数据收集池，也就是本公开实施例中的汇总数据收集模块来解决这个问题。

在一个可选的实施例中，由于Prometheus服务器按从网关获取汇总数据的频率是默认的，假设每15秒获取一次，那么为了保证存储在push gateway的汇总数据不被覆盖掉，则汇总数据收集模块可以加长数据发送时间，比如每20秒向push gateway发送汇总数据，也就是上文的获取频率(15秒每次，一分钟4次)大于推送频率(20秒每次，一分钟3次)。这种情况下，就可以避免出现相关实施例中，由于没有汇总数据收集模块或者没有中间件设备导致的汇总数据或者原始数据没有被Prometheus服务器收集到的情况，也就不会影响后续的警报规则比对以及警报的准确性。

在步骤S313中，在汇总数据满足报警规则的情况下，通过报警管理设备接收服务器发送的汇总数据对应的报警指令。

举个例子，假设汇总数据是针对CPU利用率的，若汇总数据表示的CPU利用率是95％，报警规则为超过80％，发送报警指令。则Prometheus系统会通过Prometheus服务器向汇总数据对应的报警指令。

在步骤S315中，在预设时间段内接收到多个汇总数据对应的报警指令的情况下，向警报接收设备发送报警信息。

可选的，警报接收设备可以是终端，服务器等设备，可以以发送电子邮件，pagerduty，OpsGenie，webhook等方式传输报警信息。

在一个可选的实施方式中，假设预设时间段为2分钟，则在这2分钟内，接收到5个汇总数据对应的报警指令，就可以向警报接收设备发送报警信息。

在另一个可选的实施例中，假设预设时间段为2分钟，则在这2分钟内，在连续不断的接收到5个汇总数据对应的报警指令，就可以向警报接收设备发送报警信息。

相对于一些相关的技术方案，上文介绍的是通过中间件设备对得到的数据进行汇总处理，得到汇总数据，再将汇总数据输入Prometheus系统进行报警规则比对，该实施方法具有如下的有意效果：

(1)因为上文的数据可以是流数据，也称为数据流，而本公开实施例正是利用流式计算高实时、低延迟的特点，对于数据，进行定时聚合计算处理后在将结果一次性发布到推送网关push gateway，将Prometheus服务从高平网络请求和海量计算量压力下解救出来，实现高性能的指标处理过程，也就是说，Prometheus系统只需要进行报警规则的结果比对，和一些简单的计算，就可以应用到监控规则模板中，减少Prometheus的计算压力。

(2)计算任务通过中间件设备直接根据监控规则直接计算监控结果，不依赖采样结果，结果直接且准确，监控响应更为及时和高效。

(3)利用消息队列的数据时间驱动，计算任务多实例执行，由于消息队列(如kafka)本身提供数据持久化，因此消息队列与流式计算组合即提供了滚动部署和滚动升级以及重新计算的能力.

(4)由于消息队列服务组再平衡的机制，本方案可以支持计算任务的在线动态调整与并行度，易于扩展和按需伸缩，提供灵活的部署方案，可以抵抗大规模数据突发的冲击。

在一个可选的实施例中，监控数据源还可以按照预设的推送规则确定将数据推送给中间件设备还是Prometheus系统，举个例子，如果是比较少量的数据对该数据的敏感度没有很高的要求，可以直接推送到Prometheus系统，让其计算，请参考图7，图7是根据一示例性实施例示出的一种数据处理方法的流程图，如图7所示，包括：

在步骤S701中，通过网关从监控数据源处获取待分析数据；

在步骤S703中，通过Prometheus服务器按照获取频率从网关获取当前的待分析数据；

在步骤S703中，根据待分析数据的指标类型确定待分析数据的处理方式；

在步骤S704中，根据处理方式对待分析数据进行汇总处理，得到汇总数据；

在步骤S705中，在汇总数据满足报警规则的情况下，通过报警管理设备接收Prometheus服务器发送的汇总数据对应的报警指令；

在步骤S706中，在预设时间段内接收到多个汇总数据对应的报警指令的情况下，向警报接收设备发送报警信息。

因此，在对待数据有不同的需求时，可以仅仅使用第一种方法(即通过中间件设备计算)，或者仅仅通过第二种方法(Prometheus服务器自己计算)，或者结合两种方式针对不同数据进行不同方式处理，处理方式请参考上文中的描述，这里不再赘述。

图8是根据一示例性实施例示出的一种数据处理装置框图。参照图8，该装置包括识别单元801，确定单元802、处理单元803、输出单元804。

识别单元801被配置为执行对存储在消息队列的输入主题中的待分析数据进行类型识别，得到待分析数据的指标类型；其中，消息队列包括多个输入主题，各输入主题中存储有多个待分析数据；

确定单元802被配置为执行根据指标类型确定待分析数据的处理方式和处理对象，其中，处理对象包括目标服务组中的至少一个服务实例，目标服务组为预存服务组中与处理方式相匹配的服务组；

处理单元803被配置为执行利用至少一个服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据；

输出单元804被配置为执行将汇总数据存储至消息队列的输出主题中，用于触发汇总数据收集模块将汇总数据传输至系统做监控报警比对处理；其中，输出主题与输入主题相对应。

可选的，装置还包括获取单元和过滤单元；

获取单元，被配置为执行获取当前报警需求信息；当前报警需求信息用于判断汇总数据中数据的有效性；

过滤单元，被配置为执行根据当前报警需求信息确定汇总数据中的无效数据，从汇总数据中删除无效数据，得到处理后的汇总数据；

输出单元，被配置为执行将处理后的汇总数据存储至消息队列的输出主题中。

可选的，确定单元，包括：

获取子单元，被配置为执行获取指标类型处理方式映射表；

第一确定子单元，被配置为执行从指标类型处理方式映射表确定指标类型对应的处理方式，并将处理方式确定为待分析数据的处理方式；

第二确定子单元，被配置为执行根据待分析数据的处理方式从预存服务组中确定出目标服务组；目标服务组中的至少一个服务实例为处理对象。

可选的，装置还包括分配单元；

获取单元，被配置为执行从监控数据源处实时获取待分析数据；待分析数据携带有监控数据源的标识信息；获取数据分配预设规则；数据分配预设规则至少用于记录各输入主题与监控数据源的标识信息的对应关系；

分配单元，被配置为执行按照数对应关系，将待分析数据分配至监控数据源的标识信息对应的输入主题。

可选的，服务组的数量和/或一个服务组中的服务实例的数量是基于消息队列中的输入主题的数量和/或输入主题中待分析数据的数据量动态调整的。

可选的，装置还包括容量更改单元；

容量更改单元，被配置为执行若待分析数据的数据量大于等于第一预设数据量，增加目标服务组中的服务实例个数，得到扩容后的目标服务组；

处理单元，被配置为执行利用扩容后的目标服务组内的所有服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据。

可选的，容量更改单元，被配置为执行若待分析数据的数据量小于等于第二预设数据量，减少目标服务组中的服务实例个数，得到缩容后的目标服务组；

处理单元，被配置为执行利用缩容后的目标服务组内的所有服务实例按照处理方式对待分析数据进行汇总处理，得到汇总数据；

第二预设数据量小于第一预设数据量。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图9是根据一示例性实施例示出的一种数据处理装置框图。参照图9，该装置包括接收单元901，获取单元902、发送单元903。

接收单元901被配置为执行通过网关按照预设的推送频率接收汇总数据收集模块推送的汇总数据；汇总数据是基于确定的处理方式和处理对象对待分析数据进行汇总处理得到，并存储至消息队列的输出主题中的，用于触发汇总数据收集模块从输出主题中获取；其中，确定的处理方式和处理对象是基于待分析数据的指标类型确定的；处理对象包括目标服务组中的至少一个服务实例，目标服务组为预存服务组中与处理方式相匹配的服务组；

获取单元902被配置为执行通过服务器按照预设的获取频率从网关获取汇总数据；获取频率大于推送频率；

接收单元901被配置为执行在汇总数据满足报警规则的情况下，通过报警管理设备接收服务器发送的汇总数据对应的报警指令；

发送单元903被配置为执行在预设时间段内接收到多个汇总数据对应的报警指令的情况下，向警报接收设备发送报警信息。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图10是根据一示例性实施例示出的一种用于数据处理的电子设备1000的框图，适用于中间件设备或者Prometheus系统。

该电子设备可以是服务器，还可以是具有服务器同样功能的其他设备，其内部结构图可以如图10所示。该电子设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种数据处理方法。

本领域技术人员可以理解，图10中示出的结构，仅仅是与本公开方案相关的部分结构的框图，并不构成对本公开方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在示例性实施例中，还提供了一种电子设备，包括：处理器；用于存储该处理器可执行指令的存储器；其中，该处理器被配置为执行该指令，以实现如本公开实施例中的数据处理方法。

在示例性实施例中，还提供了一种存储介质，当该存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行本公开实施例中的数据处理方法。

在示例性实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行本公开实施例中的数据处理方法。

在示例性实施例中，还提供一种系统，包括：

网关，用于按照预设的推送频率接收汇总数据收集模块推送的第一汇总数据；第一汇总数据是基于确定的处理对象和处理方式对第一待分析数据进行汇总和聚合处理得到，并存储至消息队列的输出主题中的，以使汇总数据收集模块从输出主题中获取；其中，确定的处理对象和处理方式是基于第一待分析数据的指标类型确定的；所诉处理对象包括同属一个服务组中的至少一个服务实例；

Prometheus服务器，用于按照预设的获取频率从网关获取第一汇总数据；获取频率大于推送频率；

报警管理设备，用于在第一汇总数据满足报警规则的情况下，接收Prometheus服务器发送的第一汇总数据对应的报警指令；在预设时间段内接收到多个第一汇总数据对应的报警指令的情况下，向警报接收设备发送报警信息。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种数据处理方法，其特征在于，包括：

对存储在消息队列的输入主题中的待分析数据进行类型识别，得到所述待分析数据的指标类型；其中，所述消息队列包括多个输入主题，各所述输入主题中存储有多个待分析数据；

根据所述指标类型确定所述待分析数据的处理方式和处理对象，其中，所述处理对象包括目标服务组中的至少一个服务实例，所述目标服务组为预存服务组中与所述处理方式相匹配的服务组；

利用至少一个所述服务实例按照所述处理方式对所述待分析数据进行汇总处理，得到汇总数据；

将所述汇总数据存储至所述消息队列的输出主题中，用于触发汇总数据收集模块将所述汇总数据传输至系统做监控报警比对处理；其中，所述输出主题与所述输入主题相对应。

2.根据权利要求1所述的数据处理方法，其特征在于，在得到汇总数据之后，所述方法还包括：

获取当前报警需求信息；所述当前报警需求信息用于判断所述汇总数据中数据的有效性；

根据所述当前报警需求信息确定所述汇总数据中的无效数据，从所述汇总数据中删除所述无效数据，得到处理后的汇总数据；

所述将所述汇总数据存储至所述消息队列的输出主题中包括：

将所述处理后的汇总数据存储至所述消息队列的输出主题中。

3.根据权利要求1所述的数据处理方法，其特征在于，所述根据所述指标类型确定所述待分析数据的处理方式和处理对象包括：

获取指标类型处理方式映射表；

从所述指标类型处理方式映射表确定所述指标类型对应的处理方式，并将所述处理方式确定为所述待分析数据的处理方式；

根据所述待分析数据的处理方式从所述预存服务组中确定出所述目标服务组；所述目标服务组中的至少一个服务实例为所述处理对象。

4.根据权利要求1所述的数据处理方法，其特征在于，所述对存储在消息队列的输入主题中的待分析数据进行类型识别之前，还包括：

从监控数据源处实时获取待分析数据；所述待分析数据携带有所述监控数据源的标识信息；

获取数据分配预设规则；所述数据分配预设规则至少用于记录各输入主题与所述监控数据源的标识信息的对应关系；

按照所述对应关系，将所述待分析数据分配至所述监控数据源的标识信息对应的输入主题。

5.根据权利要求1-4任一所述的数据处理方法，其特征在于，所述服务组的数量和/或一个服务组中的服务实例的数量是基于所述消息队列中的输入主题的数量和/或所述输入主题中待分析数据的数据量动态调整的。

6.一种数据处理方法，其特征在于，包括：

通过网关按照预设的推送频率接收汇总数据收集模块推送的汇总数据；所述汇总数据是基于确定的处理方式和处理对象对待分析数据进行汇总处理得到，并存储至消息队列的输出主题中的，用于触发所述汇总数据收集模块从所述输出主题中获取；其中，所述确定的处理方式和处理对象是基于所述待分析数据的指标类型确定的；所述处理对象包括目标服务组中的至少一个服务实例，所述目标服务组为预存服务组中与所述处理方式相匹配的服务组；

通过服务器按照预设的获取频率从所述网关获取汇总数据；所述获取频率大于所述推送频率；

在所述汇总数据满足报警规则的情况下，通过报警管理设备接收所述服务器发送的所述汇总数据对应的报警指令；

在预设时间段内接收到多个所述汇总数据对应的报警指令的情况下，向警报接收设备发送报警信息。

7.一种数据处理装置，其特征在于，包括：

识别单元，被配置为执行对存储在消息队列的输入主题中的待分析数据进行类型识别，得到所述待分析数据的指标类型；其中，所述消息队列包括多个输入主题，各所述输入主题中存储有多个待分析数据；

确定单元，被配置为执行根据所述指标类型确定所述待分析数据的处理方式和处理对象，其中，所述处理对象包括目标服务组中的至少一个服务实例，所述目标服务组为预存服务组中与所述处理方式相匹配的服务组；

处理单元，被配置为执行利用至少一个所述服务实例按照所述处理方式对所述待分析数据进行汇总处理，得到汇总数据；

输出单元，被配置为执行将所述汇总数据存储至所述消息队列的输出主题中，用于触发汇总数据收集模块将所述汇总数据传输至系统做监控报警比对处理；其中，所述输出主题与所述输入主题相对应。

8.一种数据处理装置，其特征在于，包括：

接收单元，被配置为执行通过网关按照预设的推送频率接收汇总数据收集模块推送的汇总数据；所述汇总数据是基于确定的处理方式和处理对象对待分析数据进行汇总处理得到，并存储至消息队列的输出主题中的，用于触发所述汇总数据收集模块从所述输出主题中获取；其中，所述确定的处理方式和处理对象是基于所述待分析数据的指标类型确定的；所述处理对象包括目标服务组中的至少一个服务实例，所述目标服务组为预存服务组中与所述处理方式相匹配的服务组；

获取单元，被配置为执行通过服务器按照预设的获取频率从所述网关获取汇总数据；所述获取频率大于所述推送频率；

所述接收单元，被配置为执行在所述汇总数据满足报警规则的情况下，通过报警管理设备接收所述服务器发送的所述汇总数据对应的报警指令；

发送单元，被配置为执行在预设时间段内接收到多个所述汇总数据对应的报警指令的情况下，向警报接收设备发送报警信息。

9.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1-5或者6中任一项所述的数据处理方法。

10.一种存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1-5或者6中任一项所述的数据处理方法。

Images