分布式爬虫任务调度方法、系统和设备

摘要

本申请涉及分布式爬虫任务调度方法、系统和设备，方法包括：获取当前节点的云原生服务器的容器资源数据；根据容器资源数据确定云原生服务器的健康阈值；根据配置的各分布式爬虫任务执行时占用的资源量，确定各分布式爬虫任务在云原生服务器执行时的资源消耗预估值；根据容器资源数据、健康阈值和各资源消耗预估值，计算云原生服务器的最高执行任务数量；根据最高执行任务数量，利用配置的任务自动调配策略在云原生服务器上进行分布式爬虫任务调度与执行；任务自动调配策略用于在健康阈值内动态调节云原生服务器上执行的分布式爬虫任务数量。达到了大幅提高任务调度、资源分配与利用效率的目的。

权利要求

1.一种分布式爬虫任务调度方法，其特征在于，包括步骤：

获取当前节点的云原生服务器的容器资源数据；

根据所述容器资源数据确定所述云原生服务器的健康阈值；

根据配置的各分布式爬虫任务执行时占用的资源量，确定各所述分布式爬虫任务在所述云原生服务器执行时的资源消耗预估值；

根据所述容器资源数据、所述健康阈值和各所述资源消耗预估值，计算所述云原生服务器的最高执行任务数量；

根据所述最高执行任务数量，利用配置的任务自动调配策略在所述云原生服务器上进行分布式爬虫任务调度与执行；所述任务自动调配策略用于在所述健康阈值内动态调节所述云原生服务器上执行的所述分布式爬虫任务数量；

所述方法还包括步骤：

若所述云原生服务器在执行分布式爬虫任务时的资源消耗量超过所述健康阈值，则通过所述任务自动调配策略修改所述最高执行任务数量；

根据修改后的所述最高执行任务数量，调节所述云原生服务器上执行的分布式爬虫任务数量；

获取当前节点的云原生服务器的容器资源数据的步骤，包括：

获取所述云原生服务器的容器资源参数；所述容器资源参数包括CPU核数、内存参数、硬盘参数和宽带参数；

获取所述云原生服务器在系统启动后的资源剩余参数；

根据配置的各分布式爬虫任务执行时占用的资源量，确定各所述分布式爬虫任务在所述云原生服务器执行时的资源消耗预估值的步骤，包括：分别获取各分布式爬虫任务的执行单元占用的固定资源量；

通过时空复杂度函数分别计算各分布式爬虫任务的执行单元的过程消耗资源量；其中，时空复杂度函数为：其中， 表示过程消耗资源量， 表示分布式任务启动时的时刻时间， 表示t时刻时间， 表示任务启动时资源占用情况， 表示任务执行1秒时资源占用情况，表示任务执行2秒时资源占用情况， 表示任务执行到t时刻资源占用情况；

根据所述固定资源量和所述过程消耗资源量分别计算得到各所述分布式爬虫任务的资源消耗预估值。

2.根据权利要求1所述的分布式爬虫任务调度方法，其特征在于，所述任务自动调配策略为：其中， 表示云原生服务器上执行的分布式爬虫任务数量， 表示当前节点i的内存资源百分比阈值， 表示当前节点i已用的内存资源百分比， 表示当前节点i的应用资源百分比阈值， 表示当前节点i的应用资源百分比， 表示当前节点i应用设置的每个执行单元占用资源大小， 表示单个分布式爬虫任务所使用的线程数， 表示当前节点i的CPU资源百分比阈值， 表示当前节点i的CPU资源百分比， 表示单个分布式爬虫任务所占用的CPU资源数， 表示当前节点i的CPU核心数。

3.根据权利要求1所述的分布式爬虫任务调度方法，其特征在于，所述方法还包括：配置分布式爬虫任务；

通过所述云原生服务器部署所述分布式爬虫任务。

4.一种分布式爬虫任务调度系统，其特征在于，包括：

容器数据模块，用于获取当前节点的云原生服务器的容器资源数据；

阈值确定模块，用于根据所述容器资源数据确定所述云原生服务器的健康阈值；

资源预估模块，用于根据配置的各分布式爬虫任务执行时占用的资源量，确定各所述分布式爬虫任务在所述云原生服务器执行时的资源消耗预估值；

任务量计算模块，用于根据所述容器资源数据、所述健康阈值和各所述资源消耗预估值，计算所述云原生服务器的最高执行任务数量；

