一种基于自适应约束条件的网络数据获取系统及方法与流程

1.本发明涉及计算机领域，特别是涉及一种基于自适应约束条件的网络数据获取系统。


背景技术：

2.网络数据具有规模庞大且易于获取的特性，所以它一直是统计分析、数据挖掘、模型训练的重要数据来源之一，而其来源主要是响应请求的服务器类网络数据源。出于对自身安全性的考虑，多数的数据源服务器都具有对访问数据的用户进行监测、记录和对用户实行管控约束的能力，这类管控约束的主要行为是针对某用户访问量过大或过快造成的资源过度占用进行限制，使用户在某段时间内无法正常获取数据，从而防止可能造成的服务器崩溃或其它恶意行为，多数数据源的实现的方式是向请求数据的获取方发送警告性的提示信息并限制获取程序以达到防范获取方潜在的恶意行为。
3.而多数情况下，网络数据获取任务的主要目标是效率尽可能高地获取大批量的网络数据，这往往会受到数据源对获取的约束。因此，根据数据源的约束进行相应的调整，并能够达到高效获取批量数据的方法具有很高的实现价值。对比与一般的数据获取，具备探测分析、自主适应能力具有独特的优势。本发明参考如今常用的一类具有如上性质的数据源，以适应数据源的获取约束为主要目的，设计了针对不同类型的约束条件做出自适应调整的网络数据获取系统，为网络数据的高效获取提供了一种可行性强的方案。


技术实现要素：

