CN113225228B - 数据处理方法及装置 - Google Patents

Abstract

本公开公开了一种数据处理方法及装置，涉及计算机技术中的人工智能领域，可应用于云计算或云服务场景。具体实现方案为：接收设备集群中各第二设备分别发送的至少一个接口各自对应的统计信息，统计信息中包括接口的标识、接口对应的至少一个监测时刻、接口在每个监测时刻接收到的请求消息的数量。根据至少一个接口各自对应的统计信息，确定设备集群的QPS信息。通过接收集群中的各个第二设备各自发送的各个接口的统计信息，从而可以根据各接口的各自对应的统计信息，以有效确定集群的QPS信息，同时因为各个接口各自对应的统计信息，是各个第二设备根据接收到请求消息的时刻实时更新的，从而可以准确有效的实现对线上集群的QPS的监控。

Description

数据处理方法及装置

技术领域

本公开涉及计算机技术中的人工智能领域，尤其涉及一种数据处理方法及装置。

背景技术

分布式架构是当今信息系统的主流架构，基于分布式架构可以提供分布式服务，分布式服务对外提供服务的单位是接口。

其中，每秒请求数(Query Per Second，QPS)是接口的重要性能指标，可以体现接口的瞬时并发流量大小，广泛应用于日常监控，容量评估，压测等众多场景。相关技术中在对QPS进行监测时，通常是采用一段时间内的页面浏览量(page view，pv)除以这段时间的秒数，采用这个结果粗略的估算QPS。

然而，上述介绍的确定QPS的方式仅能够实现对QPS的粗略估计，从而导致确定的QPS的准确性较低。

发明内容

本公开提供了一种数据处理方法及装置。

根据本公开的第一方面，提供了一种数据处理方法，所述方法包括：

接收设备集群中各所述第二设备分别发送的至少一个所述接口各自对应的统计信息，所述统计信息中包括所述接口的标识、所述接口对应的至少一个监测时刻、所述接口在每个监测时刻接收到的请求消息的数量；所述设备集群中包括至少一个第二设备，所述第二设备用于通过至少一个接口提供服务；

根据至少一个所述接口各自对应的统计信息，确定所述设备集群的QPS信息。

根据本公开的第二方面，提供了一种数据处理方法，所述方法包括：

确定至少一个请求消息中每个请求消息对应的接口和接收时刻，所述至少一个请求消息为在预设时段内通过各所述接口接收到的，所述预设时段包括n个监测时刻，所述n为大于等于1的整数；

根据每个所述请求消息对应的接口和接收时刻，确定至少一个所述接口各自对应的统计信息，所述统计信息中包括所述接口的标识、所述接口对应的至少一个监测时刻、所述接口在每个监测时刻接收到的请求消息的数量；

向第一设备发送各所述统计信息，所述统计信息用于所述第一设备确定所述设备集群的QPS信息。

根据本公开的第三方面，提供了一种数据处理装置，所述装置包括：

接收模块，用于接收设备集群中各所述第二设备分别发送的至少一个所述接口各自对应的统计信息，所述统计信息中包括所述接口的标识、所述接口对应的至少一个监测时刻、所述接口在每个监测时刻接收到的请求消息的数量；所述设备集群中包括至少一个第二设备，所述第二设备用于通过至少一个接口提供服务；

确定模块，用于根据至少一个所述接口各自对应的统计信息，确定所述设备集群的QPS信息。

根据本公开的第四方面，提供了一种数据处理装置，所述装置包括：

请求消息确定模块，用于确定至少一个请求消息中每个请求消息对应的接口和接收时刻，所述至少一个请求消息为在预设时段内通过各所述接口接收到的，所述预设时段包括n个监测时刻，所述n为大于等于1的整数；

统计信息确定模块，用于根据每个所述请求消息对应的接口和接收时刻，确定至少一个所述接口各自对应的统计信息，所述统计信息中包括所述接口的标识、所述接口对应的至少一个监测时刻、所述接口在每个监测时刻接收到的请求消息的数量；

发送单元，用于向第一设备发送各所述统计信息，所述统计信息用于所述第一设备确定所述设备集群的QPS信息。

根据本公开的第五方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面或第二方面所述的方法。

根据本公开的第六方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行第一方面或第二方面所述的方法。

根据本公开的第七方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序，所述计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得电子设备执行第一方面或第二方面所述的方法。

根据本公开的技术，可以准确有效的实现对线上集群的QPS的监控。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1为本公开实施例提供的数据处理方法的系统示意图；

图2为本公开实施例提供的数据处理方法的流程图；

图3为本公开实施例提供的数据处理方法的流程图二；

图4为本公开实施例提供的统计数组的实现示意图；

图5为本公开实施例提供的确定第一目标统计信息的实现示意图；

图6为本公开实施例提供的对第一目标统计信息分组的实现示意图；

图7为本公开实施例提供的确定一组对应的总请求记录数组的实现示意图；

图8为本公开实施例提供的确定峰值QPS的实现示意图；

图9为本公开实施例提供的峰值QPS曲线的实现示意图；

图10为本公开实施例提供的数据处理方法的流程图三；

图11为本公开实施例提供的数据处理方法的流程图四；

图12为本公开实施例提供的确定第二目标统计信息的实现示意图；

图13为本公开实施例提供的更新统计数组中的目标元素的实现示意图；

图14为本公开实施例提供的数据处理方法的处理示意图；

图15为本公开实施例提供的确定峰值QPS曲线的流程示意图；

图16为本公开实施例的数据处理装置的结构示意图一；

图17为本公开实施例的数据处理装置的结构示意图二；

图18是用来实现本公开实施例的数据处理方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

为了更好的理解本公开的技术方案，下面对本公开所涉及的相关技术进行进一步的介绍。

分布式架构是当今信息系统的主流架构，分布式服务对外提供服务的单位是接口。QPS是接口的重要性能指标，含义是一个接口每秒钟发生的请求的次数，可以体现接口的瞬时并发流量大小，广泛应用于日常监控，容量评估，压测等众多场景。

目前，相关技术在对QPS进行检测时，存在如下几种可能的实现方式：

一种可能的实现方式是，使用一段时间内的页面浏览量除以这段时间的秒数，采用这个结果粗略的估算QPS。然而，这样粗略估计的QPS的准确性较低。

另一种可能的实现方式是，使用jmeter等压测工具，在测试阶段记录QPS。然而，这样的实现方式仅限于压测阶段，不能用于线上服务

另一种可能的实现方式是，通过shell脚本，遍历机器请求日志，计算单机QPS。然而，这样的实现方式仅能计算单机的QPS，无法确定集群的QPS。

另一种可能的实现方式是，在网关层面统计QPS。然而，这样的实现方式必须使用支持QPS功能的特定网关产品，且无法监测不经过网关的内部服务间调用

因此，目前相关技术中在进行QPS的监测时，存在准确性不高的问题，并且目前针对分布式系统缺少易用的线上集群QPS的监控方案，从而会影响分布式系统的运维和问题排查。

针对现有技术中的问题，本公开提出了如下技术构思：通过集群中的各个第二设备实时的监测各自的接口所接收到的请求，并根据请求的接收时刻对各个接口所对应的QPS进行实时更新，之后第二设备将各自对应的接口的QPS上报至第一设备，以使得第一设备根据各个第二设备各自的接口的QPS，监测集群的QPS信息，从而可以准确有效的实现对线上集群QPS的监控。

在上述内容的基础上，下面结合具体的实施例对本公开提供的数据处理方法进行介绍，首先结合图1对本公开的数据处理方法所应用的系统进行介绍，图1为本公开实施例提供的数据处理方法的系统示意图。

如图1所示，本公开实施例提供的数据处理方法可以应用于分布式系统架构的分布式系统，其中一个分布式系统可以包括若干个分布式服务，参见图1，在分布式系统中例如可以包括分布式服务1、分布式服务2等等，比如说针对一个电商系统，可以包括分布式的订单服务、分布式的搜索服务等等。

同时，一个分布式服务由若干个实例组成，实例是运行程序的基本单元，在一种可能的实现方式中，实例可以理解为集群服务器中的服务器，也就是说一个分布式服务可以由若干个服务器组成，本公开中的第二设备可以为集群服务器中的服务器，例如针对图1中的分布式服务1，可以由图1中的第二设备101、第二设备102、第二设备103、第二设备104等等组成，用于为分布式服务1提供具体的服务。

以及，接口是分布式服务层面交互的单元，就是说一个接口由若干个实例提供服务。

例如参见图1，假设当前针对分布式服务1有接口1A、接口1B，，其中，接口1A可以由第二设备101、第二设备102、第二设备103、第二设备104提供服务，同样的，接口1B可以由第二设备101、第二设备102、第二设备103、第二设备104提供服务。

其中，提供服务的具体含义是，假设当前有针对接口1A的请求，可以由第二设备101、第二设备102、第二设备103、第二设备104中的任一个第二设备处理该请求。

分布式服务2中的接口、第二设备的实现方式类似。基于当前介绍可以确定的是，本实施例中的第二设备可以针对各自对应的分布式服务的至少一个接口提供服务，其中各个分布式服务的具体实现，以及各个第二设备所具体提供服务的接口数量、类型等均可以根据实际需求进行选择，本实施例对此不做限制。

本实施例中需要确定分布式系统中的接口的QPS，则各个第二设备可以实时的采集各自对应的接口的QPS数据，之后各第二设备将采集的接口QPS数据上传至第一设备，在第一设备将所有上传上来的QPS数据进行分析，从而汇聚成分布式服务级别的接口QPS数据，以有效的实现线上集群QPS的监控。

在上述图1介绍内容的基础上，下面结合具体的对本公开提供的数据处理方法进行详细介绍，基于上述可以确定的是，本公开提供的数据处理方法在第一设备侧和第二设备侧分别存在一部分操作，其中，在第一设备侧可以根据各个第二设备发送的数据确定集群的QPS信息，以及在第二设备侧，可以由第二设备采集各接口的请求数量，下面对第一设备侧的操作和第二设备侧的操作分别进行介绍。

本公开提供的数据处理方法可以用于与云计算或者云服务场景。