策略执行模块，用于根据所述最高执行任务数量，利用配置的任务自动调配策略在所述云原生服务器上进行分布式爬虫任务调度与执行；所述任务自动调配策略用于在所述健康阈值内动态调节所述云原生服务器上执行的所述分布式爬虫任务数量；

任务量计算模块还用于若所述云原生服务器在执行分布式爬虫任务时的资源消耗量超过所述健康阈值，则通过所述任务自动调配策略修改所述最高执行任务数量；根据修改后的所述最高执行任务数量，调节所述云原生服务器上执行的分布式爬虫任务数量；

任务量计算模块还用于获取所述云原生服务器的容器资源参数；所述容器资源参数包括CPU核数、内存参数、硬盘参数和宽带参数；获取所述云原生服务器在系统启动后的资源剩余参数任务量计算模块还用于分别获取各分布式爬虫任务的执行单元占用的固定资源量；通过时空复杂度函数分别计算各分布式爬虫任务的执行单元的过程消耗资源量；其中，时空复杂度函数为：其中， 表示过程消耗资源量， 表示分布式任务启动时的时刻时间， 表示t时刻时间， 表示任务启动时资源占用情况， 表示任务执行1秒时资源占用情况，表示任务执行2秒时资源占用情况， 表示任务执行到t时刻资源占用情况；根据所述固定资源量和所述过程消耗资源量分别计算得到各所述分布式爬虫任务的资源消耗预估值。

5.根据权利要求4所述的分布式爬虫任务调度系统，其特征在于，还包括：健康监控模块，用于在所述云原生服务器在执行分布式爬虫任务时的资源消耗量超过所述健康阈值时，通过所述任务自动调配策略修改所述最高执行任务数量；

数量调节模块，用于根据修改后的所述最高执行任务数量，调节所述云原生服务器上执行的分布式爬虫任务数量。

6.一种计算机设备，包括存储器和处理器，其特征在于，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现权利要求1至3任一项所述分布式爬虫任务调度方法的步骤。

说明书

分布式爬虫任务调度方法、系统和设备

技术领域

[0001] 本发明属于任务资源调度技术领域，涉及一种分布式爬虫任务调度方法、系统和设备。

背景技术

[0002] 随着互联网技术的发展，尤其是大数据和人工智能等技术应用的不断成熟，从传统的信息服务向知识服务发展成为用户信息需求的新趋势，知识服务是信息服务不断向深度和广度发展的必然结果。与信息服务相比，知识服务以信息的收集、分析、加工、整合和创新为基础，向用户提供一种支持知识应用和知识创新的服务，其服务系统需要对增量的各类网站进行增量数据爬取。针对百科类系统数量大，抓取频率快的特点，支持分布式、单点故障不影响数据获取、数据爬取任务高效的爬虫技术应运而生。基于Docker（开源的应用容器引擎）的分布式爬虫系统，其爬虫框架为Scrapy‑Redis（分布式爬虫），使用Redis（Remote Dictionary Server，远程字典服务，一个高性能的key‑value数据库）数据库存储待爬取的URL（uniform resource locator；统一资源定位符），解决了各个节点间关于URL数据同步的问题，部署在Docker集群上，也保证了爬取的高效性。然而，在实现本发明的过程中，发明人发现传统的分布式爬虫系统，存在着资源分配效率不高的技术问题。

发明内容

[0003] 针对上述传统方法中存在的问题，本发明提出了一种能够大幅提高资源分配效率的分布式爬虫任务调度方法、一种分布式爬虫任务调度系统和一种计算机设备。

[0004] 为了实现上述目的，本发明实施例采用以下技术方案：

[0005] 一方面，提供一种分布式爬虫任务调度方法，包括步骤：

[0006] 获取当前节点的云原生服务器的容器资源数据；

[0007] 根据容器资源数据确定云原生服务器的健康阈值；

[0008] 根据配置的各分布式爬虫任务执行时占用的资源量，确定各分布式爬虫任务在云原生服务器执行时的资源消耗预估值；

[0009] 根据容器资源数据、健康阈值和各资源消耗预估值，计算云原生服务器的最高执行任务数量；

[0010] 根据最高执行任务数量，利用配置的任务自动调配策略在云原生服务器上进行分布式爬虫任务调度与执行；任务自动调配策略用于在健康阈值内动态调节云原生服务器上执行的分布式爬虫任务数量。

