青训营：简易分布式爬虫

一、项目介绍

该项目是一个简易分布式爬虫系统，以分布式思想为基础，通过多节点协作的方式，将大规模的网页抓取任务分解，从而高效、快速地获取网络数据。

项目地址：https://github.com/yanchengsi/distributed_crawler

三、项目实现

3.1 技术选型与相关开发文档

一、场景分析

（一）要解决的问题

高效数据采集：需要从大量网页中快速、准确地抓取目标数据，满足数据需求方对数据及时性和完整性的要求。在面对海量网页时，传统单节点爬虫效率低下，难以在规定时间内完成数据采集任务。

分布式任务管理：实现多节点协作，合理分配爬虫任务，避免任务分配不均导致部分节点负载过高，而部分节点闲置的情况。同时，要确保任务的可靠分发与状态跟踪，保证每个任务都能得到妥善处理。

数据存储与管理：对采集到的大量数据进行有效的存储和管理，便于后续的数据处理、分析和查询。需要保证数据的安全性和完整性，防止数据丢失或损坏。

系统稳定性与扩展性：系统应具备高稳定性，能够长时间稳定运行，应对可能出现的网络波动、节点故障等问题。同时，随着业务规模的扩大，能够方便地进行扩展，增加爬虫节点或存储资源。

（二）前提假设

数据规模假设：预计在项目运行初期，每天需要采集的数据量约为10GB，随着业务的发展，数据量可能会以每月20%的速度增长。

硬件资源假设：假设每个爬虫节点服务器的配置为8核CPU、16GB内存、1TB硬盘，网络带宽为100Mbps。存储服务器配置为16核CPU、64GB内存、10TB硬盘，网络带宽为1Gbps。

网络环境假设：项目运行在稳定的企业内部网络环境中，网络延迟较低且波动较小。但可能会受到外部网络（如目标网站所在网络）不稳定因素的影响。

数据类型假设：采集的数据主要为文本数据，包含少量图片和视频数据，数据结构相对较为规范。

（三）资源预估

存储空间：根据数据规模假设，初期每天10GB的数据量，考虑到数据的存储冗余和备份需求，预计初期需要500GB的存储空间。随着数据量的增长，每月需增加约100GB的存储空间。

服务器数量：在项目初期，预计需要5台爬虫节点服务器和1台存储服务器。随着业务发展，根据数据量增长和任务负载情况，适时增加爬虫节点服务器和存储服务器数量。

二、技术选型

（一）编程语言

选择Python作为主要编程语言。Python具有丰富的第三方库，如用于网络请求的requests库、用于数据处理的pandas库、用于构建Web服务的Flask库等，能够大大提高开发效率。同时，Python语言简洁易读，便于团队成员之间的协作开发和代码维护。

（二）Web框架

采用Flask框架构建主节点的API服务。Flask是一个轻量级的Web框架，具有简单易用、灵活可扩展的特点。通过Flask可以快速搭建出用于任务分配和状态报告的API接口，满足分布式爬虫系统中主从节点之间的通信需求。

（三）消息队列

选择RabbitMQ作为消息队列。RabbitMQ是一个开源的、高性能的消息代理软件，支持多种消息协议，具有高可靠性、高扩展性和高可用性。在分布式爬虫系统中，使用RabbitMQ可以实现任务的异步分发和结果的异步收集，解耦爬虫任务的生产和消费过程，提高系统的整体性能和稳定性。

（四）数据存储

数据采集阶段：在数据采集过程中，对于临时存储采集到的数据，采用文件存储方式（如FileStorage将数据存储在data.json文件中）。这种方式简单直接，适用于数据量较小、对读写性能要求不是特别高的场景。

数据长期存储与管理：对于长期存储和管理大量数据，选用MongoDB数据库。MongoDB是一个面向文档的NoSQL数据库，具有灵活的数据模型、高扩展性和高读写性能。它能够很好地适应爬虫系统中数据结构多样、数据量快速增长的特点，方便进行数据的插入、查询和更新操作。

（五）辅助工具

代理池：使用自定义的ProxyPool工具。在爬虫过程中，为了避免被目标网站封禁IP，需要使用代理IP。ProxyPool可以实现代理IP的获取、验证和管理，为爬虫提供稳定可靠的代理IP资源。

Robots协议检查器：利用RobotsChecker工具检查目标网站的Robots协议。遵守Robots协议是爬虫合法合规运行的基础，RobotsChecker能够根据目标网站的Robots协议规则，判断是否可以对特定页面进行爬取，避免违反网站规定。

