一种数据检查方法及系统

技术领域

本申请涉及数据监控技术领域，更具体地说，涉及一种数据检查方法及系统。

背景技术

监控系统作为运维的基础，是每个系统都应配备的。一个良好的监控系统能够快速发现系统故障、准确定位系统问题，减轻运维人员的压力。如何确保监控系统自身的稳定运行，保证监控的不中断也尤为重要。

现有的监控系统一般会通过给指标设置超时未上报功能，来解决指标数据中断的问题，即当指标数据超过某个时间阈值不上报数据时，会触发相应的告警。

但是，如果该功能只对部分指标开启，那么无法保证全量资源、全量指标等的监控一致性和连续性。如果该功能对所有资源所有指标开启，一旦监控系统后台服务端或者网络出现故障，就会导致告警风暴，所有资源的所有指标都会告警，这将对运维人员产生极大困扰。

因此，如何在监控系统的运行过程中，实现全量资源、全量指标的监控一致性和连续性，确保监控系统自身的稳定运行和数据监控的不中断，是本申请亟需解决的问题。

发明内容

有鉴于此，本申请公开了一种数据检查方法及系统，旨在监控系统的运行过程中，确保数据一致性和所有数据的连续性，在实现监控系统自身的稳定运行和对数据进行实时监控而不中断。

为了实现上述目的，其公开的技术方案如下：

本申请第一方面公开了一种数据检查方法，所述方法应用于检查装置，所述方法包括：

当接收到检查指令时，将所述检查指令发送至采集代理设备，使所述采集代理设备获取检查指令中的待检查数据；

通过预先配置的定时检查策略，使所述采集代理设备对所述待检查数据进行检查，得到检查结果；所述定时检查策略至少包括检查时间段、检查周期、过滤条件和单次检查资源数量；所述定时检查策略为确保数据的一致性和连续性的检查策略。

优选的，所述当接收到检查指令时，将所述检查指令发送至采集代理设备，使所述采集代理设备获取检查指令中的待检查数据，包括：

当接收到检查指令时，将所述检查指令发送至采集代理设备，使所述采集代理设备解析所述检查指令，得到检查指令中的待检查数据。

优选的，所述通过预先配置的定时检查策略，使所述采集代理设备对所述待检查数据进行检查，得到检查结果，包括：

使所述采集代理设备对所述待检查数据进行时间段检查、周期检查、过滤条件检查和单次资源数量检查，得到检查结果；

若所述检查结果表示所述待检查数据中的所有指标在预设检查周期内均被采集到，且采集次数符合预设次数，确定所述检查结果为符合一致性且连续性的检查结果；

若所述检查结果表示所述待检查数据的所有指标中，若存在任意一个指标在预设检查周期内未被采集到，且存在任意一个指标的采集次数不符合预设次数，确定所述检查结果为不符合一致性且不符合连续性的检查结果。

优选的，在所述通过预先配置的定时检查策略，使所述采集代理设备对所述待检查数据进行检查，得到检查结果之后，还包括：

通过消费kafka数据，生成所述检查结果对应的检查报告，并将所述检查报告存储至数据库中。

本申请第二方面公开了一种数据检查方法，所述方法应用于采集代理设备，所述方法包括：

当接收到检查装置发送的检查指令时，获取检查指令中的待检查数据；

通过预先配置的定时检查策略，对所述待检查数据进行检查，得到检查结果；所述定时检查策略至少包括检查时间段、检查周期、过滤条件和单次检查资源数量；所述定时检查策略为确保数据的一致性和连续性的检查策略。

优选的，所述当接收到检查装置发送的检查指令时，获取所述检查指令的待检查数据，包括：

当接收到检查装置发送的检查指令时，解析所述检查指令，得到检查资源的待检查数据。

优选的，所述通过预先配置的定时检查策略，对所述待检查数据进行检查，得到检查结果，包括：

对所述待检查数据进行时间段检查、周期检查、过滤条件检查和单次资源数量检查，得到检查结果；