[0011] 另一方面，还提供一种分布式爬虫任务调度系统，包括：

[0012] 容器数据模块，用于获取当前节点的云原生服务器的容器资源数据；

[0013] 阈值确定模块，用于根据容器资源数据确定云原生服务器的健康阈值；

[0014] 资源预估模块，用于根据配置的各分布式爬虫任务执行时占用的资源量，确定各分布式爬虫任务在云原生服务器执行时的资源消耗预估值；

[0015] 任务量计算模块，用于根据容器资源数据、健康阈值和各资源消耗预估值，计算云原生服务器的最高执行任务数量；

[0016] 策略执行模块，用于根据最高执行任务数量，利用配置的任务自动调配策略在云原生服务器上进行分布式爬虫任务调度与执行；任务自动调配策略用于在健康阈值内动态调节云原生服务器上执行的分布式爬虫任务数量。

[0017] 又一方面，还提供一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述分布式爬虫任务调度方法的步骤。

[0018] 上述技术方案中的一个技术方案具有如下优点和有益效果：

[0019] 上述分布式爬虫任务调度方法、系统和设备，对于每个分布式节点，通过首先获取当前节点的容器资源数据，确定其健康阈值后，再根据配置的各分布式爬虫任务执行时占用的资源量进行任务执行时的资源消耗预估，进而计算云原生服务器的最高执行任务数量，最后利用制定的任务自动调配策略，对容器资源占用以及预估任务执行的资源占用情况进行合理的计算，进而对云原生服务器上执行的任务数量进行动态调度，使之能在不超过当前节点的健康阀值的前提下执行更多的任务，从而达到大幅提高资源分配与利用效率的目的。

附图说明

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

[0021] 图1为一个实施例中分布式爬虫任务调度方法的流程示意图；

[0022] 图2为另一个实施例中分布式爬虫任务调度方法的流程示意图；

[0023] 图3为一个实施例中分布式爬虫任务调度方法的应用流程框架示意图；

[0024] 图4为一个实施例中分布式爬虫任务调度系统的模块结构示意图。

具体实施方式

[0025] 为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

[0026] 除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中在本申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请。本文所使用的术语“和／或”包括一个或多个相关的所列项目的任意的和所有的组合。

[0027] 分布式网络爬虫是搜索引擎的核心部分，负责从互联网上下载网页并把网页保存起来，从新下载的网页中抽取URL并沿着这些URL的指向继续爬行。根据爬虫的分散程度不同，可把分布式爬虫分为两类：基于局域网的分布式爬虫和基于广域网分布式网络爬虫。以典型的 Web 应用程序为例，通常 Web应用程序包含一个或多个 Apache（Web服务器软件）程序用来对外提供服务。使用 Docker容器技术，只需在物理机上安装 Docker，将 Apache程序和Redis应用放在单独的 Docker 镜像中。Docker 镜像可以用私有 Docker Registry（注册表/仓库）来存储和分发，Private Docker Registry（私有Docker注册表）可以从 Docker Hub（中心/集线器）同步一些镜像，这样 Docker host（Docker服务机/容器/宿主）在下载 Docker 镜像的时候可以直接从 Private Docker Registry 下载，速度会比较快。数据库这种基础数据服务可以不放在 Docker 容器里面运行，这种应用结构清晰，升级以及管理维护简单（只需要更新 Docker Registry 中的 Docker 镜像即可），所以越来越受到青睐。

[0028] 在实践中，发明人发现现有的分布式爬虫技术，其在部署爬虫的时候，通主要过手动的方式配置爬虫的线程数量，从而达到任务资源调度的目的。但是该种方式，未考虑实际容器云服务器的运行状态以及资源占用情况，可能会由于任务资源不足的原因导致爬虫任务的失败，也可能会因为线程数量设置太少，导致资源未能合理利用。

[0029] 传统的分布式爬虫技术中，虽然利用了多台机器并行执行爬虫任务，提高了爬虫的整体速度。但相对于单云原生服务器而言，会造成资源利用率低的情况。由于爬虫任务过程中的业务逻辑相对复杂，以往在配置爬虫时，一般都会预留50%以上的爬虫资源，以防止并发数量、阻塞和异常等问题带来的单机故障，有的容器云服务器可能只使用了单机10%的资源，从而大大的浪费了服务器资源。此外，分布式爬虫的原理就是在不同的容器云服务器上执行同一个爬虫任务，从而调高爬取效率。传统的分布式爬虫技术由于资源利用率低下，常常空置大量服务器资源，导致资源没有被真正的合理利用。因此，急需一种能够提升资源分配效率，以提高资源合理利用率的分布式爬虫任务调度技术。