首先结合图2对第一设备侧的操作进行介绍，本实施例中的第一设备用于确定设备集群的QPS信息，在设备集群中可以包括至少一个第二设备，第二设备用于通过至少一个接口提供服务，更为具体的实现可以参照上述实施例的介绍，此处不再赘述。

图2为本公开实施例提供的数据处理方法的流程图，如图2所示，该方法包括：

S201、接收设备集群中各第二设备分别发送的至少一个接口各自对应的统计信息，统计信息中包括接口的标识、接口对应的至少一个监测时刻、接口在每个监测时刻接收到的请求消息的数量。

在本实施例中，第一设备可以接收设备集群中的各个第二设备发送的至少一个接口各自对应的统计信息，其中，设备集群中包括至少一个第二设备，第二设备用于通过至少一个接口提供服务，各个第二设备是分别发送各自对应的接口的统计信息。

例如当前在设备集群中包括第二设备20以及第二设备30，第二设备30对应接口1和接口2，第二设备对应接口3，则第一设备可以接收第二设备20发送的接口1的统计信息和接口2的统计信息，以及第一设备可以接收第二设备30发送的接口3的统计信息。

在一种可能的实现方式中，在统计信息中可以包括接口的标识、接口对应的至少一个监测时刻、接口在每个监测时刻接收到的请求消息的数量。

以任一个接口为例进行介绍，各个接口的实现方式均是相同的，假设当前针对接口1，在接口1的统计信息中，接口的标识用于对接口1进行唯一的指示，表示当前的统计信息是接口1的统计信息，其中接口的标识例如可以为接口名，或者标识字符串等等，本实施例对接口的标识不做限制，其可以根据实际需求进行选择，只要接口的标识可以用于实现对接口的唯一指示即可。

以及本实施例中是需要确定各个第二设备的接口在各个时刻的请求数，因此在统计信息中还包括接口对应的至少一个监测时刻，以及接口在每个监测时刻接收到的请求消息的数量。

因为本实施例中的QPS是每秒请求数，因此在一种可能的实现方式中，一个监测时刻的时间单位例如可以为1秒，则统计信息中就可以包括接口在各秒内接收到的请求消息的数量。

在一种可能的实现方式中，比如说统计信息中按照如下方式存储接口在各个监测时刻接收到的请求消息的数量。

监测时刻	接收到的请求消息的数量
		8:30:01	12
8:30:02	23
		8:30:03	13
…	…

按照上述表格即可以确定接口在各个监测时刻接收到的请求消息的数量，上述介绍的统计信息的实现方式例如可以按照表格的方式对统计信息进行存储，或者还可以按照键值对的方式对统计信息进行存储，本实施例对统计信息具体的数据格式不做限制，其可以根据实际需求进行选择，只要在统计信息中可以包括上述介绍的数据即可。

在另一种可能的实现方式中，本实施例中还可以设置有预设时段，预设时段内包括多个监测时刻，针对每个预设时段设置有一个统计数组，统计数组中的各个元素表示在预设时段内的各个监测时刻接收到的请求消息的数量，在这种实现方式下，只要确定预设时段的开始时刻，即可以根据预设时段的开始时刻以及统计数组中各个元素在数组中的位置，确定接口对应的至少一个监测时刻，以及在每个监测时刻接收到的请求消息的数量。

本实施例对统计信息的具体实现方式不做限制，只要在统计信息中可以包括接口的标识、接口对应的至少一个监测时刻，以及接口在每个监测时刻接收到的请求消息的数量即可，具体的实现方式可以根据实际需求进行选择。

S202、根据至少一个接口各自对应的统计信息，确定设备集群的QPS信息。

在接收到各个接口各自对应的统计信息之后，可以根据各个接口各自对应的统计信息，确定设备集群的QPS信息。

在一种可能的实现方式中，QPS信息例如可以为某个接口在一定时段内的峰值QPS，或者可以为某个设备在一定时段内的峰值QPS，或者还可以为峰值QPS的曲线等等，本实施例对集群的QPS信息的具体实现方式不做限制，其可以根据实际需求进行选择和扩展。

例如除了峰值QPS之外，还可以确定平均QPS等等，总之当前已经确定了设备集群中的各个第二设备的各个接口在各个监测时刻接收到的请求消息的数量，基于该数据，可以根据具体的需求确定任意的QPS信息，此处对此不做限定。

本公开实施例提供的数据处理方法，包括：接收设备集群中各第二设备分别发送的至少一个接口各自对应的统计信息，统计信息中包括接口的标识、接口对应的至少一个监测时刻、接口在每个监测时刻接收到的请求消息的数量。根据至少一个接口各自对应的统计信息，确定设备集群的QPS信息。通过接收集群中的各个第二设备各自发送的各个接口的统计信息，从而可以根据各接口的各自对应的统计信息，以有效确定集群的QPS信息，同时因为各个接口各自对应的统计信息，是各个第二设备根据接收到请求消息的时刻实时更新的，从而可以准确有效的实现对线上集群的QPS的监控。

在上述实施例的基础上，下面结合图3至图9对本公开提供的数据处理方法进行进一步的详细介绍，图3为本公开实施例提供的数据处理方法的流程图二，图4为本公开实施例提供的统计数组的实现示意图，图5为本公开实施例提供的确定第一目标统计信息的实现示意图，图6为本公开实施例提供的对第一目标统计信息分组的实现示意图，图7为本公开实施例提供的确定一组对应的总请求记录数组的实现示意图，图8为本公开实施例提供的确定峰值QPS的实现示意图，图9为本公开实施例提供的峰值QPS曲线的实现示意图。

如图3所示，该方法包括：

S301、接收设备集群中各第二设备分别发送的至少一个接口各自对应的统计信息，统计信息中包括接口的标识、接口对应的至少一个监测时刻、接口在每个监测时刻接收到的请求消息的数量。

其中，S301的实现方式与上述S201的实现方式类似，此处对相同部分不再进行赘述，在上述内容的基础上，本实施例中的统计信息还可以进一步的包括预设时段的起始时刻、接口所对应的第二设备的设备标识、以及第二设备所提供的服务的服务标识。

基于介绍可以确定的是，接口在每个监测时刻接收到的请求消息的数量例如可以存储在统计数组中，本实施例以请求消息的数量存储在数组中为例，对统计信息的实现方式进行介绍。

比如说当前针对接口A，其统计信息例如可以包括如下内容：接口A的标识、统计数组、预设时段的起始时刻，接口A所对应的第二设备的设备标识，接口A所对应的第二设备所提供的服务的服务标识。

其中，根据统计数组和预设时段的起始时刻就可以确定接口对应的至少一个监测时刻，以及接口在每个监测时刻接收到的请求消息的数量。

例如在一种可能的实现方式中，预设时段内可以包括n个监测时刻，在统计信息中可以包括统计数组，统计数组中包括n个元素，统计数组中的第i个元素就表示接口在预设时段的第i个监测时刻的接收到的请求消息的数量。

例如可以结合图4进行理解，假设预设时段包括60个监测时刻，以及一个监测时刻例如可以为1秒，则一个预设时段就是一分钟，假设当前预设时段的起始时刻是8:30:00，则预设时段就具体为8:30:00-8:30:59这个时段。

以及参见图4，例如当前时刻的统计数组为q，统计数组中的各个元素表示在预设时段内的各个监测时刻的请求消息的数量，例如q[0]就表示在预设时段内的第一个监测时刻的请求消息的数量，更为具体的含义就是说在8:30:00的请求消息的数量，以及，q[1]就表示在预设时段内的第二个监测时刻的请求消息的数量，更为具体的含义就是说在8:30:01的请求消息的数量，统计数组中其余元素的含义类似，可以参照图4进行理解，此处不再赘述。

上述图4是以预设时段是1分钟，预设时段中所包括的监测时刻的时间单元时1秒钟为例进行的介绍，在实际实现过程中，预设时段的长度，以及监测时刻所对应的时间单元的长度均可以根据实际需求进行选择，比如说预设时段的长度还可以为2分钟、5分钟、10分钟等等，本实施例对此不做限制。

因此基于预设时段的起始时刻和统计数组，就可以简单有效的确定接口在各个监测时刻所接收到的请求消息的数量。

S302、确定查询时段以及查询标识，查询标识包括如下中的至少一种：查询接口标识、查询设备标识、查询服务标识。

在本实施例中，第一设备在接收到各个第二设备发送的至少一个接口个各自对应的统计信息之后，可根据各个接口各自对应的统计信息，确定设备集群的QPS信息。

在一种可能的实现方式中，因为集群中的各个第二设备会持续的向第一设备发送各个接口在各个预设时段的统计信息，因此第一设备所接收到的统计信息的时间跨度是比较长度的，通常在确定集群的QPS信息的时候，需要的都是一段时间内的QPS信息，因此可以确定查询时段，其中查询时段是需要确定集群QPS信息的时段，其中查询时段例如可以包括查询起始时间和查询结束时间。

以及，第一设备会接收到集群中的各个第一设备的各个接口的统计信息，在确定集群的QPS信息的时候，可能需要查询某些特定标识对应的集群QPS信息。

因此本实施例中还可以确定查询标识，在一种可能的实现方式中，查询标识包括如下中的至少一种：查询接口标识、查询设备标识、查询服务标识。

比如说当前需要确定集群中的某个服务总体的QPS信息，则查询标识中例如可以包括查询服务标识；再比如说当前需要集群中的确定某个服务的某个接口的QPS信息，则查询标识中例如可以包括查询服务标识和查询接口标识；再比如说当前需要确定集群中的某个第一设备总体的QPS信息，则查询标识中例如可以包括查询设备标识；再比如说当前需要集群中的确定某个第一设备的某个接口的QPS信息，则查询标识中例如可以包括查询设备标识和查询接口标识。

在实际实现过程中，查询标识的具体实现方式可以根据实际需求进行选择，其具体取决于当前所需要查询的集群QPS信息的具体实现，本实施例对此不做特别限制。

S303、根据查询时段以及查询标识，在各统计信息中确定至少一个第一目标统计信息，其中，第一目标统计信息的预设时段的起始时刻在查询时段内，以及第一目标统计信息满足如下条件中的至少一种：第一目标统计信息的接口标识等于查询接口标识，第一目标统计信息的设备标识等于查询设备标识，第一目标统计信息的服务标识等于查询服务标识。