若所述检查结果表示所述待检查数据中的所有指标在预设检查周期内均被采集到，且采集次数符合预设次数，确定所述检查结果为符合一致性且连续性的检查结果；

若所述检查结果表示所述待检查数据的所有指标中，若存在任意一个指标在预设检查周期内未被采集到，且存在任意一个指标的采集次数不符合预设次数，确定所述检查结果为不符合一致性且不符合连续性的检查结果。

本申请第三方面公开了一种数据检查系统，所述系统应用于检查装置，所述系统包括：

发送选取单元，用于当接收到检查指令时，将所述检查指令发送至采集代理设备，使所述采集代理设备获取检查指令中的待检查数据；

第一检查单元，用于通过预先配置的定时检查策略，使所述采集代理设备对所述待检查数据进行检查，得到检查结果；所述定时检查策略至少包括检查时间段、检查周期、过滤条件和单次检查资源数量；所述定时检查策略为确保数据的一致性和连续性的检查策略。

优选的，所述发送选取单元，具体用于：

当接收到检查指令时，将所述检查指令发送至采集代理设备，使所述采集代理设备解析所述检查指令，得到检查指令中的待检查数据。

本申请第四方面公开了一种数据检查系统，所述系统应用于采集代理设备，所述方法包括：

获取单元，用于当接收到检查装置发送的检查指令时，获取检查指令中的待检查数据；

第二检查单元，用于通过预先配置的定时检查策略，对所述待检查数据进行检查，得到检查结果；所述定时检查策略至少包括检查时间段、检查周期、过滤条件和单次检查资源数量；所述定时检查策略为确保数据的一致性和连续性的检查策略。

经由上述技术方案可知，本申请公开了一种数据检查方法及系统，当检查装置接收到检查指令时，检查装置将检查指令发送至采集代理设备，使采集代理设备获取检查指令的待检查数据，通过预先配置的定时检查策略，使所述采集代理设备对所述待检查数据进行检查，得到检查结果，定时检查策略至少包括检查时间段、检查周期、过滤条件和单次检查资源数量，定时检查策略为确保数据的一致性和连续性的检查策略。通过上述方案，在监控系统的运行过程中，通过定时检查策略保证采集代理设备上执行的采集配置信息，如采集指标、采集周期等与实际的采集配置信息一致，来确保数据一致性，通过定时检查策略中的过滤条件和单次检查资源数量，使得能够遍历所有资源的所有指标，确保所有数据的连续性，实现监控系统自身的稳定运行和对数据进行实时监控，而保持数据监控的不中断。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例公开的一种数据检查方法的交互示意图；

图2为本申请实施例公开的一种数据检查方法的流程示意图；

图3为本申请实施例公开的数据检查的示意图；

图4为本申请实施例公开的另一种数据检查方法的流程示意图；

图5为本申请实施例公开的一种数据检查系统的结构示意图；

图6为本申请实施例公开的一种数据检查系统的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

由背景技术可知，现有的监控系统一般会通过给指标设置超时未上报功能，来解决指标数据中断的问题，即当指标数据超过某个时间阈值不上报数据时，会触发相应的告警。但是，如果该功能只对部分指标开启，那么无法保证全量资源、全量指标等的监控一致性和连续性。如果该功能对所有资源所有指标开启，一旦监控系统后台服务端或者网络出现故障，就会导致告警风暴，所有资源的所有指标都会告警，这将对运维人员产生极大困扰。因此，如何在监控系统的运行过程中，实现全量资源、全量指标的监控一致性和连续性，确保监控系统自身的稳定运行和数据监控的不中断，是本申请亟需解决的问题。

为了解决上述问题，本申请公开了一种数据检查方法及系统，在监控系统的运行过程中，通过定时检查策略保证采集代理设备上执行的采集配置信息，如采集指标、采集周期等与实际的采集配置信息一致，来确保数据一致性，通过定时检查策略中的过滤条件和单次检查资源数量，使得能够遍历所有资源的所有指标，确保所有数据的连续性，实现监控系统自身的稳定运行和对数据进行实时监控，而保持数据监控的不中断。具体实现方式通过下述实施例进行说明。