[0030] 下面将结合本发明实施例图中的附图，对本发明实施方式进行详细说明。

[0031] 在一个实施例中，可以理解，基于Docker+Scrapy‑Redis的分布式爬虫系统的基础介绍如下：在已有的基于容器技术的分布式爬虫技术中，Docker是一种操作系统级的虚拟化技术，是基于Linux内核实现，为应用服务创建轻量级、自给自足且可移植的容器技术。Docker容器能够给系统提供和真实物理机相同的运行环境，使用Docker容器，会大大减少因为软硬件环境的不一致而产生的问题，这也避免了开发人员花大量时间去部署调整运行环境。与传统的虚拟机相比，Docker省去了部署应用时的环境配置和解决依赖等环节，并且没有任何中间层资源开销，提升了基础的资源利用率。Docker容器可以简便又快速地构建出多套一模一样的运行环境供软件系统进行项目构建和测试，对于以后数据需求量和运算需求量增长的业务，Docker容器还可以进行动态扩容或缩容，并且一台计算机服务器上可以同时部署运行多个容器与开展多种服务，可用来组建微服务架构。

[0032] Scrapy是一款基于Python开发的开源web爬虫框架，可快速抓取Web站点并提取页面中的结构化数据，具有高度的扩展性和鲁棒性。但是在面对大量的网页数据需要处理时，单主机的爬虫程序效率低下的缺点导致不能满足项目的要求，此时就必须使用分布式爬虫。单独的原始Scrapy框架并不支持分布式，而是在Scrapy的框架基础上采用Scrapy‑Redis分布式爬虫框架。利用Redis调度和存储需要爬取的请求，并存储爬取产生的项目以供后续处理使用。

[0033] Redis全称为REmoteDictionaryServer（远程字典服务），是一个高性能的Key‑Value非关系型数据库。其Value支持多种类型的数据结构，分别是字符串(String)、散列(Hash)、列表(list)、集合(set)和有序集合(sortedset)。Redis是基于内存读写的，也可以持久化存储在磁盘中，重启过后数据不会丢失。Redis操作是原子性的，支持将几个操作合并后以原子性方式执行。Redis会在一定的时间间隔内，将内存中的数据集快照写入磁盘，在恢复的时候，再根据快照写到内存中。Redis支持以master‑slave（主仆）模式的备份。

[0034] MongoDB是一个分布式基于文件存储的数据库，由C++语言编写，旨在为WEB应用提供高性能数据存储解决方案。MongoDB是一个开源的高性能NoSQL（非关系型的数据库）数据库，用于将数据存储为文档，数据结构由Key‑Value键值对构成。MongoDB存储的文档类似JSON对象，字段值可以包含其他文档。在系统负载过大时，MongoDB可以添加更多节点，以此保证服务器性能。MongoDB支持多种编程语言，如Java、C++、Python、PHP、C#和RUBY等语言。MongoDB虽属于非关系型数据库，但介于关系型与非关系型之间。在Key‑Value数据结构中，Key的类型为字符串类型，Value可以是基本数据类型、文档或数组。

[0035] 布隆过滤器是一种去重算法，其原理是一个长段的二进制位数组，在尚未存储数据时，每一位均为0，当有新的数据需要存储时，首先利用K个Hash（哈希）函数将这个数据映射成一个位数组中的K个点，然后将位数组中的对应位置赋为1，等需要判断某一个元素是否在集合中时，就去查看该元素经过Hash函数映射的K个点是否均为1。若这些位置的数值均为1，则可以大概率认为该数据已存在；若这些位不全为1，就可以认为一定不存在。判断结果为已存在的是大概率估计的结果，不能认为是一定已存在。而判断结果为不存在的，就可以认为肯定不存在，一定正确。

[0036] 因为Hash函数的选取和位数组长度的设置原因，布隆过滤器会存在一定的误判率。若判定为已存在，则有微弱可能是误判，但判定为不存在则是一定正确，这个问题被称为假阳性(Falsepositive)。对于这个问题，可以通过控制位数组的长度和Hash函数的选取来降低误判率。位数组的长度为m，Hash函数的个数为k，元素数量为n，假阳性概率为f，则满足的关系为：