在确定查询时段以及查询信息之后，就可以在第一设备所接收到的各个统计信息中确定至少一个第一目标统计信息，其中，第一目标统计信息就是满足上述介绍的查询时段和查询标识的统计信息。

在一种可能的实现方式中，第一目标统计信息的预设时段的起始时刻在查询时段内，比如说查询时段的起始时刻是7:00:00-7:30:00，则可以将预设时段的起始时刻在7:00:00-7:30:00之间的统计信息首先筛选出来，得到满足时间条件的统计信息。

之后在满足时间条件得到时间条件的统计信息中，确定相应标识满足上述标识的统计信息。

具体的，第一目标统计信息满足如下条件中的至少一种：第一目标统计信息的接口标识等于查询接口标识，第一目标统计信息的设备标识等于查询设备标识，第一目标统计信息的服务标识等于查询服务标识。

第一目标统计信息所满足的具体条件取决于当前所要具体确定的集群QPS信息的类型。

例如当前需要查询的是集群中的某个服务总体的QPS信息，则第一目标统计信息所满足的条件可以为：第一目标统计信息的服务标识等于查询服务标识。

再例如当前需要查询的是集群中的某个服务的某个接口的QPS信息，则第一目标统计信息所满足的条件可以为：第一目标统计信息的服务标识等于查询服务标识，并且第一目标统计信息的接口标识等于查询接口标识。

再例如当前需要查询的是集群中的某个第一设备总体的QPS信息，则第一目标统计信息所满足的条件可以为：第一目标统计信息的设备标识等于查询设备标识。

再例如当前需要查询的是集群中的某个第一设备的某个接口的QPS信息，则第一目标统计信息所满足的条件可以为：第一目标统计信息的设备标识等于查询设备标识，并且第一目标统计信息的接口标识等于查询接口标识。

在实际实现过程中，第一目标统计信息具体需要满足什么条件，可以取决于当前需要查询集群中什么样的QPS信息，第一目标统计信息的相应标识只要和查询标识相同即可，本实施例对具体确定的查询标识以及根据查询标识确定的第一目标统计信息的具体实现方式不做限制，其可以根据实际需求进行选择和设置。

例如可以结合图5，以一个具体的示例，理解上述介绍的确定第一目标统计信息的过程。

如图5所示，假设当前存在统计信息1到统计信息x，则例如可以首先确定预设时段对的起始时刻在查询时段内的统计信息，作为初步筛选的统计信息。

之后根据具体的场景，按照相应的查询标识确定第一目标统计信息。

例如当前需要查询集群中服务1总体的QPS信息，则可以在初步筛选的统计信息中，确定服务标识等于服务1的标识的统计信息，从而确定服务1总体的第一目标统计信息。

再例如当前需要查询集群中服务1的接口A的QPS信息，则可以在服务1总体的第一目标统计信息中，确定接口标识等于接口A的标识的统计信息，从而确定服务1的接口A第一目标统计信息。

再例如当前需要查询集群中第一设备50总体的QPS信息，则可以在初步筛选的统计信息中，确定设备标识等于第一设备50的标识的统计信息，从而确定第一设备50总体的第一目标统计信息。

再例如当前需要查询集群中第一设备50的接口A的QPS信息，则可以在第一设备50总体的第一目标统计信息中，确定接口标识等于接口A的标识的统计信息，从而确定第一设备50的接口A第一目标统计信息。

上述图5介绍的实现方式中，是首先确定了满足查询时段的统计信息，其次确定满足查询标识的统计信息，从而得到第一目标统计信息，在另一种可能的实现方式中，还例如可以首先确定满足查询标识的统计信息，其次确定满足查询时段的统计信息，本实施例对此执行顺序不做限制，只要确定的第一目标统计信息是满足查询时段和查询标识的统计信息即可。

S304、根据至少一个第一目标统计信息，确定QPS信息。

在确定至少一个第一目标统计信息之后，可以根据至少一个第一目标统计信息确定QPS信息。

在一种可能的实现方式中，QPS信息例如可以为至少一个第一目标统计信息中的峰值QPS，其中确定峰值QPS的实现方式例如可以为：

在至少一个第一目标统计信息中，将预设时段的起始时刻相同的第一目标统计信息确定为一组，得到多个组。

可以理解的是，若一些第一目标统计信息的预设时段的起始时刻相同，则表示这些第一目标统计信息处于相同的预设时段内，则这些第一目标统计信息中所包括的请求消息的数量就是可以对应确定集群在各个监测时刻的请求消息的数量的总和的，因此可以将预设时段的起始时刻相同的第一目标统计信息确定为一组，从而得到多个组。

例如可以结合图6进行理解，参见图6，假设当前确定的至少一个第一目标统计信息包括第一目标统计信息1～第一目标统计信息t，则当前将预设时段的起始时刻相同的至少一个第一目标统计信息确定为一组，例如可以得到图6所示的分组结果。

比如说第一目标统计信息1和第一目标统计信息2的预设时段的起始时刻均为8:30:00，则例如可以将第一目标统计信息1和第一目标统计信息2确定为一组，得到图6所示的组A；以及比如说第一目标统计信息3、第一目标统计信息4和第一目标统计信息5的预设时段的起始时刻均为8:31:00，则例如可以将第一目标统计信息3、第一目标统计信息4以及第一目标统计信息5确定为一组，得到图6所示的组B，其余各个第一目标统计信息的分组方式类似。

可以理解的是，上述图6中介绍的第一目标统计信息及其分组方式仅为示例性的介绍，在实际实现过程中，第一目标统计信息的具体数量以及分组方式均可以根据实际需求进行选择，只要保证是将预设时段的起始时刻相同的第一目标统计信息确定为一组即可。

接下来，可以将各组中的第一目标统计信息的统计数组逐项相加，得到各组分别对应的总请求记录数组。

基于上述介绍的将预设时段的起始时刻相同的第一目标统计信息确定的一组的分组方式，可以确定的是，同一组中的各个第一目标统计信息的统计数组的各个元素在时间上是对应的。

比如说，第一目标统计信息1和第一目标统计信息2的预设时段的起始时刻相同，则第一目标统计信息1的统计数组中的元素q[0]表示的是8:30:00这一秒的请求数量，目标统计2的统计数组中的元素q[0]同样表示的是8:31:00这一秒的请求数量。

因此在本实施例中，可以将组中的第一目标统计信息的统计数组逐项相加，得到各组分别对应的总请求记录数组，其中总请求记录数组中就包括当前预设时段中，各个监测时刻的请求数量的总和。

例如可以结合图7进行理解，假设继续沿用上述图6的示例，其中第一目标统计信息1和第一目标统计信息2被确定为组A，则可以将第一目标统计信息1的统计数组和目标统计2的统计数组逐项相加，从而得到组A对应的总请求记录数组s，以及假设组A对应的预设时段的起始时刻是8:30:00，则当前的总请求记录数组s中记录的就是，在8:30:00～8:31:00这个预设时段中，集群在各个监测时刻接收到的请求消息的数量。

上述图7是以一个组为例进行的介绍，在具体实现过程中，各个组的实现方式类似，针对各个组均执行相同的操作，从而可以得到各个组各组对应的总请求记录数组。

以及值得说明的是，当前的总请求记录数组中记录的具体是集群哪一方面的请求消息的数量，取决于上述在确定第一目标统计信息时，是根据什么查询标识确定的，比如说当前确定的第一目标统计信息是根据查询接口标识确定的，则当前确定的第一目标统计信息就对应的是某个服务的总体的统计信息，则可以确定当前的总请求记录数组中的各个元素，指示的就是某个服务总体，在各个监测时刻中请求消息的数量，其余场景的实现方式类似，此处不再赘述。

之后，可以在各组分别对应的总请求记录数组中分别确定各组对应的最大请求数。

并将各组对应的最大请求数中的最大值，确定为峰值QPS。

具体的，在得到各组分别对应的总请求记录数组之后，当前就确定了查询时段所包括的各个预设时段的总请求记录数组，以及根据各个预设时段的总请求记录数组，就可以确定在查询时段内的各个监测时刻所对应的请求消息的数量。

因此在确定峰值QPS的时候，可以分别在各个总请求记录数组中确定最大值，从而确定各组对应的最大请求数，之后在各组对应的最大请求数中确定最大值，从而得到峰值QPS。

例如可以结合图8进行理解，假设当前在组A对应的总请求记录数组s中确定了最大请求数79，以及在组B对应的总请求记录数组s中确定了最大请求数77，以及在组C对应的总请求记录数组s中确定了最大请求数79，这就相当于确定了在查询时段中的各个预设时段中分别的最大请求数，之后在各个预设时段对应的最大请求数中确定最大值，从而可以确定在查询时段内的各个监测时刻的请求数量的最大值，从而可以确定在查询时段内的峰值QPS，例如可以为图8所示的峰值QPS 79。

上述介绍的是QPS信息为峰值QPS的实现方式，在另一种可能的实现方式中，QPS信息还可以为查询时段内的峰值QPS曲线。

其中，确定峰值QPS曲线的实现方式可以为，根据预设时间间隔将查询时段划分为至少一个子时段。

比如说查询时段是8:30:00-9:30:00，预设时间间隔例如可以为10分钟，则可以将查询时段划分为8:30:00-8:40:00、8:40:00-8:50:00等等的子时段。

之后，确定各子时段各自对应的峰值QPS。

其中，确定各个子时段各自对应的峰值QPS的实现方式与上述介绍的确定峰值QPS的实现方式相同，此处不再赘述。

之后，根据各自时段各自对应的峰值QPS，确定峰值QPS曲线。

具体的，在确定各个子时段各自对应的峰值QPS之后，可以将各个子时段的峰值QPS连接起来，从而得到峰值QPS曲线，例如可以结合图9进行理解。