参考图1所示，为本申请实施例公开的一种数据检查方法的交互示意图，该交互示意图应用于检查装置和采集代理装置，采集代理装置的数量可以为多个，该数据检查方法主要包括如下步骤：

S101：当检查装置接收到检查指令时，检查装置将检查指令发送至采集代理设备。

检查指令包含检查周期、各资源的采集配置信息等。各资源的采集配置信息如资源的采集指标、资源的采集周期等。

S102：采集代理设备解析检查指令，得到获取检查指令中的待检查数据。

采集代理设备接收到检查指令后，在每次给监控系统发送指标数据前，选取检查指令中的待检查数据并记录，直到检查周期结束后形成检查结果。

其中，检查指令的待检查数据是指在检查指令中的资源的采集指标。比如，检查指令中的采集指标为CPU使用率，获取检查指令的待检查数据为CPU使用率。

S103：采集代理设备通过预先配置的定时检查策略，使所述采集代理设备对所述待检查数据进行检查，得到检查结果；定时检查策略至少包括检查时间段、检查周期、过滤条件和单次检查资源数量，定时检查策略为确保数据的一致性和连续性的检查策略。

定时检查策略通过运维平台进行配置。定时检查策略包括检查时间段、检查周期、过滤条件、单次检查资源数量等。具体定时检查策略的详细描述见表1。

表1

具体检查时间段可以是6:00-6:30，也可以是15:20-16:00等，具体检查时间段根据实际情况进行设置，本申请不做具体限定。

检查周期可以是每间隔1分钟，也可以是每间隔1小时等，具体检查周期根据实际情况进行设置，本申请不做具体限定。

比如，设置过滤条件为CPU使用率为不需检查的资源。

为便于描述，将单次检查资源数量设置为N，N的取值为大于等于1的整数，开启定时检查策略后，检查任务下发到监控数据一致性和连续性的检查装置，检查装置从数据库(mysql)随机取出N条未检查过的资源的采集配置信息。其中，为保证监控数据一致性和连续性检查的时效性，在本方案中设定一个月内完成所有资源的检查，因此mysql中保留一个月内资源的检查结果。在每次检查时，检查装置根据mysql中保留的检查结果取出N条未检查过的资源的采集配置信息。如果mysql中不存在未检查过的资源，则当天不执行检查任务。检查装置的时效性可根据不同系统的需求配置不同的检查结果保留时间。

具体检查结果如表2所示。

表2

表2中，采集配置信息里面所有指标的采集次数都达到预设次数就符合连续性。

预设次数可以是1次，也可以是2次等，具体预设次数根据实际情况进行设置，本申请不做具体限定。

为了方便理解生成检查结果的过程，这里举例进行说明：

例如，假设N是300，资源名称分别是N1、N2、N3……N300，检查周期是30分钟。那么每个资源会收到检查指令，其中每个资源的采集配置信息包含该资源应采集的指标和指标对应的采集周期。在检查周期30分钟内，各资源记录所有应采集指标被采集的次数。

假设资源N1的采集配置信息为：一分钟采集一次磁盘使用率，一分钟采集一次CPU使用率，一分钟采集一次内存使用率，三分钟采集一次dns服务状态，五分钟采集一次可用内存。那么当上述五个指标在检查周期内都至少被采集到一次，则一致性为true，否则为false。当为false时，未被采集到的指标组成不一致指标集。对于“磁盘使用率”、“CPU使用率”、“内存使用率”，标准次数为30次。对于“dns服务状态”标准次数为10次。对于“可用内存”标准次数为6次。即当“磁盘使用率”、“CPU使用率”、“内存使用率”的采集次数分别等于29或30或31时，则此三个指标符合预设次数。当“dns服务状态”指标的采集次数等于9或10或11时，则该指标符合连预设次数。当“可用内存”指标的采集次数等于5或6或7时，则该指标符合预设次数。当所有的采集指标都符合预设次数时连续性为true，否则为false。当为false时，不连续的指标组成不连续指标集。

S104：检查装置通过消费kafka数据，生成检查结果对应的检查报告。