三、相关开发文档

（一）技术文档

系统架构设计文档：详细描述分布式爬虫系统的整体架构，包括主节点、从节点、消息队列、数据存储等各个组件的功能和交互关系。通过架构图和文字说明，使开发人员对系统的整体框架有清晰的认识，便于进行后续的开发和维护工作。

模块设计文档：针对每个功能模块（如URLManager、DataCrawler、DataStorage等），编写详细的模块设计文档。文档内容包括模块的功能概述、输入输出接口、内部实现逻辑、关键算法和数据结构等。这有助于开发人员深入理解每个模块的功能，提高代码开发的准确性和效率。

数据库设计文档：如果使用数据库（如MongoDB）进行数据存储，需要编写数据库设计文档。文档中应包含数据库的架构设计、集合（表）结构设计、索引设计、数据存储策略等内容。这对于保证数据库的性能和数据的一致性非常重要。

（二）使用文档

安装部署文档：提供详细的项目安装和部署步骤，包括Python环境的搭建、依赖库的安装、项目代码的部署、消息队列和数据库的配置等。确保开发人员和运维人员能够按照文档顺利完成项目的部署工作。

使用指南：编写用户使用指南，介绍如何启动分布式爬虫系统，如何配置爬虫任务（如设置爬取的URL列表、爬取深度等参数），如何查看爬虫任务的运行状态和结果等。这有助于用户快速上手使用分布式爬虫系统。

（三）测试文档

测试计划文档：制定详细的测试计划，包括测试目标、测试范围、测试策略、测试资源安排、测试进度计划等内容。明确测试的重点和难点，合理安排测试资源和时间，确保测试工作的顺利进行。

测试用例文档：根据项目的功能需求和设计文档，编写详细的测试用例。测试用例应覆盖系统的各个功能模块和关键业务流程，包括功能测试、性能测试、兼容性测试等方面。通过执行测试用例，可以发现系统中存在的缺陷和问题，及时进行修复和优化。

3.2 架构设计

可以补充场景分析环节，明确要解决的问题和前提假设，比如预计0.5%的用户属于大V，粉丝很多，也会经常上传视频，当前架构的解决方案是xxx。

一、场景分析

（一）要解决的问题

高效大规模数据采集：互联网上海量的网页数据是本项目的采集目标，需快速、全面地获取。传统单节点爬虫面对大规模数据时效率极低，无法满足数据需求，且在采集过程中容易因网络波动、网站反爬机制等问题中断，导致数据采集不完整。

应对网站反爬策略：众多网站设置了多种反爬机制，如IP限制、User - Agent检测、验证码验证等。爬虫需具备应对这些反爬策略的能力，否则频繁被封IP或禁止访问，会严重影响数据采集工作。

分布式任务调度与协同：实现多节点的高效协作，合理分配爬虫任务。避免出现任务分配不均的情况，防止部分节点负载过高而部分闲置，同时要确保任务在节点间可靠分发与状态跟踪，保障任务顺利完成。

数据的有效存储与管理：采集到的大量数据需进行妥善存储和管理，方便后续处理、分析与查询。要保证数据的安全性和完整性，避免数据丢失或损坏，且在数据量不断增长的情况下，存储系统仍能高效运行。

系统的高稳定性与扩展性：系统需长时间稳定运行，能应对网络波动、节点故障等突发状况。随着业务发展，数据采集规模扩大，系统要便于扩展，可灵活增加爬虫节点或存储资源。

（二）前提假设

数据规模假设：预计初期每天需采集的数据量约为5GB，数据类型主要为网页文本、少量图片和链接信息。随着业务拓展，数据量将以每月15%的速度增长。

硬件资源假设：每个爬虫节点服务器配置为4核CPU、8GB内存、500GB硬盘，网络带宽为50Mbps。存储服务器配置为8核CPU、16GB内存、2TB硬盘，网络带宽为100Mbps。

网络环境假设：项目运行在相对稳定的网络环境中，但可能受外部网络（如目标网站所在网络）不稳定因素影响，存在一定网络延迟和丢包率。

网站反爬假设：假设约30%的目标网站存在一定程度的反爬机制，其中10%的网站反爬机制较为复杂，需要采用多种策略应对。

（三）当前架构解决方案

针对高效大规模数据采集：采用分布式爬虫架构，多节点并行工作，提高数据采集效率。通过URL管理器统一管理待爬取URL，合理分配任务到各个爬虫节点，实现高效的数据采集。