如图9所示，例如当前按照10分钟的时间间隔，将查询时段8:30:00-9:30:00分为了6个子时段，其中，子时段8:30:00-8:40:00对应的峰值QPS例如为79，子时段8:40:00-8:50:00对应的峰值QPS例如为67，子时段8:50:00-9:00:00对应的峰值QPS例如为45，子时段9:00:00-9:10:00对应的峰值QPS例如为36，子时段9:10:00-9:20:00对应的峰值QPS例如为56，子时段9:20:00-9:30:00对应的峰值QPS例如为18，则基于各个自子时段的峰值QPS，例如可以得到图8所示的峰值QPS曲线。

本实施例对确定的QPS信息的具体类型不做限制，其可以根据实际需求进行选择，凡是根据各个第二设备对应的统计信息确定的集群的QPS相关的信息，均可以作为本实施例中的QPS信息，本实施例对此不做特别限制。

本公开实施例提供的数据处理方法，通过接收各个第二设备分别发送到的统计信息，从而可以有效确定集群的统计信息，以及根据查询时段和查询标识，在各个统计信息中确定对应的第一目标统计信息，从而可以根据实际需求查询指定时段内的指定类型的统计信息，之后根据第一目标统计信息确定集群的QPS信息，从而可以准确的实现对于集群的QPS信息的确定，并且其中的查询时段和查询标识都是根据实际需求选择的，从而可以有效的实现对需要的集群QPS信息的确定。

在上述实施例的基础上，上述介绍的是后台的第一设备对集群中各个第二设备的统计信息进行处理，以确定集群的QPS信息的实现方式，下面结合具体的实施例对第二设备侧确定统计信息的实现方式进行说明。

值得说明的是，当前介绍的第二设备侧的实现方式，可以应用于设备集群中的任意一个第二设备，其中第二设备用于通过至少一个接口提供服务，各个第二设备的实现方式是相同的，下面以任意一个第二设备为例，对第二设备确定统计信息的实现方式进行介绍。

图10为本公开实施例提供的数据处理方法的流程图三。

如图10所示，该方法包括：

S1001、确定至少一个请求消息中每个请求消息对应的接口和接收时刻，至少一个请求消息为在预设时段内通过各接口接收到的，预设时段包括n个监测时刻，n为大于等于1的整数。

在本实施例中，第二设备会接收请求消息，在一种可能的实现方式中，为了便于对第二设备接收到的请求消息进行统计，可以以预设时段为单位，统计第二设备所接收到的请求消息，其中，预设时段例如可以包括n个监测时刻，监测时刻和预设时段的实现方式与上述实施例介绍的类似，此处不再赘述。

以及，本实施例中的请求消息是第二设备通过其所提供服务的接口接收的，也就是说请求消息是针对接口的，因此本实施例中的请求消息为第二设备在预设时段内通过各个接口接收到的。

本实施例的第二设备在预设时段内可以接收到至少一个请求消息，其中每个请求消息都对应有接口和接收时刻，其中，请求消息对应的接口用于指示该请求消息当前请求的是哪个接口，比如说请求消息1对应的接口是接口A，则表示当前请求消息请求是针对接口A发起的请求；以及，请求消息的接收时刻是指第二设备接收到请求消息的时刻。

在实际实现过程中，第二设备在预设时段内所接收到的请求消息的数量，以及各个请求消息所对应的接口和请求时间，均可以根据实际需求进行选择，本实施例对此不做特别限制。

S1002、根据每个请求消息对应的接口和接收时刻，确定至少一个接口各自对应的统计信息，统计信息中包括接口的标识、接口对应的至少一个监测时刻、接口在每个监测时刻接收到的请求消息的数量。

针对每一个请求消息，可以根据请求消息对应的接口和接收时刻，对至少一个接口各自对应的统计信息进行更新，从而确定各个接口各自对应的统计信息。

其中，接口对应的统计信息中包括接口的标识，用于指示当前的统计信息是哪一个接口的统计信息；以及在接口对应的统计信息中还包括接口对应的至少一个监测时刻，以及接口在每个监测时刻接受到的请求消息的数量，用于指示该接口在各个监测时刻所接受到的请求消息的数量。

在一种可能的实现方式中，例如可以在接收到一个请求消息的时候，就根据当前接收到的请求消息，对该请求消息对应的接口的统计信息进行更新，例如当前的请求消息是针对接口A的请求消息，该请求消息的接收时刻是8:30:34，则就可以在接收到该请求消息的时候，将接口A的统计信息中，在8:30:34的监测时刻接收到的请求消息的数量加一。根据在预设时段内接收到的各个请求消息，实时的进行上述操作，从而可以在预设时段结束时，确定至少一个接口各自对应的统计信息。

在另一种可能的实现方式中，例如可以在当前的预设时段结束之后，根据预设时段内所接收到的各个请求消息，再根据各个请求消息对应的接口和接收时刻，依次对各个对应的接口的统计信息进行更新，从而可以得到至少一个接口各自对应的统计信息，更新的实现方式与上述介绍的类似，此处不再赘述。

在具体实现过程中，具体是采用实时更新的方式确定至少一个接口各自对应的统计信息，还是采用预设时段结束之后一起更新的方式确定至少一个接口各自对应的统计信息，可以根据实际需求进行选择，本实施例对此不做特别限制。

值得说明的是，当前确定了统计信息的至少一个接口是在该预设时段内接收到请求消息的接口，比如说当前存在接口A、接口B、接口C，以及在当前的预设时段内，假设针对接口A和接口B存在请求消息，存在接口C不存在请求消息，则最终确定的统计信息包括接口A的统计信息和接口B的统计信息。

S1003、向第一设备发送各统计信息，统计信息用于第一设备确定设备集群的QPS信息。

在确定至少一个接口各自对应的统计信息之后，就可以向第一设备发送各个统计信息，以使得第一设备可以根据各个第一设备发送的统计信息，确定设备集群的QPS信息。

值得说明的是，上述介绍的是在一个预设时段内的执行过程，第二设备会以预设时段对应的时长为周期，持续的确定各个预设时段内的统计信息，比如说预设时段对应的时长是1分钟，以及假设当前预设时段是8:30:00-8:31:00，则在8:30:00-8:31:00这个预设时段结束之后，在下一个预设时段8:31:00-8:32:00会重复执行上述过程，因此集群中的各个第一设备会持续不断的确定统计信息，并持续向第二设备发送确定的统计信息，因此第二设备可以准确有效的确定集群的QPS信息。

本公开实施例提供的数据处理方法，包括：确定至少一个请求消息中每个请求消息对应的接口和接收时刻，至少一个请求消息为在预设时段内通过各接口接收到的，预设时段包括n个监测时刻，n为大于等于1的整数。根据每个请求消息对应的接口和接收时刻，确定至少一个接口各自对应的统计信息，统计信息中包括接口的标识、接口对应的至少一个监测时刻、接口在每个监测时刻接收到的请求消息的数量。向第一设备发送各统计信息，统计信息用于第一设备确定设备集群的QPS信息。通过第一设备在预设时段内根据接收到的至少一个请求消息，确定至少一个接口各自对应的统计信息，其中统计信息可以指示接口在各个监测时刻接收到的请求消息的数量，基于请求消息可以准确有效的确定接口对应的统计信息，之后向第一设备发送统计信息，从而可以使得第一设备根据各个第二设备发送的统计信息，准确的确定集群的QPS信息。

在上述实施例的基础上，下面对第二设备确定统计信息的实现方式进行进一步的详细介绍，图11为本公开实施例提供的数据处理方法的流程图四，图12为本公开实施例提供的确定第二目标统计信息的实现示意图，图13为本公开实施例提供的更新统计数组中的目标元素的实现示意图。

如图11所示，该方法包括：

S1101、确定至少一个请求消息中每个请求消息对应的接口和接收时刻，至少一个请求消息为在预设时段内通过各接口接收到的，预设时段包括n个监测时刻，n为大于等于1的整数。

其中，S1101的实现方式与S1001的实现方式类似，此处不再赘述。

S1102、在接收到请求消息之后，根据请求消息对应的接口确定第二目标统计信息。

在本实施例中，在第二设备接收到请求消息之后，可以首先根据请求消息对应的接口确定第二目标统计信息，其中，第二目标统计信息中的接口的标识和请求消息对应的接口的标识是相同的。

在一种可能的实现方式中，可以首先获取请求消息对应的接口的第一标识，之后根据该第一标识确定对应的第二目标统计信息。

其中，可以首先在第二设备存储的第一集合中查找第二目标统计信息，具体的，在第二设备中存储有第一集合，第一集合用于存储各个接口各自对应的统计信息。

例如可以结合图12进行理解，假设当前存在第一集合，第一集合中可以包括至少一个接口的统计信息，比如说当前包括接口A对应的统计信息1，接口2对应的统计信息2。

在本实施例中，可以在接收到针对某个接口的请求消息的时候，再创建该接口对应的统计信息，之后再次接收到针对该接口的请求消息的时候，就可以直接应用该统计信息。

则可以首先在第二设备存储的第一集合中查找接口的标识和第一标识相同的第二目标统计信息，若确定第一集合中存在第二目标统计信息，则可以从第一集合中获取该第二目标统计信息。

比如说可以结合图12进行理解，假设当前的请求消息是针对接口A的请求消息，则可以确定请求消息对应的接口的第一标识是接口A，之后在第一集合中查找接口A对应的统计信息，因为第一集合中包括接口A对应的统计信息1，因此可以从第一集合中获取接口A对应的统计信息1，从而得到第二目标统计信息。

或者，若确定第一集合中不存在第二目标统计信息，则可以根据请求消息对应的接口，创建该接口对应的第二目标统计信息。

具体的，在第一集合中不存在第二目标统计信息，则表示当前第二设备是首次接收到针对该接口的请求消息，则可以根据当前的请求消息创建该接口所对应的第二目标统计信息。

比如说可以结合图12进行理解，假设当前的请求消息是针对接口C的请求消息，则可以确定请求消息对应的接口的第一标识是接口C，之后在第一集合中查找接口C对应的统计信息，因为第一集合中不包括接口C对应的统计信息，因此可以创建接口C对应的统计信息，并将创建的接口C对应的统计信息确定为第二目标统计信息，在确定第二目标统计信息之后，例如可以将创建的统计信息存储在第一集合中，以便于下次在接收到针对接口C的请求的时候，可以直接从第一集合中获取该请求消息。例如参见图12，在创建接口C对应的统计信息3之后，将统计信息3存储在第一集合中。