[0037]

[0038] 系统使用位数组的长度及Hash函数的个数来控制误判率。对于Hash函数的选取是尽可能地做到让映射结果等概率地落在每一位上，过于偏重某部分位置都将会对最终的误判率产生很大的影响。布隆过滤器判重和存储元素的时间均为固定常数，不会随着数据量的增大而变化。另外布隆过滤器存储空间占用小，空间效率比较高。在分布式爬虫系统的URL去重时，使用二阶段的布隆过滤器，可以降低误判率。

[0039] 采用一致性哈希算法来解决元素分配不均匀的问题：分布式爬虫系统中算法原理首先是将服务器节点映射在Hash环上，然后再将待分配元素经过Hash映射在同一个Hash环上，然后由待分配元素与服务器节点的位置关系来决定元素的分配结果。要求服务器节点的映射要满足均衡性，尽量使服务器节点均匀地分布在整个Hash环上。通过一致性哈希算法，即使某一台服务器节点因故宕机停止工作退出集群，也只会影响原先分配给这台故障机器的元素，而不会影响原先分配给其它服务器节点的元素。

[0040] 在本申请中，基于docker的云原生资源合理调配技术的关键点在于单机服务器资源的获取、服务器承载的阈值设置、爬虫任务占用情况预估以及合理对执行任务的数量进行动态调配。

[0041] 请参阅图1，本申请实施例提供了一种分布式爬虫任务调度方法，包括以下步骤S12至S20：

[0042] S12，获取当前节点的云原生服务器的容器资源数据。

[0043] 可以理解，对于每个节点的云原生服务器，首先可以通过系统底层接口、人工上传或者其他参数查询方式获取云原生服务器的容器资源数据，云原生服务器是基于docker构建的，因此器容器资源数据可以包括系统初始化时的资源参数，也包括系统启动后的资源参数，用于确定该云原生服务器的资源可用情况和占用情况等。

[0044] S14，根据容器资源数据确定云原生服务器的健康阈值。

[0045] 可以理解，在部署云原生服务器并获取其容器资源参数后，可获取任务启动设置的健康阈值数，健康阈值数为容器能够正常运行的最大资源使用率，可用于结合云原生服务器固有资源参数，计算健康阈值百分比与剩余资源百分比情况，从而方便在执行任务时对云原生服务器的健康状态健康。

[0046] S16，根据配置的各分布式爬虫任务执行时占用的资源量，确定各分布式爬虫任务在云原生服务器执行时的资源消耗预估值。

[0047] 可以理解，每个分布式爬虫任务被执行时，其所需占用的资源量可以包括两类，一类是任务线程本身占用的资源量，为预设的固定值，另一类是线程过程需消耗的资源量，可以通过估算得知，因此，对于任一当前节点而言，云原生服务器在执行分布式爬虫任务前，可以先预估爬虫运行过程中的资源消耗情况，从而为云原生服务器上的任务数量依据所需资源进行动态调整提供条件。

[0048] S18，根据容器资源数据、健康阈值和各资源消耗预估值，计算云原生服务器的最高执行任务数量。

[0049] 可以理解，对于每个当前节点，在确定该节点的云原生服务器的容器资源数据、健康阈值和各分布式爬虫任务的资源消耗预估值后，即可直接计算出该节点的云原生服务器所能支持的最高执行任务数量，也即能够并发执行的分布式爬虫任务的最大数量。

[0050] S20，根据最高执行任务数量，利用配置的任务自动调配策略在云原生服务器上进行分布式爬虫任务调度与执行；任务自动调配策略用于在健康阈值内动态调节云原生服务器上执行的分布式爬虫任务数量。

[0051] 可以理解，在确定节点的云原生服务器的最高执行任务数量后，可利用预先配置的任务自动调配策略，在节点的云原生服务器的健康阈值范围内进行最大化爬虫线程创建与执行，达到容器资源最大化利用以及爬虫高效执行的目的。