在S104中，检查装置通过消费kafka数据，根据检查结果生成检查报告。检查报告包括资源名称、一致性、一致性指标集、连续性、连续性指标集。

S105：检查装置将检查报告存储至数据库(mysql)中。

本方案有效保证了监控数据的正确采集以及监控业务的不中断。在确保监控数据一致性方面，本发明能保证采集代理上执行的采集配置信息(采集脚本、采集指标、采集周期等)与实际的采集配置信息一致。在确保监控数据连续性方面，本方案能够遍历所有资源的所有指标，确保所有数据的连续性。

本方案从保证监控数据一致性和连续性的角度出发，在确保采集的监控数据与实际配置一致的前提下，能够同时检查监控数据采集的连续性。

本申请实施例中，通过定时检查策略保证采集代理设备上执行的采集配置信息，如采集指标、采集周期等与实际的采集配置信息一致，来确保数据一致性，通过定时检查策略中的过滤条件和单次检查资源数量，使得能够遍历所有资源的所有指标，确保所有数据的连续性，实现监控系统自身的稳定运行和对数据进行实时监控，而保持数据监控的不中断。

参考图2所述，为本申请实施例公开的一种数据检查方法，该数据检查方法应用于上述实施例图1中的检查装置，该数据检查方法主要包括如下步骤：

S201：当检查装置接收到检查指令时，检查装置将检查指令发送至采集代理设备，使采集代理设备获取检查指令中的待检查数据。

检查指令包含检查周期、各资源的采集配置信息等。各资源的采集配置信息如资源的采集指标、资源的采集周期等。

具体的，当接收到检查指令时，将检查指令发送至采集代理设备，使采集代理设备解析检查指令，得到检查指令的待检查数据。

其中，检查指令的待检查数据是指在检查指令中的资源的采集指标。比如，检查指令中的采集指标为CPU使用率，获取检查指令的待检查数据为CPU使用率。

比如，检查指令中的采集指标为内存使用率，使采集代理装置解析检查指令，得到待检查资源的采集指标为内存使用率的采集指标。

根据每个资源各自的采集配置信息，确定该资源应该采集的指标。根据上述定义的检查指令包含检查周期、各资源的采集配置信息等，各个资源按照各自的采集配置信息确定采集指标。

S202：检查装置通过预先配置的定时检查策略，使采集代理设备对待检查数据进行检查，得到检查结果；定时检查策略至少包括检查时间段、检查周期、过滤条件和单次检查资源数量；定时检查策略为确保数据的一致性和连续性的检查策略。

具体检查装置通过预先配置的定时检查策略，使采集代理设备对待检查数据进行检查，得到检查结果过程如A1-A3所示。

A1：检查装置使采集代理设备对待检查数据进行时间段检查、周期检查、过滤条件检查和单次资源数量检查，得到检查结果。

A2：若检查结果表示待检查数据中的所有指标在预设检查周期内均被采集到，且采集次数符合预设次数，确定检查结果为符合一致性且连续性的检查结果。

预设次数只要等于标准次数-1、标准次数、标准次数+1其中的一个即可。标准次数的确定本申请不做具体限定。比如，标准次数为5，预设次数为4、5、6中的一个均可。

其中，只要采集次数等于这三个数值(标准次数-1、标准次数、标准次数+1)中的一个都符合要求。

其次，采集配置信息中所有的指标在检查周期内都至少采集到一次，则值为true；否则为false。检查指标CPU使用率、内存使用率和磁盘使用率等指标只要采集到一次即为满足一致性。当CPU使用率、内存使用率和磁盘使用率等指标中只要有一个指标的采集次数不符合预设次数时是不满足连续性。

采集次数符合预设次数即为满足连续性。

比如，待检查数据包括CPU使用率、内存使用率和磁盘使用率，检查周期为30分钟，在30分钟内CPU使用率、内存使用率和磁盘使用率均被采集到1次，确定检查结果符合一致性。标准次数为5次，预设次数为4次，5次，6次，若采集次数为4次，5次，或6次，确定检查结果为连续性的检查结果。