在一种可能的实现方式中，统计信息中例如可以包括接口的标识、预设时段的起始时刻，以及统计数组，其中，统计数组中包括n个元素，统计数组中的第i个元素表示接口在预设时段的第i个监测时刻接收到的请求消息的数量，n为大于等于1的整数，i为大于等于1并且小于等于n的整数，有关统计信息的更为详细的实现方式可以参照上述实施例的介绍，此处不再赘述。

因此在一种可能的实现方式中，在根据请求消息对应的接口创建第二目标统计信息的时候，可以包括：

将请求消息对应的接口的第一标识确定为第二目标统计信息的接口的标识。

其中，因为当前请求消息对应的接口的第一标识指示了当前需要请求的接口，并且确定不存在该接口的统计信息，因此当前就是需要针对该接口进行统计信息的创建，因此可以将第一标识确定为第二目标统计信息的接口的标识。

以及，确定当前时刻之前最邻近的目标时刻，将目标时刻确定为第二目标统计信息的预设时段的起始时刻，其中，目标时刻为整点时刻或者整分时刻。

在本实施例中，为了便于统计数组中各元素的对应关系，因此集群中的所有第一设备都采用同步的预设时段，同时为了便于管理，本实施例中的预设时段的起始时刻都是整点时刻或者整分时刻，比如说整7点、整8点，或者说7点整3分，7点整4分等等。

因此在初始化第二目标统计信息的时候，可以将当前时刻之前最邻近的目标时刻，确定为第二目标统计信息的预设时段的起始时刻。

此处可以进行举例说明，比如说需要进行第二目标统计信息的创建的当前时刻是8:30:34，因为这并不是一个整分时刻，因此需要确定当前时刻之前最邻近的整分时刻，因此可以确定的目标时刻为8:30:00，并将该目标时刻确定为预设时段的起始时刻。因此本实施例中在确定预设时段的起始时刻的时候，是将当前时刻之前邻近的整点时刻或者整分时刻确定为预设时段的起始时刻。

以及，根据预设时段所包括的监测时刻的数量创建第二目标统计信息的统计数组，其中，统计数组所包括的元素的数量和预设时段所包括的监测时刻的数量，统计数组的各个元素初始化为第二预设数值。

在本实施例中，还需要进行统计数组的初始化，本实施例中统计数组中的元素数量n等于预设时段中所包括的监测时刻的数量n，因此可以根据预设时段所包括的监测时刻的数量创建第二目标统计信息的统计数组，并且将统计数组中的各个元素初始化为第二预设数值。在一种可能的实现方式中，第二预设数值例如可以为0。

比如说预设时段为1分钟，预设时段中所包括的监测时刻的数量是60，一秒钟对应一个监测时刻，则可以创建包括60个元素的统计数组，数组中的各个元素用于表示在各个监测时刻接收到的请求消息的数量。

在实际实现过程中，具体的获取第二目标统计信息的实现方式可以根据实际需求进行确定，其取决于当前在第一集合中是否存在请求消息对应的统计信息，若存在就直接获取，若不存在则创建。

本实施例中通过在接收到针对某个接口的请求消息的时候，再实时的创建该接口对应的统计信息，从而可以根据实际需求进行统计信息的创建，避免针对所有的接口都创建统计信息所导致的系统资源的浪费。

S1103、确定请求消息的接收时刻和预设时段的起始时刻的差值s。

在确定当前请求消息对应的接口的第二目标统计信息之后，可以确定请求消息的接收时刻和预设时段的起始时刻的差值s，可以理解的是，该差值s可以指示请求消息的接收时刻对应的是当前预设时段中的第几个监测时刻，进而可以对相应监测位置的统计数组的元素进行更新。

S1104、将第二目标统计信息的统计数组中的第s个元素确定为目标元素。

S1105、将当前的目标元素加上第一预设数值，得到更新后的目标元素。

下面对S1104和S1105一起进行介绍：

本实施例中的差值s可以指示请求消息的接收时刻当前对应的是预设时段中的第几个监测时刻，在第二目标统计信息中的统计数组用于记录各个监测时刻对应的请求消息的数量，因此可以将第二目标统计信息的统计数组中的第s个元素确定为目标元素，其中，目标元素也就是说需要对请求消息的数量进行记录的时刻。

在一种可能的实现方式中，可以将当前的目标元素加上第一预设数值，从而得到更新后的目标元素，其中，第一预设数值例如可以为1，也就是说对目标元素进行加1，表示当前监测时刻接收到的请求消息的数量增加了1个；或者，第一预设数值也可以为其余的数值实现方式，本实施例对此不做限制，当第一预设数值为其余数值的时候，在后续进行相应的处理即可。

下面结合图13对上述介绍的过程进行介绍，如图13所示，假设当前预设时段的起始时刻是8:30:00，以及假设请求消息的接收时刻是8:30:04，则可以确定预设时段的起始时刻和请求消息的接收时刻之间的差值s为4，基于该差值4，可以确定第二目标统计信息的统计数组q中的第4个元素为目标元素，也就是图13中所示的q[3]，之后将q[3]加上预设数值1，q[3]就变为了1，表示在8:30:04这个时刻接收到了一个请求消息。

S1106、判断当前时刻是否为预设时段的结束时刻，若是，则执行S1107，若否，则执行S1102。

值得说明的是，本实施例中预设时段的起始时刻开始，就会执行上述介绍的根据请求消息对应的接口确定第二目标统计信息，并根据请求消息的接收时刻更新第二目标统计信息的操作，直至预设时段结束。

因此在执行完上述操作之后，可以判断当前时刻是否为预设时段的结束时刻，若否，则表示当前预设时段尚未结束，还需要继续执行上述操作，因此重复从上述的S1102执行操作。

在判断当前时刻是否为预设时段的结束时刻时，在一种可能的实现方式中，可以将当前时刻和预设时段的结束时刻相比，从而判断当前时刻是否为预设时段的结束时刻。

或者，可以将当前确定的差值s和预设时段所包括的监测时刻的数量n相比，若s大于或等于n，则表示当前接收到请求消息的时刻已经超出了预设时段或者到达了预设时段的结束时刻，因此可以确定当前时刻是预设时段的结束时刻；若s小于n，则表示当前接收到请求消息的时刻还在预设时段内，因此可以确定当前时刻不是预设时段的结束时刻。

在实际实现过程中，具体的判断方式可以根据实际需求进行选择，本实施例对此不做特别限制。

S1107、向第一设备发送各统计信息，统计信息用于第一设备确定设备集群的QPS信息。

在另一种可能的实现方式中，若确定当前时刻为预设时段的结束时刻，则可以确定当前这个预设时段结束了，因此可以向第一设备发送该预设时段中确定的各个统计信息，以使得第一设备可以根据统计信息确定设备集群的QPS信息，更为具体的实现方式可以参照上述S1003的介绍，此处不再赘述

本公开实施例提供的数据处理方法，包括：确定至少一个请求消息中每个请求消息对应的接口和接收时刻，至少一个请求消息为在预设时段内通过各接口接收到的，预设时段包括n个监测时刻，n为大于等于1的整数。在接收到请求消息之后，根据请求消息对应的接口确定第二目标统计信息。确定请求消息的接收时刻和预设时段的起始时刻的差值s。将第二目标统计信息的统计数组中的第s个元素确定为目标元素。将当前的目标元素加上第一预设数值，得到更新后的目标元素。判断当前时刻是否为预设时段的结束时刻，若是，则向第一设备发送各统计信息，统计信息用于第一设备确定设备集群的QPS信息。通过根据请求消息对应的接口确定第二目标统计信息，其中，在第一集合中包括第二目标统计信息的可以直接获取，在第一集合中不包括第二目标统计信息的时候进行第二目标统计信息的创建，从而可以在接收到针对某个接口的时候，再实时的创建该接口对应的统计信息，以避免针对所有的接口都创建统计信息所导致的系统资源的浪费；同时，本实施例中根据请求消息的接收时刻和预设时段的起始时刻的差值s，对数组中的第s个元素进行更新，从而可以简单有序的实现对于各个接口对应的请求消息的数量的记录，同时本实施例中通过设置集群中的各个第二设备的预设时段是同步的，以及预设时段的起始时刻为整点时刻或者整分时刻，从而可以保证同一个预设时段中，各个接口对应的统计数组可以直接进行对应元素的操作，避免了需要进行时间对齐等复杂的操作，有效降低了第一设备确定集群QPS信息的复杂性。

在上述实施例的基础上，下面结合图14和图15对本公开中第一设备的操作和第二设备的操作进行一个系统的说明，图14为本公开实施例提供的数据处理方法的处理示意图，图15为本公开实施例提供的确定峰值QPS曲线的流程示意图。

如图14所示，本实施例中的数据处理方法分为两个阶段，一个是在第二设备一侧执行的采集阶段，另一个是在第一设备一侧执行的分析阶段，其中，在采集阶段可以采集各个第二设备上的各接口的统计信息，之后上传到后台的第一设备。在分析阶段可以在后台将所有上传来的统计信息进行分析，汇聚成分布式服务级别的集群的接口的QPS信息。

下面对两个阶段分别进行介绍：

首先对采集阶段进行介绍，基于上述介绍可以确定的是，在采集阶段中，需要以统计信息的形式对各个接口的接收到的请求进行存储，其中统计信息例如可以采用向量进行描述，因此在一种可能的实现方式中，例如可以采用如下伪代码描述接口的统计信息的向量数据结构：

struct qps_vec{

string method_name；

int qps[N]；

long start_timestamp；

}；

其中，method_name代表接口名，例如可以对应上述介绍的接口的标识，为字符串。

qps是统计数组，其中的每一个元素代表一秒钟的请求消息的数量，其中N代表qps数组的长度，需要与预设时段中包括的监测时刻的数量相等。本实施例中假设一个监测时刻为1秒，则qps[0]代表预设时段中第一秒的请求数，qps[1]代表预设时段中第二秒的请求数，以此类推。