[0052] 上述分布式爬虫任务调度方法，通过首先获取当前节点的容器资源数据，确定其健康阈值后，再根据配置的各分布式爬虫任务执行时占用的资源量进行任务执行时的资源消耗预估，进而计算云原生服务器的最高执行任务数量，最后利用制定的任务自动调配策略，对容器资源占用以及预估任务执行的资源占用情况进行合理的计算，进而对云原生服务器上执行的任务数量进行动态调度，使之能在不超过当前节点的健康阀值的前提下执行更多的任务，从而达到大幅提高资源分配与利用效率的目的。

[0053] 在一个实施例中，如图2所示，上述分布式爬虫任务调度方法还可以包括步骤：

[0054] S10，配置分布式爬虫任务；

[0055] S11，通过云原生服务器部署分布式爬虫任务。

[0056] 可以理解，可通过scrapy和scrapy‑redis等通用爬虫技术构建所需执行的各分布式爬虫任务，以爬取所需的数据。在爬虫任务的部署过程中，需构建docker容器（也即云原生服务器），在容器构建过程中，需初始化云容器资源，例如包括CPU核数、内存容量、硬盘容量以及宽带等资源，这些资源的数据可以作为容器资源参数。

[0057] 通过上述步骤，可以构建所需的爬虫任务并进行快速的任务部署。

[0058] 在一个实施例中，关于上述的步骤S12，具体可以包括如下步骤：

[0059] 获取云原生服务器的容器资源参数；容器资源参数包括CPU核数、内存参数、硬盘参数和宽带参数；

[0060] 获取云原生服务器在系统启动后的资源剩余参数。

[0061] 可以理解，容器资源参数属于云原生服务器的系统初始资源参数，包括该云原生服务器中配置的CPU核数、内存参数、硬盘参数和宽带参数等资源参数，用于确定各资源的资源量大小。此外，还需要获取系统启动后资源剩余参数，也即系统启动后，除系统运行本身占用的固定资源外，剩余可用的资源量。资源剩余参数可以通过调用云原生服务器操作系统底层API接口来直接读取。

[0062] 通过上述步骤，即可快速且准确地获取到云原生服务器的容器资源数据。

[0063] 在一个实施例中，关于上述的步骤S16，具体可以包括如下步骤：

[0064] 分别获取各分布式爬虫任务的执行单元占用的固定资源量；

[0065] 通过时空复杂度函数分别计算各分布式爬虫任务的执行单元的过程消耗资源量；其中，时空复杂度函数为：

[0066]

[0067] 其中， 表示过程消耗资源量， 表示分布式任务启动时的时刻时间， 表示t时刻时间， 表示任务启动时资源占用情况， 表示任务执行1秒时资源占用情况，表示任务执行2秒时资源占用情况， 表示任务执行到t时刻资源占用情况；

[0068] 根据固定资源量和过程消耗资源量分别计算得到各分布式爬虫任务的资源消耗预估值。

[0069] 可以理解，由于分布式爬虫任务一般以单个线程作为执行单元，线程本身对系统资源既有消耗的同时，也有过程损耗资源，所以需要在单个线程本身的既有消耗的基础上，计算出分布式爬虫任务的总消耗情况。线程本身占用的资源为预设固定值，而过程损耗资源可根据执行任务的实际情况，依靠现有的时间和空间复杂度函数，预估任务执行过程总运算次数以及CPU计算密集度对资源的消耗情况，而直接计算出来，从而将两项资源消耗相加即可得到该分布式爬虫任务的资源消耗预估值。

[0070] 通过上述步骤，可以高效且高准确度地预估爬虫任务运行时的资源消耗情况。

[0071] 在一个实施例中，任务自动调配策略为：

[0072]

[0073] 其中， 表示云原生服务器上执行的分布式爬虫任务数量， 表示当前节点i的内存资源百分比阈值， 表示当前节点i已用的内存资源百分比， 表示当前节点i的应用资源百分比阈值， 表示当前节点i的应用资源百分比， 表示当前节点i应用设置的每个执行单元占用资源大小， 表示单个分布式爬虫任务所使用的线程数， 表示当前节点i的CPU资源百分比阈值， 表示当前节点i的CPU资源百分比， 表示单个分布式爬虫任务所占用的CPU资源数， 表示当前节点i的CPU核心数。