A3：若检查结果表示待检查数据的所有指标中，若存在任意一个指标在预设检查周期内未被采集到，且存在任意一个指标的采集次数不符合预设次数，确定检查结果为不符合一致性且不符合连续性的检查结果。

需要说明的是，只要采集次数等于这三个数值(标准次数-1、标准次数、标准次数+1)中的一个都符合要求。其次，当检查周期内检查指标CPU使用率、内存使用率和磁盘使用率都被采集到时是满足一致性的，CPU使用率、内存使用率和磁盘使用率中只要有一个指标的采集次数不符合预设次数时是不满足连续性。

检查装置通过消费kafka数据，生成检查结果对应的检查报告，并将检查报告存储至mysql中。

为了方便理解数据检查方法，此处结合图3进行举例说明。图3示出了数据检查的示意图。

例如，运维平台配置定时检查策略(配置检查时间段、检查周期、过滤条件和单次检查资源数量)，定时检查任务启动，运维平台将定时检查策略发送至检查装置；检查装置将检查指令发送至采集代理装置(agent)；采集代理装置通过定时检查策略，对待检查数据进行检查，得到检查结果，并将检查结果发送至检查装置中的kafka，检查装置将检查结果发送至数据库mysql进行保存；检查装置向数据库mysql查询采集配置信息(如资源的采集指标、采集周期等)。检查装置通过消费kafka数据，生成检查结果对应的检查报告，

本申请实施例中，通过定时检查策略保证采集代理设备上执行的采集配置信息，如采集指标、采集周期等与实际的采集配置信息一致，来确保数据一致性，通过定时检查策略中的过滤条件和单次检查资源数量，使得能够遍历所有资源的所有指标，确保所有数据的连续性，实现监控系统自身的稳定运行和对数据进行实时监控，而保持数据监控的不中断。

参考图4所示，为本申请实施例公开的另一种数据检查方法，该数据检查方法应用于上述实施例图1公开的采集代理设备，该数据检查方法主要包括如下步骤：

S401：当采集代理设备接收到检查装置发送的检查指令时，获取检查指令中的待检查数据。

在S401中，当采集代理设备接收到检查装置发送的检查指令时，采集代理设备解析检查指令，得到待检查数据。

其中，检查指令包含检查周期、各资源的采集配置信息等。各资源的采集配置信息如资源的采集指标、资源的采集周期等。

检查指令的待检查数据是指在检查指令中的资源的采集指标。比如，检查指令中的采集指标为CPU使用率，获取检查指令的待检查数据为CPU使用率。

S402：采集代理设备通过预先配置的定时检查策略，对待检查数据进行检查，得到检查结果；定时检查策略至少包括检查时间段、检查周期、过滤条件和单次检查资源数量；定时检查策略为确保数据的一致性和连续性的检查策略。

具体采集代理设备通过预先配置的定时检查策略，对待检查数据进行检查，得到检查结果的过程如B1-B3所示。

B1：对待检查数据进行时间段检查、周期检查、过滤条件检查和单次资源数量检查，得到检查结果。

B2：若检查结果表示待检查数据中的所有指标在预设检查周期内均被采集到，且采集次数符合预设次数，确定检查结果为符合一致性且连续性的检查结果。

B3：若检查结果表示待检查数据的所有指标中，若存在任意一个指标在预设检查周期内未被采集到，且存在任意一个指标的采集次数不符合预设次数，确定检查结果为不符合一致性且不符合连续性的检查结果。

B1-B3的执行过程和执行原理，与上述A1-A3的执行过程和执行原理一致，可参考，此处不再进行赘述。

本申请实施例中，通过定时检查策略保证采集代理设备上执行的采集配置信息，如采集指标、采集周期等与实际的采集配置信息一致，来确保数据一致性，通过定时检查策略中的过滤条件和单次检查资源数量，使得能够遍历所有资源的所有指标，确保所有数据的连续性，实现监控系统自身的稳定运行和对数据进行实时监控，而保持数据监控的不中断。