start_timestamp为预设时段的起始时刻，可以精确到秒，一个预设时段中可以包含N秒。本实施例中例如可以设置start_timestamp是一个所有第二设备可以同步开始的时间，例如可以是整分钟，整小时等，以便于后续对各个预设时段中的统计数组进行对应处理，具体的实现方式可以参照上述的介绍。

在每个第二设备中，都维护一个qps_vec类型的集合，记为vec_set，vec_set可以对应上述实施例中介绍的第一接口。

针对第二设备中的每一个接口，都可以存在一个qps_vec结构的向量vec(也就是统计信息)存储在第一集合vec_set中，其中vec.method_name等于接口名，vec.qps可以初始化为长度为N的统计数组。vec.start_timestamp可以初始化为当前时间之前最邻近的整点时间或者整分时间，精确到秒。

其中，这个表示统计信息的向量vec可以在接口实际发生请求后再实际创建。

具体的，当每次请求发生时，可以通过某种方式拦截请求消息(常见的方法如采集请求日志、Java Agent字节码增强技术，基础设施层hook等)。例如每一次拦截到的请求消息可以为如下结构：

struct req_info{

string method_name；

long timestamp；

}；

其中method_name代表发生请求的接口名，timestamp代表请求消息的接收时间，精确到秒。

之后可以在第一集合vec_set中查找接口名method_name与请求消息req_info中的接口名匹配的第一目标统计信息qps_vec，如果存在则直接确定目标统计信息，如果不存在则按照上面描述的过程创建一个新的第一目标统计信息qps_vec。也就是上述介绍的在第一集合中存在请求的接口对应的第一目标统计信息的时候，直接获取第一目标统计信息；在第一集合中不存在请求的接口对应的第一目标统计信息的时候，创建当前请求的接口对应的统计信息。

之后，可以计算请求消息的接收时间req_info.timestamp与目标统计信息qps_vec的预设时段的起始时刻start_timestamp的差值s，其中差值s精确到整数秒，之后将qps_vec.qps[s]加1。

例如，当N＝60时，一个预设时段内某个接口的统计信息qps_vec中的统计数组qps应该呈现为qps[0]＝qps0,qps[1]＝qps1,...qps[N-1]＝qpsN-1其中qps<n>为第n秒的接口QPS。

当一个预设时段结束(到达N秒)的时候，可以将该时段中的统计信息qps_vec移除出第一集合vec_set，并开始新的预设时段，同时可以将统计信息qps_vec结构转换为如下结构，并向第一设备发送：

struct instance_qps_vec{

string instance_id；

string app_name；

string method_name；

int qps[N]；

long start_timestamp；

}；

其中instance_id为本台第二设备的标识，app_name为本第二设备所属的分布式服务的标识名字，其它字段与qps_vec中的含义相同。也就是说本实施例的统计信息除上述介绍的接口名、统计数组、预设时段的起始时刻之外，还可以包括接口对应的第二设备的标识和第二设备对应的服务的标识。

可以理解的是，上述是以任一个第二设备为例进行的介绍，各个第二设备均可以执行上述操作，因此如图14所示，各个第二设备均可以向后台的第一设备上传各自对应的统计信息。

在上述介绍的采集阶段的基础上，下面对后台的第一设备所执行的分析阶段进行介绍。

后台的第一设备在接收到各个第二设备发送的统计信息之后，例如可以选择如SQL、NoSQL、NewSQL等存储介质，来存储统计信息，以便于后续从存储介质中获取相应的统计信息，从而确定集群的QPS信息。

其中，在分析阶段可以根据实际的QPS需求确定集群的QPS信息，例如QPS需求可以包括如下中的至少一种：

计算某个服务总体的峰值QPS；

计算某个服务某个接口的峰值QPS；

计算某个第二设备总体的峰值QPS；

计算某个第二设备上某个接口的峰值QPS；

计算QPS曲线；

基于上述分析阶段的介绍可以确定的是，各个第二设备可以将完整的统计信息instance_qps_vec上传到后台的第一设备，当前以vec_tbl来指代第一设备中存储各第二设备上传的统计信息instance_qps_vec项。

在一种可能的实现方式中，当QPS信息为峰值QPS时，例如可以按照如下流程计算一段时间内的峰值QPS：

1、确定查询时段，start_ts为查询时段的起始时刻，end_ts为查询时段的结束时刻，确定查询标识，查询标识可以包括如下中的至少一种：要查询的接口名method_name，要查询的第二设备标识instance_id，要查询的服务标识app_name。

2、从vec_tbl中筛选出预设时段的起始时刻start_timestamp在start_ts与end_ts之间的所有统计信息。并根据下列场景所描述的查询条件进一步筛选：

a)计算某个服务总体的峰值QPS：app_name等于要查询的服务标识；

b)计算某个服务某个接口的峰值QPS：app_name等于要查询的服务标识且method_name等于要查询接口标识；

c)计算某个第二设备总体的峰值QPS：instance_id等于要查询的第二设备的标识；

d)计算某个第二设备上某个接口的峰值QPS：instance_id等于要查询的第二设备的标识且method_name等于要查询的接口名。

也就是说在各个统计信息中，确定满足查询标识和查询时段的第二目标统计信息。

3、将确定的第二目标统计信息instance_qps_vec按照预设时段的起始时刻start_timestamp进行分组，可以将所有start_timestamp相同的第二目标统计信息存入一个组group，于是可得到若干个group，对于每个group的所有第二目标统计信息，按照其中统计数组的每一项逐项相加，得到总请求记录数组，例如可以表示为group_qps_sum数组，其中：

group_qps_sum[n]＝sum(instance_qps_vec.qps[n])，其中n＝0..N-1

4、求每个group中总请求记录数组group_qps_sum中最大的一项记为最大请求数group_qps_max，即group_qps_max＝max(group_qps_sum[0..N-1])

5、求各group中的最大请求数group_qps_max的最大值，记为最大值qps_max，即qps_max＝max(group_qps_max)。

6、其中，最大值qps_max即为start_ts到end_ts的查询时段中，集群中相应的峰值QPS，具体是哪种类型的峰值QPS，取决于上述的查询标识。

上述介绍的是QPS信息是峰值QPS的实现方式，在另一种可能的实现方式中，QPS信息还例如可以为峰值QPS曲线。

具体的，可以根据预设时间间隔将查询时段划分为至少一个子时段，确定各子时段各自对应的峰值QPS，根据各自时段各自对应的峰值QPS，确定峰值QPS曲线。

例如可以结合图15理解确定QPS曲线的过程，如图15所示，可以确定查询时段的开始时间start_ts和结束时间end_ts，以及可以确定预设时间间隔interval，用于后续进行子时段的划分。

之后，可以从开始时间开始进行处理，将当前时间点cur_ts初始化为开始时间start_ts，之后创建数组line[P]，其中数组line[P]用于记录各个时间点的峰值QPS，其实P为时间点的数量，也就是上述介绍的子时段的数量。

以及可以将循环的标识i初始化为0，表示从数组中的第一个元素line[0]开始进行处理，之后可以判断当前时间点是否小于结束时间点，这个判断作为结束的循环条件执行。

在一种可能的实现方式中，若当前时间点cur_ts小于结束时间end_ts，则可以确定当前未执行到查询时段的结束之间，需要继续执行后续流程。

具体的，可以计算当前时间点cur_ts到cur_ts+interval的子时段之间的峰值QPS，即为qps，确定峰值QPS的实现方式与上述介绍的类似，此处不再赘述。

之后将当前确定的峰值QPS确定为line数组中的元素，具体的，设置line[i]＝qps，并且记i＝i+1，以便进行下一次的处理。

之后将当前时间点加上预设时间间隔(cur_ts+interval)的时间点确定为新的当前时间点cur_ts，之后再判断当前时间点是否小于结束时间。

若确定当前时间点小于结束时间，则重复执行上述操作；若确定当前时间点不小于结束时间，则可以确定得到line数组，其中，line数组中的数组元素即表示各个子时段对应的峰值QPS，根据line数组中的各个数组元素即可以得到QPS曲线。

同时值得说明的是，本实施例中的统计数组中的元素个数n可以根据实际需求进行选择，可以理解的是，n越大，则统计信息的数量越少，但是单个统计信息的数据量就越大；相应的，n越小，则统计信息的数量越多，但是单个统计信息的数据量就越小，在实际实现过程中，可以根据实际需求选择n的设置，例如可以根据后台的第一设备的存储介质的实际情况对n进行调整。

综上所述，本公开实施例提供的数据处理方法，包括第二设备一侧的采集阶段和第一设备一侧的分析阶段，上述实现过程，适用于线上服务，可以计算集群的QPS，并且实时根据各个预设时段内的请求消息更新统计数组，从而可以保证确定的QPS信息的准确性，以及本公开提供的数据处理方法适用于任意分布式架构，不绑定特定网关产品，且适用于内部服务间调用，因此本公开实施例提供的数据处理方法，可以准确有效的实现对于集群QPS信息的确定。

图16为本公开实施例的数据处理装置的结构示意图一。如图16所示，本实施例的数据处理装置1600可以包括：接收模块1601、确定模块1602。

本实施例提供的数据处理装置1600应用于第一设备，所述第一设备用于确定设备集群的每秒请求数QPS信息，所述设备集群中包括至少一个第二设备，所述第二设备用于通过至少一个接口提供服务，所述数据处理装置1600包括：

接收模块1601，用于接收设备集群中各所述第二设备分别发送的至少一个所述接口各自对应的统计信息，所述统计信息中包括所述接口的标识、所述接口对应的至少一个监测时刻、所述接口在每个监测时刻接收到的请求消息的数量；

确定模块1602，用于根据至少一个所述接口各自对应的统计信息，确定所述设备集群的QPS信息。

一种可能的实现方式中，所述统计信息还包括预设时段的起始时刻、接口所对应的第二设备的设备标识、以及所述第二设备所提供的服务的服务标识；

所述确定模块1602包括：

第一确定单元，用于确定查询时段以及查询标识，所述查询标识包括如下中的至少一种：查询接口标识、查询设备标识、查询服务标识；