[0074] 具体的，任务自动调配策略可以预先配置好并存入各云原生服务器中，以用于对节点的任务数量依据该节点的资源情况进行实时动态调配。对于任一节点而言，当前节点i根据该节点可用内存资源获取可创建的新执行单元数量，而创建相应数量的线程数量。通过可创建的执行单元数量又可获取当前节点i内存资源最大支持任务数量；根据当前节点i的单个CPU核心占用资源量，也可获取单个CPU核心支持执行的任务数，计算该节点CPU支持的并发任务执行数量，还可通过计算内存的最大支持任务数量与CPU目前支持的最大任务数量，来监控该节点的任务执行健康状态等。

[0075] 通过上述任务自动调配策略，可以使云原生服务器高效地通过获取合适的执行任务数量启动相应的任务个数来爬取所需数据。

[0076] 在一个实施例中，如图3所示，上述分布式爬虫任务调度方法，还可以包括步骤：

[0077] 若云原生服务器在执行分布式爬虫任务时的资源消耗量超过健康阈值，则通过任务自动调配策略修改最高执行任务数量；

[0078] 根据修改后的最高执行任务数量，调节云原生服务器上执行的分布式爬虫任务数量。

[0079] 可以理解，在任务执行过程中，可通过配置的过程健康监控器来实时监控云原生服务器的任务执行健康情况。在任务执行的过程中，还可能会出现实时资源占用大于健康阀值的情况，针对该情况，需要利用任务自动调配策略动态调节云原生服务器当前的执行任务数量，防止资源占用过多而引发运行事故。

[0080] 通过上述步骤，可以实时监控云原生服务器的任务运行情况，确保资源最大化利用同时保证系统健康运行。

[0081] 在实际测试中，本申请提供的上述方案相比于传统技术：能够更高效的利用系统资源，由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销，Docker对系统资源的利用率更高，无论是应用执行速度、内存损耗还是文件存储速度，都要比传统虚拟机技术更高效。因此，相比虚拟机技术，一个相同配置的主机，往往可以运行更多数量的应用。

[0082] 传统的虚拟机技术启动应用服务往往需要数分钟，而Docker容器应用，由于直接运行于宿主内核，无需启动完整的操作系统，因此可以做到秒级、甚至毫秒级的启动时间。大大节约了开发、测试和部署的时间。开发过程中一个常见的问题是环境一致性问题。由于开发环境、测试环境和生产环境不一致，导致部分bug并未在开发过程中被发现。而Docker的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性，从而不会再出现这段代码在开发机器上没问题却在测试机器上出现问题的此类问题。

[0083] 对开发和运维(DevOps)人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。使用Docker可以通过定制应用镜像来实现持续集成、持续交付和部署。开发人员可以通过Dockerfile来进行镜像构建，并结合持续集成(Continuous Integration)系统进行集成测试，而运维人员则可以直接在生产环境中快速部署该镜像，甚至结合持续部署(Continuous Delivery/Deployment)系统进行自动部署。而且使用Dockerfile使镜像构建透明化，不仅仅开发团队可以理解应用运行环境，也方便运维团队理解应用运行所需条件，帮助更好的生产环境中部署该镜像。

[0084] 由于Docker确保了执行环境的一致性，使得应用的迁移更加容易。Docker可以在很多平台上运行，无论是物理机、虚拟机、公有云或是私有云，甚至是笔记本，其任务运行结果都是一致的。因此用户可以很轻易地将在一个平台上运行的应用，迁移到另一个平台上，而无需担心运行环境的变化导致应用无法正常运行的情况。

[0085] 由于合理利用了云原生服务器的资源，所以相对与传统的分布式爬虫系统，本申请的方案中任务执行效率提高显著。若每个云原生服务器有20%至30%资源合理利用起来，爬虫效率则相对提高50%以上。

[0086] 由于采用了任务自动调配策略，除了可忽略不计的健康状态监控以及资源计算等模块占用的少量资源，节省的资源可全部投入到爬虫任务的执行中去，从而使容器始终处在健康且高效地合理利用资源的状态中。

[0087] 在容器运行过程中，由于不知道容器资源占用情况，若贸然制定爬虫执行数量，可能会因为资源不足导致服务器异常。而通过任务自动调配策略即可避免该问题，执行过程中亦会对任务执行情况进行健康检查，从而使容器执行平稳且可控。可在当前云原生服务器的优势条件下，更好的发挥大规模服务集群的执行效率，在面对TB级和PB级规模的互联网数据采集场景中，能够自动且快速地完成数据采集任务。

[0088] 应该理解的是，虽然图1和图2流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且图1和图2的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