应对网站反爬策略：利用代理池获取大量代理IP，定期更换IP地址，规避IP限制。同时，在请求头中设置多样化的User - Agent，模拟不同的访问终端。对于验证码验证，考虑引入第三方验证码识别服务或开发智能识别算法。

分布式任务调度与协同：使用消息队列（如RabbitMQ）实现任务异步分发和结果异步收集。主节点将任务发送到消息队列，从节点从队列中获取任务并执行，完成后将结果返回。主节点通过消息队列监控任务状态，进行任务重试和调度优化。

数据的有效存储与管理：根据数据量和业务需求，初期采用文件存储（如FileStorage将数据存储在data.json文件中）进行临时存储，后期随着数据量增长，切换到数据库存储（如MongoDB或MySQL）。MongoDB适合处理海量、结构灵活的数据，MySQL适合对数据一致性和事务性要求较高的场景。利用数据库的索引、分区等技术，提高数据存储和查询性能。

系统的高稳定性与扩展性：在系统设计上，各个模块之间相对独立，通过接口进行交互。当某个节点出现故障时，其他节点可以继续工作，消息队列会暂存任务，待故障节点恢复后重新分配任务。如需扩展系统，只需增加爬虫节点服务器和存储服务器，调整相关配置即可。

二、架构设计

（一）整体架构概述

本分布式爬虫系统主要由主节点、从节点、URL管理器、消息队列、数据采集模块、数据解析模块、数据存储模块和辅助工具（代理池、Robots协议检查器）组成。各部分协同工作，实现数据的高效采集、处理和存储。

（二）模块设计

主节点：作为整个系统的核心控制单元，负责初始化任务队列，将种子URL添加到URL管理器中。通过Flask框架搭建API服务，提供任务分配接口（如/get_task）和任务状态报告接口（如/report_status）。接收从节点的任务状态报告，根据任务执行情况调整任务分配策略，确保任务的有效调度。

从节点：从消息队列中获取爬虫任务，调用数据采集模块、数据解析模块和数据存储模块完成任务。数据采集模块负责根据URL获取网页内容，数据解析模块对采集到的网页内容进行解析，提取有用信息，数据存储模块将解析后的数据保存到指定存储介质。从节点执行完任务后，将任务状态（成功或失败）通过消息队列或API报告给主节点。

URL管理器（URLManager）：使用Redis数据库存储URL。负责管理待爬取URL集合和已爬取URL集合。提供添加种子URL、获取待爬取URL、添加新发现URL、获取已访问URL等功能。利用Redis的集合数据结构，确保URL的唯一性和高效的添加、查询操作。

消息队列（如RabbitMQ）：在主节点和从节点之间传递任务和任务结果。主节点将任务发送到任务队列（如crawler_tasks），从节点从任务队列中获取任务进行处理。从节点完成任务后，将结果发送到结果队列（如crawler_results），主节点从结果队列获取任务状态，实现任务的异步处理和解耦。

数据采集模块（DataCrawler）：从URL管理器获取待爬取URL，根据配置决定是否使用代理IP访问目标网站。检查目标网站的Robots协议，确保合法爬取。获取网页内容后，传递给数据解析模块，并根据任务执行情况标记URL为已访问或失败。

数据解析模块（DataParser）：对采集到的网页内容进行解析，提取页面标题、正文、元数据、图片链接、页面链接等信息。提供多种解析方法，适应不同类型网页的解析需求，确保解析结果的准确性和完整性。

数据存储模块（DataStorage）：提供多种存储实现方式，如文件存储（FileStorage）、MongoDB存储（MongoDBStorage）和MySQL存储（MySQLStorage）。根据项目需求和数据特点选择合适的存储方式，负责将解析后的数据保存到相应存储介质中，并提供数据查询和管理功能。

辅助工具

代理池（ProxyPool）：负责管理代理IP资源，提供获取代理IP的接口。定期检查代理IP的可用性，剔除无效代理IP，确保数据采集模块使用的代理IP有效，提高爬虫的抗反爬能力。

Robots协议检查器（RobotsChecker）：根据目标网站的Robots协议，检查是否允许爬取特定URL。获取Robots协议中规定的爬取延迟时间，控制爬虫的访问频率，遵守网站的访问规则，避免过度爬取。

（三）模块交互流程

主节点启动时，将种子URL添加到URL管理器中，并初始化消息队列。

从节点启动后，持续监听消息队列中的任务。当有任务时，从URL管理器获取待爬取URL。