第二确定单元，用于根据所述查询时段以及所述查询标识，在各所述统计信息中确定至少一个第一目标统计信息，其中，所述第一目标统计信息的预设时段的起始时刻在所述查询时段内，以及所述第一目标统计信息满足如下条件中的至少一种：所述第一目标统计信息的接口标识等于所述查询接口标识，所述第一目标统计信息的设备标识等于所述查询设备标识，所述第一目标统计信息的服务标识等于所述查询服务标识；

第三确定单元，用于根据所述至少一个第一目标统计信息，确定所述QPS信息。

一种可能的实现方式中，所述预设时段内包括n个监测时刻，所述统计信息中包括统计数组，所述统计数组中包括n个元素，所述统计数组中的第i个元素表示接口在所述预设时段的第i个监测时刻接收到的请求消息的数量，所述n为大于等于1的整数，所述i为大于等于1并且小于等于n的整数；

所述QPS信息包括峰值QPS；

所述第三确定单元具体用于：

在所述至少一个第一目标统计信息中，将预设时段的起始时刻相同的第一目标统计信息确定为一组，得到多个组；

将各组中的第一目标统计信息的统计数组逐项相加，得到各组分别对应的总请求记录数组；

在各组分别对应的总请求记录数组中分别确定各组对应的最大请求数；

将所述各组对应的最大请求数中的最大值，确定为所述峰值QPS。

一种可能的实现方式中，所述QPS信息包括峰值QPS曲线；

所述第三确定单元具体用于：

根据预设时间间隔将所述查询时段划分为至少一个子时段；

确定各所述子时段各自对应的峰值QPS；

根据各所述自时段各自对应的峰值QPS，确定所述峰值QPS曲线。

图17为本公开实施例的数据处理装置的结构示意图二。如图17所示，本实施例的数据处理装置1700可以包括：请求消息确定模块1701、统计信息确定模块1702、发送模块1703。

本实施例提供的数据处理装置1700应用于设备集群中的任意一个第二设备，所述第二设备用于通过至少一个接口提供服务，所述数据处理装置1700包括：

请求消息确定模块1701，用于确定至少一个请求消息中每个请求消息对应的接口和接收时刻，所述至少一个请求消息为在预设时段内通过各所述接口接收到的，所述预设时段包括n个监测时刻，所述n为大于等于1的整数；

统计信息确定模块1702，用于根据每个所述请求消息对应的接口和接收时刻，确定至少一个所述接口各自对应的统计信息，所述统计信息中包括所述接口的标识、所述接口对应的至少一个监测时刻、所述接口在每个监测时刻接收到的请求消息的数量；

发送模块1703，用于向第一设备发送各所述统计信息，所述统计信息用于所述第一设备确定所述设备集群的QPS信息。

一种可能的实现方式中，所述请求消息确定模块1701，包括：

执行单元，用于执行统计操作，所述统计操作包括：在接收到请求消息之后，根据所述请求消息对应的接口确定第二目标统计信息，并根据所述请求消息的接收时刻更新所述第二目标统计信息；

从所述预设时段的起始时刻起重复执行所述统计操作，直至所述预设时段的结束时刻。

一种可能的实现方式中，所述统计信息中包括统计数组，所述统计数组中包括n个元素，所述统计数组中的第i个元素表示接口在所述预设时段的第i个监测时刻接收到的请求消息的数量，所述n为大于等于1的整数，所述i为大于等于1并且小于等于n的整数；

所述执行单元包括：

确定子单元，用于根据所述请求消息的接收时刻和所述预设时段的起始时刻，在所述第二目标统计信息的统计数组中确定目标元素；

更新子单元，用于更新所述目标元素。

一种可能的实现方式中，所述确定子单元具体用于：

确定所述请求消息的接收时刻和所述预设时段的起始时刻的差值s；

将所述第二目标统计信息的统计数组中的第s个元素确定为所述目标元素。

一种可能的实现方式中，所述更新子单元具体用于：

将当前的目标元素加上第一预设数值，得到更新后的目标元素。

一种可能的实现方式中，所述执行单元包括：

获取子单元，用于获取所述请求消息对应的接口的第一标识；

查找子单元，用于在存储的第一集合中查找所述第二目标统计信息，其中，所述第二目标统计信息的接口的标识和所述第一标识相同，所述第一集合用于存储各所述接口各自对应的统计信息；

所述获取子单元，还用于若所述第一集合中存在所述第二目标统计信息，则从所述第一集合中获取所述第二目标统计信息；或者，

创建子单元，用于若所述第一集合中不存在所述第二目标统计信息，则根据所述请求消息对应的接口，创建所述第二目标统计信息。

一种可能的实现方式中，所述统计信息还包括所述预设时段的起始时刻；

所述创建子单元具体用于：

将所述请求消息对应的接口的第一标识确定为所述第二目标统计信息的接口的标识；以及，

确定当前时刻之前最邻近的目标时刻，将所述目标时刻确定为所述第二目标统计信息的预设时段的起始时刻，其中，所述目标时刻为整点时刻或者整分时刻；以及，

根据所述预设时段所包括的监测时刻的数量创建所述第二目标统计信息的统计数组，其中，所述统计数组所包括的元素的数量和所述预设时段所包括的监测时刻的数量，所述统计数组的各个元素初始化为第二预设数值。

本公开提供一种数据处理方法及装置，应用于计算机技术中的人工智能领域，可应用于云计算或云服务场景，以达到准确有效的实现对线上集群的QPS的监控的技术效果。

根据本公开的实施例，本公开还提供了一种电子设备和一种可读存储介质。

根据本公开的实施例，本公开还提供了一种计算机程序产品，计算机程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一实施例提供的方案。

图18示出了可以用来实施本公开的实施例的示例电子设备1800的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图18所示，电子设备1800包括计算单元1801，其可以根据存储在只读存储器(ROM)1802中的计算机程序或者从存储单元1808加载到随机访问存储器(RAM)1803中的计算机程序，来执行各种适当的动作和处理。在RAM 1803中，还可存储设备1800操作所需的各种程序和数据。计算单元1801、ROM 1802以及RAM 1803通过总线1804彼此相连。输入/输出(I/O)接口1805也连接至总线1804。

设备1800中的多个部件连接至I/O接口1805，包括：输入单元1806，例如键盘、鼠标等；输出单元1807，例如各种类型的显示器、扬声器等；存储单元1808，例如磁盘、光盘等；以及通信单元1809，例如网卡、调制解调器、无线通信收发机等。通信单元1809允许设备1800通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1801可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1801的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1801执行上文所描述的各个方法和处理，例如方法数据处理方法。例如，在一些实施例中，方法数据处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1808。在一些实施例中，计算机程序的部分或者全部可以经由ROM 1802和/或通信单元1809而被载入和/或安装到设备1800上。当计算机程序加载到RAM 1803并由计算单元1801执行时，可以执行上文描述的方法数据处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元1801可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行方法数据处理方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (20)

1.一种数据处理方法，所述方法包括：

接收设备集群中各第二设备分别发送的至少一个接口各自对应的统计信息，所述统计信息中包括所述接口的标识、所述接口对应的至少一个监测时刻、所述接口在每个监测时刻接收到的请求消息的数量；所述设备集群中包括至少一个第二设备，所述第二设备用于通过至少一个接口提供服务；

根据至少一个所述接口各自对应的统计信息，确定所述设备集群的每秒请求数QPS信息；所述统计信息中包括n个元素，第i个元素表示接口在所述统计信息对应的预设时段的第i个监测时刻接收到的请求消息的数量，所述预设时段内包括n个监测时刻；所述n为大于等于1的整数，所述i为大于等于1并且小于等于n的整数；

所述统计信息中包括统计数组，所述QPS信息包括峰值QPS和峰值QPS曲线；所述根据至少一个第一目标统计信息，确定所述QPS信息，包括：

在所述至少一个第一目标统计信息中，将预设时段的起始时刻相同的第一目标统计信息确定为一组，得到多个组；

将各组中的第一目标统计信息的统计数组逐项相加，得到各组分别对应的总请求记录数组；

在各组分别对应的总请求记录数组中分别确定各组对应的最大请求数；

将所述各组对应的最大请求数中的最大值，确定为所述峰值QPS；

根据预设时间间隔将查询时段划分为至少一个子时段；

确定各所述子时段各自对应的峰值QPS；

根据各所述子时段各自对应的峰值QPS，确定所述峰值QPS曲线；

其中，所述至少一个第一目标统计信息是根据所述查询时段以及查询标识，在各所述统计信息中确定的；所述第一目标统计信息的预设时段的起始时刻在所述查询时段内。

2.根据权利要求1所述的方法，其中，所述统计信息还包括预设时段的起始时刻、接口所对应的第二设备的设备标识、以及所述第二设备所提供的服务的服务标识；所述方法还包括：

确定查询时段以及查询标识，所述查询标识包括如下中的至少一种：查询接口标识、查询设备标识、查询服务标识所述第一目标统计信息满足如下条件中的至少一种：所述第一目标统计信息的接口标识等于所述查询接口标识，所述第一目标统计信息的设备标识等于所述查询设备标识，所述第一目标统计信息的服务标识等于所述查询服务标识。

3.一种数据处理方法，所述方法包括：

确定至少一个请求消息中每个请求消息对应的接口和接收时刻，所述至少一个请求消息为在预设时段内通过各所述接口接收到的，所述预设时段包括n个监测时刻，所述n为大于等于1的整数；

根据每个所述请求消息对应的接口和接收时刻，确定至少一个所述接口各自对应的统计信息，所述统计信息中包括所述接口的标识、所述接口对应的至少一个监测时刻、所述接口在每个监测时刻接收到的请求消息的数量；

向第一设备发送各所述统计信息，所述统计信息用于所述第一设备确定设备集群的QPS信息；所述统计信息中包括n个元素，第i个元素表示接口在所述统计信息对应的预设时段的第i个监测时刻接收到的请求消息的数量，所述预设时段内包括n个监测时刻；所述n为大于等于1的整数，所述i为大于等于1并且小于等于n的整数；

所述QPS信息包括峰值QPS和峰值QPS曲线；所述统计信息中包括统计数组；用于所述第一设备确定所述设备集群的QPS信息具体包括：

用于所述第一设备在所述至少一个第一目标统计信息中，将预设时段的起始时刻相同的第一目标统计信息确定为一组，得到多个组；