[0089] 请参阅图4，在一个实施例中，还提供一种分布式爬虫任务调度系统100，包括容器数据模块11、阈值确定模块13、资源预估模块15、任务量计算模块17和策略执行模块19。其中，容器数据模块11用于获取当前节点的云原生服务器的容器资源数据。阈值确定模块13用于根据容器资源数据确定云原生服务器的健康阈值。资源预估模块15用于根据配置的各分布式爬虫任务执行时占用的资源量，确定各分布式爬虫任务在云原生服务器执行时的资源消耗预估值。任务量计算模块17用于根据容器资源数据、健康阈值和各资源消耗预估值，计算云原生服务器的最高执行任务数量。策略执行模块19用于根据最高执行任务数量，利用配置的任务自动调配策略在云原生服务器上进行分布式爬虫任务调度与执行；任务自动调配策略用于在健康阈值内动态调节云原生服务器上执行的分布式爬虫任务数量。

[0090] 上述分布式爬虫任务调度系统100，通过各模块的协作，首先获取当前节点的容器资源数据，确定其健康阈值后，再根据配置的各分布式爬虫任务执行时占用的资源量进行任务执行时的资源消耗预估，进而计算云原生服务器的最高执行任务数量，最后利用制定的任务自动调配策略，对容器资源占用以及预估任务执行的资源占用情况进行合理的计算，进而对云原生服务器上执行的任务数量进行动态调度，使之能在不超过当前节点的健康阀值的前提下执行更多的任务，从而达到大幅提高资源分配与利用效率的目的。

[0091] 在一个实施例中，上述分布式爬虫任务调度系统100，还可以包括健康监控模块和数量修改模块。其中，健康监控模块用于在云原生服务器在执行分布式爬虫任务时的资源消耗量超过健康阈值时，通过任务自动调配策略修改最高执行任务数量。数量修改模块用于根据修改后的最高执行任务数量，调节云原生服务器上执行的分布式爬虫任务数量。

[0092] 在一个实施例中，上述分布式爬虫任务调度系统100的各模块，还可以用于分别实现上述分布式爬虫任务调度方法各实施例中增加的步骤或者子步骤所对应的相应功能。

[0093] 关于分布式爬虫任务调度系统100的具体限定，可以参见上文中分布式爬虫任务调度方法的相应限定，在此不再赘述。上述分布式爬虫任务调度系统100中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于具体数据处理功能的设备中，也可以软件形式存储于前述设备的存储器中，以便于处理器调用执行以上各个模块对应的操作，前述设备可以是但不限于本领域已有的各型服务器设备。

[0094] 又一方面，还提供一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现如下处理步骤：获取当前节点的云原生服务器的容器资源数据；根据容器资源数据确定云原生服务器的健康阈值；根据配置的各分布式爬虫任务执行时占用的资源量，确定各分布式爬虫任务在云原生服务器执行时的资源消耗预估值；根据容器资源数据、健康阈值和各资源消耗预估值，计算云原生服务器的最高执行任务数量；根据最高执行任务数量，利用配置的任务自动调配策略在云原生服务器上进行分布式爬虫任务调度与执行；任务自动调配策略用于在健康阈值内动态调节云原生服务器上执行的分布式爬虫任务数量。

[0095] 在一个实施例中，处理器执行计算机程序时还可以实现上述分布式爬虫任务调度方法各实施例中增加的步骤或者子步骤。

[0096] 再一方面，还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现如下处理步骤：获取当前节点的云原生服务器的容器资源数据；根据容器资源数据确定云原生服务器的健康阈值；根据配置的各分布式爬虫任务执行时占用的资源量，确定各分布式爬虫任务在云原生服务器执行时的资源消耗预估值；根据容器资源数据、健康阈值和各资源消耗预估值，计算云原生服务器的最高执行任务数量；根据最高执行任务数量，利用配置的任务自动调配策略在云原生服务器上进行分布式爬虫任务调度与执行；任务自动调配策略用于在健康阈值内动态调节云原生服务器上执行的分布式爬虫任务数量。

[0097] 在一个实施例中，计算机程序被处理器执行时，还可以实现上述分布式爬虫任务调度方法各实施例中增加的步骤或者子步骤。

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

[0099] 以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

[0100] 以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可做出若干变形和改进，都属于本申请保护范围。因此本申请专利的保护范围应以所附权利要求为准。