数据采集模块使用代理IP（若配置启用），根据Robots协议检查结果访问目标网站，获取网页内容。

采集到的网页内容传递给数据解析模块，解析提取相关信息。

解析后的数据由数据存储模块保存到指定存储介质。

数据采集模块根据任务执行情况标记URL状态，并将任务结果（成功或失败）通过消息队列报告给主节点。

主节点根据任务结果调整任务分配策略，继续分配新任务，循环执行上述流程，直至完成所有任务。

3.3 项目代码介绍

主节点 API 代码（master_api.py）：基于 Flask 框架构建。/get_task接口用于从URLManager获取待爬取 URL 并返回；/report_status接口接收爬虫任务状态报告，根据状态调用URLManager相应方法标记 URL 状态，日志记录状态报告信息。主程序启动 Flask 应用，监听0.0.0.0:5000。

消息队列操作代码（mq_operations.py）：借助pika库与 RabbitMQ 交互。send_task_to_queue将 URL 任务发送到crawler_tasks队列；receive_task_from_queue从队列获取任务，实例化相关类执行爬取，根据结果调用send_result_to_queue将任务状态发送到crawler_results队列。

主程序代码（newMain.py）：使用argparse处理命令行参数。main函数根据is_master参数区分主从节点逻辑，目前主从节点逻辑部分暂未实现。实例化多个爬虫相关类后调用data_crawler.crawl()执行爬虫操作。

四、测试结果

功能测试

测试用例

测试master_api.py中/get_task接口：准备一个有等待 URL 的URLManager实例场景，发起 GET 请求到/get_task，预期返回包含有效 URL 的 JSON 数据；再准备URLManager中无等待 URL 的场景，请求后预期返回{"task": null}。

测试master_api.py中/report_status接口：模拟向/report_status发送 POST 请求，请求体分别设置status为success和failed，同时携带一个已存在于URLManager中的 URL，查看URLManager中对应 URL 的状态是否按预期更新，并且检查日志是否正确记录状态报告信息。

测试mq_operations.py消息队列操作：使用消息队列客户端工具向crawler_tasks队列发送一个测试 URL 任务，观察receive_task_from_queue函数是否能正确获取任务并调用DataCrawler进行爬取，同时检查crawler_results队列是否收到正确的任务状态消息。

测试newMain.py主程序：分别使用--master参数和不使用该参数运行程序，检查是否能按预期进入主节点或从节点逻辑（尽管目前部分逻辑未实现，但可检查程序流程是否正确），并且观察DataCrawler的crawl方法是否能被正确调用。

测试结果分析：如果各接口和函数按照测试用例预期执行，如接口返回正确数据、状态更新无误、消息队列正常通信、主程序流程正确，那么功能测试通过。若出现如接口返回错误数据、状态未更新、消息丢失、程序崩溃等问题，则功能测试不通过，需根据错误提示和日志信息排查代码错误，如模块导入问题、函数逻辑错误、配置错误等。

性能测试

性能分析报告：在测试环境中模拟多任务并发场景，向crawler_tasks队列批量发送 URL 任务，使用性能测试工具（如 JMeter 等）监控系统性能。记录系统响应时间，包括从任务发送到receive_task_from_queue获取任务的时间、任务处理完成并返回结果的时间；统计系统吞吐量，即单位时间内处理的任务数量；监控服务器资源利用率，如 CPU、内存、网络带宽等。如果响应时间过长，可能是消息队列处理速度慢、DataCrawler处理任务效率低；吞吐量低可能是系统资源瓶颈、任务处理逻辑复杂导致；资源利用率过高则表明系统在当前配置下无法高效处理任务。

可优化点：若消息队列成为性能瓶颈，可考虑优化消息队列配置，如增加队列容量、优化消息存储方式，或更换更高效的消息队列系统。若DataCrawler处理任务慢，检查handle_crawl方法中网络请求、数据解析、存储操作等环节，优化代码逻辑，如使用异步请求提高网络请求效率、优化数据解析算法、采用更高效的存储方式（如数据库索引优化、批量存储等）。针对系统资源利用率高的问题，可进行硬件升级，如增加内存、更换高性能 CPU，或优化代码减少资源消耗，如合理释放不再使用的对象资源、优化算法减少计算量。

五、Demo 演示视频 （必填）

项目并没有完成很好，运行时总是bug不断，报错。明明有module，可还是运行不了。

[Screen Recording 2025-03-05 213351.mp4]

六、项目总结与反思