将各组中的第一目标统计信息的统计数组逐项相加，得到各组分别对应的总请求记录数组；

在各组分别对应的总请求记录数组中分别确定各组对应的最大请求数；

将所述各组对应的最大请求数中的最大值，确定为所述峰值QPS；

根据预设时间间隔将查询时段划分为至少一个子时段；

确定各所述子时段各自对应的峰值QPS；

根据各所述子时段各自对应的峰值QPS，确定所述峰值QPS曲线；

其中，所述至少一个第一目标统计信息是根据所述查询时段以及查询标识，在各所述统计信息中确定的；所述第一目标统计信息的预设时段的起始时刻在所述查询时段内。

4.根据权利要求3所述的方法，其中，所述根据每个所述请求消息对应的接口和接收时刻，确定至少一个所述接口各自对应的统计信息，包括：

执行统计操作，所述统计操作包括：在接收到请求消息之后，根据所述请求消息对应的接口确定第二目标统计信息，并根据所述请求消息的接收时刻更新所述第二目标统计信息；

从所述预设时段的起始时刻起重复执行所述统计操作，直至所述预设时段的结束时刻。

5.根据权利要求4所述的方法，其中，所述统计信息中包括统计数组，所述统计数组中包括所述n个元素；所述根据所述请求消息的接收时刻更新所述第二目标统计信息，包括：

根据所述请求消息的接收时刻和所述预设时段的起始时刻，在所述第二目标统计信息的统计数组中确定目标元素；

更新所述目标元素。

6.根据权利要求5所述的方法，其中，所述根据所述请求消息的接收时刻和所述预设时段的起始时刻，在所述第二目标统计信息的统计数组中确定目标元素，包括：

确定所述请求消息的接收时刻和所述预设时段的起始时刻的差值s；

将所述第二目标统计信息的统计数组中的第s个元素确定为所述目标元素。

7.根据权利要求5所述的方法，其中，所述更新所述目标元素，包括：

将当前的目标元素加上第一预设数值，得到更新后的目标元素。

8.根据权利要求4-7任一项所述的方法，其中，所述根据所述请求消息对应的接口确定第二目标统计信息，包括：

获取所述请求消息对应的接口的第一标识；

在存储的第一集合中查找所述第二目标统计信息，其中，所述第二目标统计信息的接口的标识和所述第一标识相同，所述第一集合用于存储各所述接口各自对应的统计信息；

若所述第一集合中存在所述第二目标统计信息，则从所述第一集合中获取所述第二目标统计信息；或者，

若所述第一集合中不存在所述第二目标统计信息，则根据所述请求消息对应的接口，创建所述第二目标统计信息。

9.根据权利要求8所述的方法，其中，所述统计信息还包括所述预设时段的起始时刻；

所述根据所述请求消息对应的接口，创建所述第二目标统计信息，包括：

将所述请求消息对应的接口的第一标识确定为所述第二目标统计信息的接口的标识；以及，

确定当前时刻之前最邻近的目标时刻，将所述目标时刻确定为所述第二目标统计信息的预设时段的起始时刻，其中，所述目标时刻为整点时刻或者整分时刻；以及，

根据所述预设时段所包括的监测时刻的数量创建所述第二目标统计信息的统计数组，其中，所述统计数组所包括的元素的数量和所述预设时段所包括的监测时刻的数量，所述统计数组的各个元素初始化为第二预设数值。

10.一种数据处理装置，所述装置包括：

接收模块，用于接收设备集群中各第二设备分别发送的至少一个接口各自对应的统计信息，所述统计信息中包括所述接口的标识、所述接口对应的至少一个监测时刻、所述接口在每个监测时刻接收到的请求消息的数量；所述设备集群中包括至少一个第二设备，所述第二设备用于通过至少一个接口提供服务；

确定模块，用于根据至少一个所述接口各自对应的统计信息，确定所述设备集群的QPS信息；所述统计信息中包括n个元素，第i个元素表示接口在所述统计信息对应的预设时段的第i个监测时刻接收到的请求消息的数量，所述预设时段内包括n个监测时刻；所述n为大于等于1的整数，所述i为大于等于1并且小于等于n的整数；

述统计信息中包括统计数组，所述统计数组中包括所述n个元素；

所述QPS信息包括峰值QPS和峰值QPS曲线；

第三确定单元具体用于：

在所述至少一个第一目标统计信息中，将预设时段的起始时刻相同的第一目标统计信息确定为一组，得到多个组；

将各组中的第一目标统计信息的统计数组逐项相加，得到各组分别对应的总请求记录数组；

在各组分别对应的总请求记录数组中分别确定各组对应的最大请求数；

将所述各组对应的最大请求数中的最大值，确定为所述峰值QPS；

根据预设时间间隔将查询时段划分为至少一个子时段；

确定各所述子时段各自对应的峰值QPS；

根据各所述子时段各自对应的峰值QPS，确定所述峰值QPS曲线；

其中，所述至少一个第一目标统计信息是根据所述查询时段以及查询标识，在各所述统计信息中确定的；所述第一目标统计信息的预设时段的起始时刻在所述查询时段内。

11.根据权利要求10所述的装置，其中，所述统计信息还包括预设时段的起始时刻、接口所对应的第二设备的设备标识、以及所述第二设备所提供的服务的服务标识；

所述确定模块包括：

第一确定单元，用于确定查询时段以及查询标识，所述查询标识包括如下中的至少一种：查询接口标识、查询设备标识、查询服务标识；

所述第一目标统计信息满足如下条件中的至少一种：所述第一目标统计信息的接口标识等于所述查询接口标识，所述第一目标统计信息的设备标识等于所述查询设备标识，所述第一目标统计信息的服务标识等于所述查询服务标识。

12.一种数据处理装置，所述装置包括：

请求消息确定模块，用于确定至少一个请求消息中每个请求消息对应的接口和接收时刻，所述至少一个请求消息为在预设时段内通过各所述接口接收到的，所述预设时段包括n个监测时刻，所述n为大于等于1的整数；

统计信息确定模块，用于根据每个所述请求消息对应的接口和接收时刻，确定至少一个所述接口各自对应的统计信息，所述统计信息中包括所述接口的标识、所述接口对应的至少一个监测时刻、所述接口在每个监测时刻接收到的请求消息的数量；

发送模块，用于向第一设备发送各所述统计信息，所述统计信息用于所述第一设备确定设备集群的QPS信息；所述统计信息中包括n个元素，第i个元素表示接口在所述统计信息对应的预设时段的第i个监测时刻接收到的请求消息的数量，所述预设时段内包括n个监测时刻；所述n为大于等于1的整数，所述i为大于等于1并且小于等于n的整数；

所述QPS信息包括峰值QPS和峰值QPS曲线；所述统计信息中包括统计数组；用于所述第一设备确定所述设备集群的QPS信息具体包括：

用于所述第一设备在所述至少一个第一目标统计信息中，将预设时段的起始时刻相同的第一目标统计信息确定为一组，得到多个组；

将各组中的第一目标统计信息的统计数组逐项相加，得到各组分别对应的总请求记录数组；

在各组分别对应的总请求记录数组中分别确定各组对应的最大请求数；

将所述各组对应的最大请求数中的最大值，确定为所述峰值QPS；

根据预设时间间隔将查询时段划分为至少一个子时段；

确定各所述子时段各自对应的峰值QPS；

根据各所述子时段各自对应的峰值QPS，确定所述峰值QPS曲线；

其中，所述至少一个第一目标统计信息是根据所述查询时段以及查询标识，在各所述统计信息中确定的；所述第一目标统计信息的预设时段的起始时刻在所述查询时段内。

13.根据权利要求12所述的装置，其中，所述请求消息确定模块，包括：

执行单元，用于执行统计操作，所述统计操作包括：在接收到请求消息之后，根据所述请求消息对应的接口确定第二目标统计信息，并根据所述请求消息的接收时刻更新所述第二目标统计信息；

从所述预设时段的起始时刻起重复执行所述统计操作，直至所述预设时段的结束时刻。

14.根据权利要求13所述的装置，其中，所述统计信息中包括统计数组，所述统计数组中包括所述n个元素；

所述执行单元包括：

确定子单元，用于根据所述请求消息的接收时刻和所述预设时段的起始时刻，在所述第二目标统计信息的统计数组中确定目标元素；

更新子单元，用于更新所述目标元素。

15.根据权利要求14所述的装置，其中，所述确定子单元具体用于：

确定所述请求消息的接收时刻和所述预设时段的起始时刻的差值s；

将所述第二目标统计信息的统计数组中的第s个元素确定为所述目标元素。

16.根据权利要求14所述的装置，其中，所述更新子单元具体用于：

将当前的目标元素加上第一预设数值，得到更新后的目标元素。

17.根据权利要求13-16任一项所述的装置，其中，所述执行单元包括：

获取子单元，用于获取所述请求消息对应的接口的第一标识；

查找子单元，用于在存储的第一集合中查找所述第二目标统计信息，其中，所述第二目标统计信息的接口的标识和所述第一标识相同，所述第一集合用于存储各所述接口各自对应的统计信息；

所述获取子单元，还用于若所述第一集合中存在所述第二目标统计信息，则从所述第一集合中获取所述第二目标统计信息；或者，

创建子单元，用于若所述第一集合中不存在所述第二目标统计信息，则根据所述请求消息对应的接口，创建所述第二目标统计信息。

18.根据权利要求17所述的装置，其中，所述统计信息还包括所述预设时段的起始时刻；

所述创建子单元具体用于：

将所述请求消息对应的接口的第一标识确定为所述第二目标统计信息的接口的标识；以及，

确定当前时刻之前最邻近的目标时刻，将所述目标时刻确定为所述第二目标统计信息的预设时段的起始时刻，其中，所述目标时刻为整点时刻或者整分时刻；以及，

根据所述预设时段所包括的监测时刻的数量创建所述第二目标统计信息的统计数组，其中，所述统计数组所包括的元素的数量和所述预设时段所包括的监测时刻的数量，所述统计数组的各个元素初始化为第二预设数值。

19.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-2或权利要求3-9中任一项所述的方法。

20.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行权利要求1-2或权利要求3-9中任一项所述的方法。

Images