4.本发明为了解决在大批量获取网络数据时受到数据源约束，无法高效获取数据的技术问题，提供一种在数据源管控约束下仍能对数据进行高效获取，满足获取任务，能够获取大数据量、高效率、高成功率网络数据的基于自适应约束条件的网络数据获取系统及方法。
5.本发明提供一种基于自适应约束条件的网络数据获取系统，设有用户输入模块、预处理模块、任务分发模块、消息传递模块、数据存储模块、数据获取模块、数据分析模块和数据处理模块，用户输入模块与预处理模块连接，预处理模块与任务分发模块连接，任务分发模块分别与消息传递模块和数据存储模块连接，数据获取模块、数据分析模块和数据处理模块还分别与消息传递模块和数据存储模块连接；
6.用户输入模块，用于接收用户发送的数据并传入整个系统；
7.预处理模块，对用户指定的输入数据，包括数据源、初始任务数据、处理方式做基本的处理；
8.任务分发模块，是系统中的一个任务分发节点，负责最基本、最重要的数据获取任务的生成调优，以及在整个系统中对不同功能的节点进行任务的调度、指导、分配和节点运行任务情况的监测；
9.消息传递模块，是系统中多个负责传递消息的消息队列节点，负责传递节点的信
息以及任务的信息，通过不同功能和类型的消息队列和不同节点之间的联系，将任务稳定快速地分配到节点并协调工作；
10.数据存储模块，对应系统中多个不同类型的数据库，负责存储整个系统中需要在节点间传递的必要数据，保证了整个系统数据上的协调和正确；
11.数据获取模块，对应系统中的多种类型不同、数量较多的数据获取节点，负责按照对应的数据获取任务的要求进行对应任务数据的批量高效的获取；
12.数据分析模块，对应系统中多个具有计算处理能力的数据分析节点，负责对数据获取任务中获取的结果进行分析，并从中提取出数据源的获取约束条件，从而反馈给任务分发节点，作为生成高效数据获取任务的重要依据；
13.数据处理模块，对应系统中多个具有数据处理能力的数据处理节点，负责将获取到的原始数据以用户给定的模式处理，使其成为符合用户需求的数据。
14.本发明还提供一种基于自适应约束条件的网络数据获取方法，包括以下步骤：
15.步骤一、系统的部署和设置：对各台主机做基本的运行条件配置，进行数据获取模块、数据处理模块、数据分析模块、消息传输模块、数据存储模块的部署，并保证各模块正常工作，其中需要对具体的数据获取节点、数据处理节点、数据分析节点生成对应的id号作为标记，并在数据库中节点信息表来存入节点的编号和相关属性；
16.步骤二、数据获取：用户把将要放入系统进行获取的数据以及指定的数据源的信息输入到系统中，任务分发节点根据数据库中数据获取节点的信息结合已经探测到的数据源的约束条件将获取任务进行构造，并将具体的任务传送到对应的消息队列中进行处理；
17.步骤三、数据分析：任务分发节点收到数据获取任务完成的消息之后，将任务发送给空闲的数据分析节点，数据分析节点将获取到的结果进行数据的分析、约束条件的生成，并将完成消息返回给任务分发节点，任务分发节点进行对应信息的更新存储，并根据任务的状态决定是否将任务消息发送到数据处理节点，数据处理节点一旦接收到了任务，便更改任务状态并执行任务，最后将处理好的数据进行存储；
18.步骤四、数据处理：任务分发节点收到数据分析任务完成的消息之后，将任务发送给空闲的数据处理节点，数据处理节点将获取到的结果进行数据的处理、将原任务数据集合改变使得任务分发节点重新加载该任务、存入数据库，并将完成消息返回给任务分发节点，任务分发节点进行对应任务信息的更新存储。
19.优选地，步骤一到步骤四还包括系统内部的反馈处理，反馈处理包括节点连通性的反馈处理、节点任务程序执行情况的反馈处理和失败任务的反馈处理。
20.优选地，步骤一中数据库需要建立的表或集合包括：
21.(1)节点信息表，主要用来查看节点的信息，存储于nosql数据库中；
22.(2)约束条件集合；
23.(3)任务集合；
24.(4)任务数据集合；
25.(5)处理方法集合；
26.(6)最终结果集合。
27.优选地，步骤二的具体步骤包括：
28.步骤21，预处理模块对应的节点在数据流入后对用户提供的数据进行处理，包括
数据分类和确定处理方式；
29.步骤22，任务分发节点收到数据获取的请求，从数据库中获取一个获取任务必要的信息，开始建立任务或对任务进行分发；
30.步骤23，空闲的数据获取节点通过监听自己的消息队列，取到由任务分发节点发出的任务的消息，根据任务方法的具体要求，配置并执行该获取任务，将结果进行反馈。
31.优选地，步骤三的具体步骤包括：
32.步骤31，任务分发节点不断监听回复消息队列，接收到其中获取节点任务完成的消息，判断返回消息的节点的状态，若为“故障”，则将任务对应状态改为“失败”，不再向下进行；并对应的将任务进行发送到分析节点的消息队列中；
33.步骤32，所有空闲的分析节点不断监听该消息队列，在遇到任务消息时由唯一的一个节点将任务获取，并开始执行分析过程。
34.优选地，步骤四的具体步骤包括：
35.步骤41，任务分发节点不断监听回复消息队列，接收到其中分析节点任务完成的消息，判断返回消息节点的状态，若为“故障”，则将任务对应状态改为“失败”，不向下进行；否则在任务数据库中查找对应分析节点任务的结果，如果对应任务的状态为“需要处理”，则将任务进行发送到处理节点的消息队列中；
36.步骤42，所有空闲的处理节点不断监听该消息队列，在遇到任务消息时由唯一的一个节点将任务获取，并开始将获取到的数据按照用户指定的方式进行处理并获得最终结果。
37.本发明的有益效果是：
38.本发明利用分布式系统针对某个特定网络数据源进行大规模数据获取，系统内部的各类主机节点除了实现获取数据的基本要求外，还对获取到的数据进行相应的分析，当发现了数据源发来的限制约束信息时，及时调整获取数据的方法，通过系统中各部分的协调完成系统获取数据的自适应调整，从而完成获取能力的快速调优进而保证获取数据的质量和效率。此外，本发明针对在网络数据获取中可能出现的几种主要的数据源限制约束进行了归纳举证，并分别利用对应的方法进行了具体的分析判别，相对于数据规模、数据处理成本、节点处理能力要求更高的机器学习、深度学习方法，该发明提到的方法有效的平衡了分析准确率、分析复杂度、分析效率等问题，也保证了对于不同约束处理方法的完整性，可解释性也优于深度学习方法。另外，该发明的适用范围广泛，对于多种不同的网络数据类型可以进行具体对应类型的处理，甚至可以针对不同数据类型进行组合获取，体现出该发明的应用价值和应用广度。
附图说明
39.图1是本发明系统主要功能流程图；
40.图2是本发明系统整体的结构功能模块的详细示意图。
41.附图符号说明：
42.1.用户输入模块：用于接收用户发送的数据并传入整个系统；
43.2.预处理模块：该模块主要对于用户指定的输入数据，包括数据源、初始任务数据(例如域名)、处理方式做基本的处理，对应功能包括初始数据的分类，处理方式的存储等；
44.3.任务分发模块：对应的是系统中的一个任务分发节点，主要负责最基本、最重要的数据获取任务的生成调优，以及在整个系统中对不同功能的节点进行任务的调度、指导、分配和节点运行任务情况的监测。对应的功能包括数据获取任务的创建、对处于不同状态的任务进行对应类型节点的分发和调配、监测各节点的连通性和任务执行情况、对执行失败的任务进行处理回收等；
45.4.消息传递部分：对应系统中多个负责传递消息的消息队列节点，主要负责传递节点的信息以及任务的信息，通过不同功能和类型的消息队列和不同节点之间的联系，任务可以稳定快速地分配到节点并协调工作；
46.5.数据存储部分：对应系统中多个不同类型的数据库几点，主要负责存储整个系统中需要在节点间传递的必要数据，保证了整个系统数据上的协调和正确；
47.6.数据获取模块：对应系统中的多种类型不同、数量较多的数据获取节点，主要负责按照对应的数据获取任务的要求进行对应任务数据的批量高效的获取；由于对应获取的数据类型的不同，以及数据获取时网络情况和数据源的状态可能影响到任务的执行，因此在执行对应的数据获取任务时，为了保证获取到原始数据的鲁棒性，获取时包含必要的辅助功能以及连通性监测；该模块对应的功能包括正确合理地像数据源获取原始数据，以及改变对应任务状态和通知任务分发节点等；
48.7.数据分析模块：对应系统中多个具有计算处理能力的数据分析节点，主要负责对数据获取任务中获取的结果进行分析，并从中提取出数据源的获取约束条件，从而反馈给任务分发节点，作为生成高效数据获取任务的重要依据。对于获取到的数据中潜在的约束条件，采用多种方法进行定性定量的分析，并最终构造出可信度较高的约束条件。该模块对应的功能包括分析获取到的原始数据并生成定性定量的约束条件，以及改变对应任务状态和通知任务分发节点等；
49.8.数据处理模块：对应系统中多个具有数据处理能力的数据处理节点，主要负责将获取到的原始数据以用户给定的模式处理，使其成为符合用户需求的数据；由于无法保证每次数据获取的成功率高低，有时需要将获取数据中不满足条件的数据进行重新获取，因此模块具备了对非成功获取的条目进行返回重新获取的功能；该模块对应的功能包括以用户指定的方式处理获取到的原始数据并生成符合条件的最终结果，以及改变对应任务状态和通知任务分发节点等。
具体实施方式
50.下面结合附图和实施例对本发明做进一步说明，以使本发明所属技术领域的技术人员能够容易实施本发明。
51.实施例：
52.一、系统的部署和设置
53.在本实施例中，对各台主机做基本的运行条件配置，按照图2所示进行数据获取模块、数据处理模块、数据分析模块、消息传输部分、数据存储部分的部署，并保证各模块可以正常工作，其中需要对具体的数据获取节点、数据处理节点、数据分析节点生成对应的id号作为标记，并在数据库中节点信息表来存入节点的编号和相关属性。
54.数据存储方面，其中的数据库需要建立以下表或集合：
55.(1)节点信息表，主要用来查看节点的信息，存储于nosql数据库中，具体的属性包括：
56.1)节点id，主键，主要对应以上提到的三种类型的节点，数据获取节点g
×××
，数据处理节点p
×××
，数据分析节点a
×××
；
57.2)节点基本信息，主要包括ip地址，设备信息等节点的唯一性信息；
58.3)节点状态，主要包括以下几种状态：
59.1忙碌：节点正在执行任务；
60.2空闲：节点处于无任务执行的空闲状态；
61.3睡眠：主要针对数据获取节点被调度成休眠状态的情况；
62.4故障：出现各种未知错误的节点，该状态一旦出现，需要维护人员手动回复状态；
63.4)当前节点执行的任务；
64.5)时间戳，主要再改变状态时改变。
65.(2)约束条件集合，其中的每个约束条件文件中的字段构成为：
66.1)约束id；
67.2)对应的数据源；
68.3)约束条件的种类，对应该种类类条件的具体信息如频率、限额、黑名单等等；
69.4)具体内容；
70.5)时间戳；
71.6)过期时间；
72.7)具体内容，不同类型对应的类型不同，具体情况如下：
73.1)频率类：具体的频率；
74.2)限额类：限额的数量，停止获取的时间；
75.3)黑名单类：具体的节点信息，如ip、设备名等；
76.8)收敛计数：主要对于频率类型和限额类型的约束，该字段体现了某一约束条件测量的准确性，存在相同的约束测出差距较大的结果时，具体再选择时，选择收敛计数更大的那个作为可靠的约束条件进行获取任务的构造。
77.(3)任务集合，其中每个任务文件中字段的构成为：
78.1)任务id(主键)；
79.2)对应节点的id，每个任务每个阶段只可以交给一台对应的主机；
80.3)网络数据源；
81.4)任务当前状态，主要包含以下几种：
82.1、完成，数据的具体信息已经按照用户指定的提取模式存入了数据库中；
83.2、未开始，当前任务还没有被正式分配到具体的任务中；
84.3、正在获取，任务发送到了获取节点，并正在获取原始数据；
85.4、需要分析，获取节点执行完了的状态，分析节点将根据这个状态取任务；
86.5、正在分析，数据分析节点正在对任务进行处理；
87.6、需要处理，数据分析节点处理完成的状态，数据处理节点将根据这个状态取任务；
88.7、正在处理，数据处理节点正在对任务进行处理，成功处理后置为完成状态；
89.8、失败，在分析阶段时发现获取数据的结果的失败案例较高，需要对当前任务进行进一步的调整并重新执行的任务。
90.5)时间戳；
91.6)其他字段，各个不同的状态差异较大，具体说明如下：
92.1、重新执行次数，失败状态转化成未开始状态的关键字段；
93.2、任务失败原因，任务分发节点在对失败任务是否重新执行时需要考虑的字段；
94.3、任务数据，在数据获取任务中对应步骤2
‑
(2)中的结果返回的数据；在分析任务中，对应获取任务中获取到的原始数据和节点的网络、端口连通性数据；处理任务中对应获取任务中获取到的原始任务。数据多的对应任务的时长更长；
95.4、任务的处理方法，该字段主要出现在获取任务和处理任务中，获取任务中描述根据获取约束条件整理出的方法，包括获取频率，使用代理标记等和方法有关的字段；处理任务描述获取到的数据时使用的处理方法的id，对应具体的匹配模式、处理规则，这个处理方法的字段在用户指定后会一直存在；
96.5、节点睡眠时间，该时间主要是在数据源具有限额约束时，为了保证获取量和获取效率而采取的一种措施。
97.(4)任务数据集合，其中每个任务数据文件中字段的构成为：
98.1)任务id，对应具体任务中的任务id；
99.2)类型，主要分为以下几种：
100.1、初始数据，主要由预处理模块对用户输入的任务数据进行分类后的结果，或是数据处理节点将本次获取任务中获取失败的条目汇总的结果；
101.2、获取的原始数据：由数据获取任务中获取到的结果；
102.3、连通性和设备数据：在数据获取任务期间经过探测数据源的网络、端口连通性获得的结果，还有获取节点的设备信息如ip地址、设备名等；
103.3)具体数据，注意，如果类型是“获取的原始数据”且对应条目很多的情况下，具体的每个条目都已初始数据中的条目作为键在处理；类型是“连通性和设备数据”，需要进一步存储每次连通性探测结果的时间戳；
104.4)条目数量；
105.(5)处理方法集合，其中每个文件中字段的构成为：
106.1)方法id；
107.2)类型，主要分为文本型和脚本型；
108.3)内容，文本型对应具体的处理模板，例如正则匹配规则；脚本型对应一段处理的代码；
109.(6)最终结果集合，将处理任务结束后的任务数据分条目进行存储，数量和最终成功地条目数有关，主要包含以下字段：
110.1)条目名；
111.2)处理方式；
112.3)任务id；
113.4)是否成功处理，如果成功处理的情况下，具体内容字段是有意义的；
114.5)具体内容，包括原始字段，其他字段可以根据处理方式中的字段继续向下细分。
115.在消息传递部分中，每个数据获取节点在消息队列中创建一个自己的队列(g
××
_queue)，该队列主要负责提醒该节点进行数据的处理；所有数据处理节点使用一个共同的队列(p_queue)，所有数据分析节点使用一个共同的队列(a_queue)，队列的作用同数据获取节点类似的提醒作用，这两个队列使用点对点模式，即后两类节点订阅的队列中存在需要处理的消息时，队列只允许一个节点对该消息进行接收处理。此外，以上的三类节点还需要订阅一个队列(l_queue)，该队列是用来接收任务分配节点发送的连通性测试通知和任务执行情况检测通知。任务分配节点需要配置一个自己的消息队列(m_queue)，主要接收其他节点发来的消息，信息包括其他节点的任务通知信息、任务日志信息和各节点接收到连通性检测的响应信息。
116.任务分发节点设置3个计时器，一个用于定时启动其他各节点连通性的探测功能，一个用于定时启动任务执行状态获取功能，一个用于定时查看任务集合，并对状态为失败的任务进行处理，具体实现在环节4中体现。
117.在获取节点上配置代理池，需要保证代理池中代理的可用性、稳定性。并且需要配置相关的辅助功能，例如在需要登录的一些api中含有验证码，需要具备获取、识别验证码的能力。
118.除任务分发节点外的各种节点需要对于当前任务生成日志的能力，对应任务数据中的每一条是否执行生成一个执行成功或者报错的信息。此外，除任务分发节点外的每个节点对应任务分发节点的连通性探测、任务执行情况监测具有构造消息的能力，连通性探测返回的是网络连通情况，任务执行情况监测返回的是对应任务的日志信息。
119.二、数据获取
120.在本实施例中，用户把将要放入系统进行获取的数据以及指定的数据源的信息输入到系统中(例如，一个实例是，批量获取一大批域名的whois信息，需要把构成whois请求的域名作为输入由用户提供，对应的数据源指定为域名对应的whois服务器，具体获取的处理格式由用户选择)，任务分发节点根据数据库中数据获取节点的信息结合已经探测到的数据源的约束条件将获取任务进行构造，并将具体的任务传送到对应的消息队列中进行处理。具体步骤如下：
121.步骤21，预处理模块对应的节点在数据流入后对用户提供的数据进行处理，包括数据分类和确定处理方式，对应图1中st1。
122.首先进行初始任务数据的分类，对应图2中预处理模块
‑
1。数据分类的方法主要根据数据源的种类、数据处理模式的差异、输入数据的种类进行划分，将同类数据放在一起。例如，一个场景是，向某api输入域名、ip数据，并爬取对应api的返回信息，这时用户需要向系统输入大量的域名和ip的数据，该api对应输入域名和输入ip的返回格式不同，这时，该模块可以对用户输入种类分类，或者根据爬虫的匹配格式进行分类。
123.其次是存储对获取到数据的处理方式，对应图2中预处理模块
‑
2。确定处理方式可以由用户指定，同时也包含系统中几种默认的模板处理，用户指定时，需要表明具体的类型是“文本型”还是“脚本型”再传入处理方法集合中，生成对应的方法id。在接收到用户输入后向任务分发节点发送处理请求。
124.步骤22，任务分发节点收到数据获取的请求，从数据库中获取一个获取任务必要的信息，开始建立任务或对任务进行分发，对应图1中st2、st3。具体包含以下步骤：(本步骤
中的(1)
‑
(4)对应图2中任务分发模块
‑
1，(5)对应图2中3任务分发模块
‑
2)
125.(1)先从约束条件表中搜索出所有和该数据源有关的约束条件。判断约束条件是否过期，将过期的约束条件删除。考虑任务的收敛计数：如果收敛计数超过10次，认为该约束基本确定，则将和该约束内容相同的其他约束删除，并可以开始将大规模数据分配给的获取节点以保证按照约束条件中的约束构造稳定高效的数据获取任务；否则，对于内容相同的约束，选择收敛计数高的作为构造的参考。首先确定的新任务获取频率：若存在频率方面的约束条件且该约束未收敛，则将按照约束中的间隔时间加5秒规定此次获取任务的频率，否则直接按照收敛后的频率进行使用；若不存在，则按照标准规定的频率初值(间隔时间为5秒)进行使用。
126.(2)计算任务数据的数量，根据节点的频率、限额等，以1.5小时为单位进行分配该任务所含任务数据的数量。考虑频率的约束时，这里采用一种平均情况下的估算办法，按照这种估计方法所分配的数据量均为当前的最大值，具体分配时任务数据量会小于等于该值：例如约束间隔时间是5秒的节点，传输时延不超过1秒，数据源处理数据的时间不超过1秒，若分配给该节点150条任务数据，大致需要18分钟的时间能够完成任务，则1小时内所获取的数字大约在450条数据；以此方法估计，约束时间间隔20秒以内的节点，分配180条数据都可以在1小时内完成；时间间隔35秒以内的节点，分配100条数据都可以在1小时内完成；其余大于40秒的节点，分配80条数据。这样的估算是按照网络延迟较大、处理时间较长的方法估算的，实际的获取时间应该会小于等于估算的时间。此外，这步中应该考虑对应数据源的限额的约束，如果有具体的限额约束，则会伴随有对应的节点睡眠时间，再获取一定量的数据后进入睡眠状态。默认对约束条件收敛次数小于等于2的数据源或无任何约束条件的数据源分配的任务的执行时间为1.5小时，并根据前面提到估算规则分配相应数量的数据；如果约束条件已经收敛，则可以将大规模数据交给该节点进行获取。
127.(3)从节点信息表中寻找数据获取节点是否处于空闲状态，这里在选取节点时遵循的策略是：
128.如果对于数据源没有相关的节点信息方面(ip地址等可以确定节点类的信息)约束产生，则随机选择一个空闲状态的节点作为执行节点；
129.如果数据源的有节点信息类的约束条件约束，则需要根据具体的约束条件进行判断在空闲的节点中选择，具体情况如下：
130.对于类似黑名单类的约束条件，先将其中过期的去除，再将约束条件中已经生成的约束和所有的已有的所有节点信息做差集，从剩余的空闲节点中选择一个作为任务节点，并需要在生成的任务中标记使用代理的标记；如果当前没有空闲节点可用，则选择一个不受条件约束的忙碌节点或睡眠节点布置任务，并将任务状态置为“失败”，失败原因为“无空闲节点”。
131.(4)根据(1)
‑
(3)步获取到的信息进行任务的构造，每条任务的构造格式按照环节1中数据库部分中任务集合给定的格式进行，构造出新的任务，状态为“未开始”，时间戳对应当前时间更新，将方法字段根据(1)步中的约束进行完善获取方法，如果环节2—步骤1中用户指定了方法，将处理方法中加入处理阶段的方法id，并将该任务存入数据库的任务集合中。
132.(5)任务分配节点将任务集合中对应“未开始”状态的任务取出，将对应每个任务
的通知消息的传入对应获取节点的消息队列g
××
_queue中。
133.步骤23，空闲的数据获取节点g
××
通过监听自己的消息队列g
××
_queue，取到由任务分发节点发出的任务的消息，根据任务方法的具体要求，配置并执行该获取任务，将结果进行反馈，对应图1中st4。具体包含以下步骤：(本步骤中的(2)对应图2中数据获取模块
‑1‑
(2)，(3)对应图2中6数据获取模块
‑1‑
(1)，(1)(4)(5)(6)对应图2中数据获取模块
‑
2)
134.(1)不断监听自己订阅的消息队列g
××
_queue，一旦发现了对应的任务，通过访问数据库将对应的任务状态改成“正在获取”，当前节点执行的任务置为对应任务，状态置为“忙碌”，并且将自己收到任务的消息传递给任务分发节点。
135.(2)开始两个定时程序，分别置于两个独立进程中，一个短定时作为对与数据源连通性的探测，短定时时长的设定为5分钟一次；一个长定时作为对于数据源指定服务端口的探测(例如whois服务针对43端口)，长定时的时长设定为10分钟一次。设置两个标记，分别标志连通性和端口开放，连通性标记的状态分为：正常、无法联通、未知；端口标记的状态为：正常、关闭、未知。在整个获取数据程序的执行过程中，这两个程序将不断执行，并分别记录每次执行后的结果。
136.(3)根据具体的数据源和获取的数据类型，决定是否要使用对应的辅助功能，比如生成识别验证码，构造cookie，模拟人工操作等的功能。这些功能需要根据具体获取数据源的要求进行具体的考察并决定是否调用。
137.(4)将任务方法中对应的参数(获取频率、使用代理标记等)进行配置，并开始对数据源，从数据库中用任务中任务数据字段取出任务数据，并利用这些数据向数据源构造获取请求进行原始数据的批量获取。如果任务中有节点睡眠时间字段，则在获取限额规定的条数后，将数据库中本节点的状态改为“睡眠”，并停止获取开始睡眠相应的时间。进入睡眠状态的节点在睡眠时间结束后，会更改数据库中本节点的状态为“忙碌”，并继续执行获取任务。
138.关于具体获取数据的过程要求，由数据源类型和任务数据类型所决定，必要时可以使用代理池中的代理，代理更换的策略根据不同数据源的约束做出更改(默认设为一个代理使用时间至少5分钟)，具体的获取实例这里不做穷举和具体描述，只举一例作为说明，例如利用给定域名向某个whois服务器进行whois原始数据的获取，通过构造socket内容，指定whois服务端口(43)，向对应的whois服务器发送报文请求，并获取到原始的域名whois数据，如果需要使用代理，在一段时间后，在构造某条socket访问时采用代理池中的代理。将获取到的原始数据、(2)中对应的网络连通性信息、获取节点的相关信息加入数据库中对应的任务id的任务数据文件中对应的字段，标注对应的类型分别为：获取的原始数据、连通性和设备数据，并将更改后的文件存入任务数据集合。
139.(5)在执行完获取任务后，在节点状态不为“故障”时，将节点的状态改为“空闲”。
140.(6)将对应的任务状态改为“需要分析”，并将任务完成的消息发送到任务分发节点的消息队列中。
141.三、数据分析
142.在本实施例中，任务分发节点收到数据获取任务完成的消息之后，将任务发送给空闲的数据分析节点，数据分析节点将获取到的结果进行数据的分析、约束条件的生成，并将完成消息返回给任务分发节点，任务分发节点进行对应信息的更新存储，并根据任务的
状态决定是否将任务消息发送到数据处理节点，数据处理节点一旦接收到了任务，便更改任务状态并执行任务，最后将处理好的数据进行存储。具体步骤如下：
143.步骤31，任务分发节点不断监听回复消息队列，接收到其中获取节点任务完成的消息，判断返回消息的节点的状态，若为“故障”，则将任务对应状态改为“失败”，不再向下进行；并对应的将任务进行发送到分析节点的消息队列中，对应图1中st2，对应图2中3任务分发模块
‑
2。
144.步骤32，所有空闲的分析节点不断监听该消息队列，在遇到任务消息时由唯一的一个节点将任务获取，并开始执行分析过程，对应图1中st5。以下为详细内容，对应关系为：(3)对应图2中数据分析模块
‑1‑
(1)(2)，(4)对应图2中数据分析模块
‑1‑
(3)，(5)对应图2中数据分析模块
‑1‑
(4)，(1)(2)(6)(7)对应图2中数据获取模块
‑
2。
145.(1)空闲的分析节点监听该队列，在收到任务消息时，该消息队列在接收消息的时候只允许一个节点进行接收，保证分析任务执行的唯一性，接收该任务的节点将数据库中对应的任务状态改为“正在分析”，当前节点执行的任务置为对应任务，状态置为“忙碌”，对应任务中执行任务节点改为当前分析节点，并将收到任务的消息发送给任务分发节点。
146.(2)将由数据获取节点任务获取到的原始数据包括连通性、数据获取任务的节点信息等数据取出，用于后续在约束类型的判断和任务状态的转化中应用。
147.(3)首先对原始数据中每个条目进行关键字匹配和模板匹配，采用对应数据类型信息的相关关键字库、获取数据的模板(例如：爬取网页代码的格式)、提示信息模板(例如：whois信息返回的警告信息，爬虫返回信息中的状态码等)、对应执行获取任务的获取节点信息进行筛选，这些关键字包含了具体可能遇到的几种约束类型：
148.1)和获取数据的模板关键字相匹配的，属于正常获取到的原始数据，不属于约束提示信息；
149.2)toooften,ratelimit,fast,connectionrefuse,connectionreset状态码429等类型的提示信息，表明其属于频率约束类型的；
150.3)quotaexceeded,toomanyrequests等类型的提示信息，表明其属于限额约束类型的；
151.4)timeout类型，属于超时信息，此类返回信息可能原因有多种，会进行具体的分析；
152.5)iplocked,blacklist等类型，或者在其中出现了获取节点信息的情况，属于节点相关信息链接受限类型的。
153.除以上类型的提示信息，其他类型的提示信息可以进行相似性的匹配，对收集到文本进行分词，并和已有的提示信息库中的每类信息模板进行相似度计算，相似度超过50％的收集起来，取其中概率最大的类型作为该信息的类型，如果相似度最大的是一般获取到数据模版，则不需要考虑该信息；如果没有相似度达标的，则不做处理。在进行详细匹配的过程中，有一些具体的数值信息会直接在返回信息中出现，此时可以直接进行提取，并作为后面生成约束信息的处理。
154.(4)为判断获取任务的具体情况，处理出现的无法直接提取数量信息的频率类和限额类的约束信息，以及判断之前关键字中无法判断的情况，需要对于(3)中得到的提示信息数据和未确认类型数据进行具体的进行数值量化统计分析，这些数值信息用于后续的任
务状态转化的分析和具体约束的生成。对获取到的提示信息的作为约束条件考虑基本要求是该类信息的出现次数占比需要达到总条数的10％及以上，具体的数据包括以下几个方面：
155.1)每种提示信息在整体获取数据中的占比；
156.2)每种提示信息在整个获取次数中的出现次数；
157.3)每种提示信息出现的间隔时间的均值；
158.4)每种提示信息连续出现次数的众数；
159.5)每种提示信息出现的聚集程度，这里指的是统计按照不同的时间分段个数对提示信息在时间上进行聚类后各聚类的大小，采用dbscan的方法，分段时间默认为3、5、10、12、15、20、25、30分钟几种作为半径，对应每个半径的最小点数为连续出现次数的众数对应的耗费时间(众数乘以间隔时间均值)比上分配时间作为比例乘以众数的结果。
160.6)每条获取数据的长度均值，方差；
161.以上几个信息作为主要的量化信息，作为生成具体的约束条件和判断约束类型的数据支持。
162.(5)根据以上(2)
‑
(4)步中收集的相关数据和信息，开始进行具体约束条件的分析和构造。
163.首先需要进行还未确认类型信息的判定，主要处理的是timeout类型和(3)中相似度匹配失败的信息，具体的判定原则如下：
164.1)对于(3)中相似度失败的信息，通过每条提示信息长度的均值方差，计算标准差系数，如果标准差系数过大，则说明该数据获取的不稳定性过高，直接构造对应约束条件：频率约束为1分钟一次、限额约束为50条且对应睡眠时间10分钟、需要使用代理，记录失败原因为“触发约束”，并直接跳出开始步骤3；否则，需要在3)中分析其类型。
165.2)对于timeout类型，首先对于(2)中的网络和端口的连通性数据进行分析，如果对应的连通性数据为未知或无法联通(占比达到一半以上)，则判定为网络情况和服务器提供服务出现故障，不生成相应的约束，记录任务失败原因为“网络拥塞或数据源故障”，直接跳转到步骤3。如果连通性良好，则在3)中进行具体的判定。
166.3)对于1)、2)中留下的信息进行进一步约束类型的判断，具体规则如下：
167.a)考虑信息出现的占比，不超过10％的情况，认为现象不明显，直接跳转到步骤3；超过10％的情况，则继续向下判断；
168.b)考虑信息出现的聚集程度，在给定聚簇个数时，如果各个聚簇的大小较为平均，且总簇数较多，则说明较为分散；否则如果个别的几个聚簇个数远大于其他聚簇(3倍以上)，且总簇数较少，则说明较为集中。如果足够分散，则说明是频率型约束的概率比较高；如果足够集中，则说明是限额或节点信息型的约束概率比较高。采用对于每种时间分段进行权值划分并累计概率的方法进行最后的判定，由于对应的数据个数不同，对于每种时间分段分配权值的方法遵循以下规则：对应的最小点数越接近连续出现次数的众数的时间分段对应的权值越高。将所有聚类分析出的概率进行加权计算出是否“足够分散”的概率，对应算出最后的判定为“足够分散”的概率，超过50％则作为频率型约束，否则作为限额和节点信息型约束。
169.其次是对于没有具体数量指标的约束进行数量上的测算估计，主要对应频率类、
限额类、和节点信息类的约束提示信息，对于每种提示信息分别单独进行以下步骤的估算，具体的估计方法如下：
170.1)对于频率类的约束条件，通常情况符合较为分散的条件，按照连续出现次数的众数进行分块(取整，多余的条数不计入其中)，对应每个块中对应获取成功的数据条数和提示信息出现的次数基本相同，计算出各块中的条数和总的获取时间，计算所有块中该提示信息的平均间隔时间，进而算出提示信息的近似触发频率；
171.2)对于限额类的信息，通常情况符合较为集中的条件，每当遇到一个满足集中出现的簇，统计两个相邻的簇中间含有成功条目的数目(如果只有一个簇，则计算所有的成功条目数)，计算簇间条数的均值，作为限额的条数的估计；计算簇中提示信息的个数的均值，并乘以对应的获取时间，作为节点停止获取数据即睡眠的时间，这里需要注意的是，如果只有一个簇，且出现位置在最后，则将睡眠时间置为最大，即24小时；
172.3)对于节点约束类信息，往往伴随着2)统计时出现，此时将节点的信息作为条件记录下来。同时2)中的睡眠时间的计算方法可以用来记录对应约束的持续时间，同理的是，如果所有提示信息出现在最后且数量大，则将持续时间置为最大，即24小时。
173.最后，根据以上得出的约束条件类型和数值结果，按照约束条件集合中文件的格式和定义的各个字段，构造对应的约束条件文件，并判断能否加入数据库作为新的约束，如果能则将约束条件文件插入。这里需要说明的是当前约束过期时间计算和当前构造的约束可否插入数据库集合两个问题的处理：
174.1)过期时间计算：对于节点约束类约束来说，直接用当前的时间戳加上计算出的持续时间即可；对于其他类型的约束，默认情况下没有过期时间，可以通过相关设置改变默认过期时间；
175.2)当前约束是否可插入：首先从数据库集合中找出所有和当前数据源相同且具体内容相同的已有约束，并对比约束数据(如频率、限额等)的偏差，如果该偏差小于5％，则将该条已有约束的收敛计数加1，不插入当前这条约束；否则，按照构造的格式将该文件插入。
176.(6)分析节点执行完获取任务后，在节点状态不为“故障”时，将节点的状态改为“空闲”。
177.(7)如果数据获取率高于70％，将对应的任务状态改为“需要处理”；否则改为“失败”并附上相关的失败原因(上面提到过的触发约束、网络拥塞或数据源故障)。并将任务完成的消息发送到任务分发节点的消息队列中。
178.四、数据处理
179.在本实施例中，任务分发节点收到数据分析任务完成的消息之后，将任务发送给空闲的数据处理节点，数据处理节点将获取到的结果进行数据的处理、将原任务数据集合改变使得任务分发节点重新加载该任务、存入数据库，并将完成消息返回给任务分发节点，任务分发节点进行对应任务信息的更新存储。具体步骤如下：
180.步骤41，任务分发节点不断监听回复消息队列，接收到其中分析节点任务完成的消息，判断返回消息节点的状态，若为“故障”，则将任务对应状态改为“失败”，不向下进行；否则在任务数据库中查找对应分析节点任务的结果，如果对应任务的状态为“需要处理”，则将任务进行发送到处理节点的消息队列中。本步骤对应图1中st2，对应图2中任务分发模块
‑
2。
181.步骤42，所有空闲的处理节点不断监听该消息队列，在遇到任务消息时由唯一的一个节点将任务获取，并开始将获取到的数据按照用户指定的方式进行处理并获得最终结果，对应图1中st6。以下为详细内容，对应关系为：(2)对应图2中数据处理模块
‑1‑
(1)，(3)对应图2中数据处理模块
‑
1，(4)对应图2中数据处理模块
‑1‑
(2)，(1)(5)对应图2中数据处理模块
‑
2。
182.(1)空闲的处理节点监听该队列，在收到任务消息时，该消息队列在接收消息的时候只允许一个节点进行接收，保证分析任务执行的唯一性，接收该任务的节点将数据库中对应的任务状态改为“正在处理”，节点执行的任务置为对应任务，状态置为“忙碌”，对应任务中执行任务节点改为当前处理节点，并将收到任务的消息发送给任务分发节点。
183.(2)根据任务中的处理方法字段在数据库的处理方法集合中找到对应的文件，并根据处理方法的具体类型进行处理程序的部署，文本型的一般处理方式为将其作为常规处理程序的指导进行处理，例如正则表达式文本或者模式规则文本；脚本型的一般处理方式为生成对应的处理程序，例如截取指定字段的脚本或文本压缩脚本。
184.(3)从数据库中取出对应的原始数据文件，对于该批量数据进行逐条的处理，并将成功处理和失败处理的结果进行聚集。如果失败处理的条数不超过20条，则将对应任务的状态改为“完成”；否则，将失败处理结果中聚集的初始数据条数，更改到对应的任务数据集合中对应当前任务id的文件中初始数据字段对应的条数，并将当前任务状态改为“失败”。
185.(4)将对应的成功结果按照对应的条目存入最终结果集合：获取成功的情况下，如果对应的条目和处理方式不存在，则创建对应的条目数据，将其中对应成功处理的条数的是否成功处理字段标为成功，任务id字段标记为当前任务id，并根据处理结果逐步完善各个具体内容字段；如果对应条目和处理方式存在，则将其是否成功处理字段标为成功，任务id字段覆盖为当前任务id，并依次覆盖其他字段。获取失败的情况下，只有不存在对应条目和处理方式是，才创建对应的条目，是否获取成功标志标记为失败。
186.(5)在执行完获取任务后，在节点状态不为“故障”时，将节点的状态改为“空闲”，并将任务完成的消息发送到任务分发节点的消息队列中。
187.五、系统内部反馈处理
188.本实施例说明的是系统内部的反馈处理，包括节点连通性的反馈处理、节点任务程序执行情况的反馈处理、失败任务的反馈处理。
189.在整个系统的执行过程中，任务分发节点需要实时地对整个系统中的其他执行节点情况进行监视，对于任务的状态和执行情况进行监视，对失败任务进行处理等。下面的功能中，(1)对应图1中st7，图2中任务分发模块
‑
3；(2)对应图1中st8，图2中任务分发模块
‑
4，(3)对应图1中st9，图2中任务分发模块
‑
5。
190.(1)连通性探测监视。任务分发节点上设有探测节点的连通性功能，其具体为：在任务分发节点上设置定时器，该定时器用于在指定的时间内向各个节点进行定时访问以确定节点的连通性，默认的定时时间为10分钟。每当定时器到时时，任务分发节点向l_queue中发送连通性信息，并对上个10分钟内m_queue中收到关于各节点连通性的响应消息进行统计，将没在时间内回复的节点记录下来，主要对应的形式为节点id和对应的失败次数，如果连续失败的次数超过3次，则将该节点的状态改成“故障”，如果该节点有正在执行的任务，则将对应的任务状态置为“失败”，失败原因为“无节点空闲”。这个过程独立于任务分发
节点的其他功能，并且从系统启动开始始终运行。
191.(2)任务执行情况监视。任务分发节点设有任务执行情况监视功能，设置默认时长为30分钟的计时器，计时器到时时向l_queue中发送任务执行情况监测通知，参考任务集合中各个任务的状态接收m_queue中各“忙碌”节点发送来的日志信息，对于日志信息进行审核，如果出现日志信息中大规模报错信息，或者时间跨度差距过大次数过多的情况，任务分发节点将对应的节点的状态改为“故障”。
192.(3)失败任务的处理。任务分发节点在查看数据库中任务集合时进行的必然操作。任务分发节点除了在m_queue收到消息时查看任务集合，还设有默认定时为10分钟的计时器定时查看任务集合。查看集合中的文件时，如果原失败的任务中没有“重新执行次数”字段，默认添加该字段并置为1，否则先判断当前的重新执行次数，如果超过10次则直接不考虑对应任务的发出，10次以下则根据对应的失败原因字段进行任务中响应字段的更新，并按照阶段和要求重新发出任务。具体分类如下：
193.1)无空闲节点，对应当前环节无空闲节点的状态。根据任务对应的节点、任务数据等判断当前任务应该处理的阶段，并查看当前该环节对应的节点是否有空闲，如果有空闲，则根据该环节进行状态修改(未开始、需要分析、需要处理)并将该任务发送到对应的消息队列中。否则，不做任何处理，等待下次计时器到时时再考虑；
194.2)触发约束，在数据分析环节或数据处理环节中得到的原因。将对应的任务状态置为未开始，重新执行次数字段加1，并重新获取当前空闲的获取节点，执行环节2—步骤2中除了(4)外的过程；
195.3)网络拥塞或数据源故障，在数据分析环节或数据处理环节中得到的原因。重新执行次数字段加2，其余过程同2)触发约束的情况。
196.以上所述仅对本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡是在本发明的权利要求限定范围内，所做的任何修改、等同替换、改进等，均应在本发明的保护范围之内。