基于上述实施例图2公开的一种数据检查方法，本申请实施例还对应公开了一种数据检查系统，如图5所示，该数据检查系统应用于检查装置，该数据检查系统包括发送获取单元501和第一检查单元502。

发送获取单元501，用于当检查装置接收到检查指令时，将检查指令发送至采集代理设备，使采集代理设备获取检查指令中的待检查数据。

第一检查单元502，用于检查装置通过预先配置的定时检查策略，使所述采集代理设备对待检查数据进行检查，得到检查结果；定时检查策略至少包括检查时间段、检查周期、过滤条件和单次检查资源数量；定时检查策略为确保数据的一致性和连续性的检查策略。

进一步的，发送获取单元501，具体用于当检查装置接收到检查指令时，将检查指令发送至采集代理设备，使采集代理设备解析检查指令，得到检查指令中的待检查数据。

进一步的，第一检查单元502，包括第一检查模块、第一确定模块和第二确定模块。

第一检查模块，用于检查装置使采集代理设备对待检查数据进行时间段检查、周期检查、过滤条件检查和单次资源数量检查，得到检查结果。

第一确定模块，用于若检查结果表示待检查数据中的所有指标在预设检查周期内均被采集到，且采集次数符合预设次数，检查装置确定检查结果为符合一致性且连续性的检查结果。

第二确定模块，用于若检查结果表示所述待检查数据的所有指标中，若存在任意一个指标在预设检查周期内未被采集到，且存在任意一个指标的采集次数不符合预设次数，检查装置确定检查结果为不符合一致性且不符合连续性的检查结果。

进一步的，数据检查系统还包括生成单元。

生成单元，用于检查装置通过消费kafka数据，生成检查结果对应的检查报告，并将所述检查报告存储至数据库中。

本申请实施例中，通过定时检查策略保证采集代理设备上执行的采集配置信息，如采集指标、采集周期等与实际的采集配置信息一致，来确保数据一致性，通过定时检查策略中的过滤条件和单次检查资源数量，使得能够遍历所有资源的所有指标，确保所有数据的连续性，实现监控系统自身的稳定运行和对数据进行实时监控，而保持数据监控的不中断。

基于上述实施例图4公开的另一种数据检查方法，本申请实施例还对应公开了另一种数据检查系统，如图6所示，该另一种数据检查系统应用于采集代理设备，该数据检查系统包括获取单元601和第二检查单元602。

获取单元601，用于当接收到检查装置发送的检查指令时，获取检查指令中的待检查数据。

第二检查单元602，用于通过预先配置的定时检查策略，对待检查数据进行检查，得到检查结果；定时检查策略至少包括检查时间段、检查周期、过滤条件和单次检查资源数量；定时检查策略为确保数据的一致性和连续性的检查策略。

进一步的，选取单元601具体用于当接收到检查装置发送的检查指令时，解析检查指令，得到检查资源的待检查数据。

进一步的，第二检查单元602包括：检查模块、第三确定模块和第四确定模块。

检查模块，用于对待检查数据进行时间段检查、周期检查、过滤条件检查和单次资源数量检查，得到检查结果。

第三确定模块，用于若检查结果表示待检查数据中的所有指标在预设检查周期内均被采集到，且采集次数符合预设次数，确定检查结果为符合一致性且连续性的检查结果。

第四确定模块，用于若检查结果表示所述待检查数据的所有指标中，若存在任意一个指标在预设检查周期内未被采集到，且存在任意一个指标的采集次数不符合预设次数，确定检查结果为不符合一致性且不符合连续性的检查结果。

本申请实施例中，通过定时检查策略保证采集代理设备上执行的采集配置信息，如采集指标、采集周期等与实际的采集配置信息一致，来确保数据一致性，通过定时检查策略中的过滤条件和单次检查资源数量，使得能够遍历所有资源的所有指标，确保所有数据的连续性，实现监控系统自身的稳定运行和对数据进行实时监控，而保持数据监控的不中断。

上述各个实施例的具体实施过程及其衍生方式，均在本申请的保护范围之内。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为聚类部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。