青训营：简易分布式爬虫

一、项目介绍

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

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

三、项目实现

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

一、场景分析

（一）要解决的问题

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

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

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

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

（二）前提假设

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

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

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

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

（三）资源预估

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

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

二、技术选型

（一）编程语言

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

（二）Web框架

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

（三）消息队列

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

（四）数据存储

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

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

（五）辅助工具

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

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

三、相关开发文档

（一）技术文档

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

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

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

（二）使用文档

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

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

（三）测试文档

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

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

3.2 架构设计

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

一、场景分析

（一）要解决的问题

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

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

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

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

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

（二）前提假设

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

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

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

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

（三）当前架构解决方案

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

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

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

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

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

二、架构设计

（一）整体架构概述

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

（二）模块设计

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

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

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

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

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

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

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

1. 辅助工具

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

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

（三）模块交互流程

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

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

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

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

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

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

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

3.3 项目代码介绍

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

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

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

四、测试结果

1. 功能测试

• 测试用例

• 测试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方法是否能被正确调用。

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

1. 性能测试

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

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

五、Demo 演示视频 （必填）

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

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

六、项目总结与反思

目前仍存在的问题 已识别出的优化项 架构演进的可能性 项目过程中的反思与总结

1.目前仍存在的问题

1. 不清楚报错点为什么会报错，查找原因找不到。

1. 主从节点逻辑部分尚未完全实现，从节点连接主节点获取任务以及主节点初始化任务队列的功能缺失，无法完成完整的分布式爬虫流程。

1. 代码中部分关键功能的具体实现细节不明确，例如URLManager中管理 URL 的具体算法、DataCrawler中数据爬取和处理的逻辑不够清晰，可能影响功能的稳定性和扩展性。

1. 项目中使用的消息队列（RabbitMQ）配置信息简单，仅设置了服务器 IP，可能无法满足高并发、大规模任务的需求，容易出现消息积压或处理延迟的情况。

1. 未对数据存储方式进行性能优化，如FileStorage将数据存储在data.json文件中，随着数据量增加，文件读写效率可能降低，影响整体性能。

2.已识别出的优化项

（1）环境配置优化

1. 编写环境配置脚本，自动检测并安装项目所需的 Python 模块，降低部署门槛，提高环境配置的准确性和效率。

1. 使用虚拟环境工具（如venv或conda），将项目依赖环境进行隔离，避免不同项目间的依赖冲突，确保项目在不同环境下的可移植性。

（2）功能优化

1. 完善主从节点逻辑，实现从节点向主节点获取任务的可靠通信机制，以及主节点对任务队列的有效管理和分配，确保分布式爬虫系统正常运行。

1. 优化URLManager和DataCrawler的代码逻辑，提高代码的可读性和可维护性，例如采用更合理的数据结构存储 URL，优化数据爬取和处理的算法，提高功能的稳定性和扩展性。

（3）性能优化

1. 优化消息队列配置，根据实际业务需求调整队列参数，如设置合适的队列容量、消息持久化策略等，提高消息处理的效率和可靠性。在高并发场景下，考虑使用分布式消息队列解决方案，提升系统的吞吐量和并发处理能力。

1. 改进数据存储方式，将数据存储从简单的文件存储转换为数据库存储，如使用MongoDB或MySQL，利用数据库的索引、缓存等机制提高数据存储和查询的性能。同时，实现数据的批量存储和读取，减少 I/O 操作次数，提高整体性能。

3.架构演进的可能性

（1）引入微服务架构

将项目中的各个功能模块（如 URL 管理、数据爬取、数据存储等）拆分为独立的微服务，每个微服务可以独立开发、部署和扩展。通过微服务架构，可以提高系统的可维护性和可扩展性，便于团队成员分工协作，同时降低单个模块故障对整个系统的影响。

（2）采用分布式存储和计算框架

随着数据量和任务量的增加，现有的架构可能无法满足性能需求。可以考虑引入分布式存储框架（如HDFS）和分布式计算框架（如Spark），实现数据的分布式存储和并行计算，提高系统的处理能力和性能。

（3）集成自动化监控和运维系统

为了更好地管理和维护项目，可集成自动化监控和运维系统，如Prometheus和Grafana用于监控系统性能指标（如 CPU 使用率、内存使用率、消息队列积压情况等），Kubernetes用于自动化部署、扩展和管理容器化应用，提高系统的稳定性和可靠性。

4.项目过程中的反思与总结

（1）项目管理方面

1. 在项目初期，对项目的整体规划和需求分析不够充分，导致项目开发过程中出现部分功能缺失、架构设计不完善等问题。在后续项目中，应加强项目前期的规划和需求调研，确保项目目标明确、架构合理。

1. 团队成员之间的沟通协作不够紧密，在代码编写过程中可能存在对功能理解不一致、代码风格不统一等问题。今后应建立更加有效的沟通机制，定期进行团队交流和代码审查，确保项目开发的一致性和高效性。

（2）技术选型方面

1. 在技术选型时，对部分技术的了解不够深入，如消息队列和数据存储技术，导致在项目实施过程中发现性能瓶颈。在未来的项目中，应加强对技术选型的评估和调研，充分考虑技术的适用性、性能、可扩展性等因素。

1. 对项目的技术难度预估不足，导致项目开发进度受到影响。在后续项目中，应更加准确地评估技术难度，合理安排开发时间和资源，确保项目按时交付。

（3）代码编写方面

1. 代码的注释和文档编写不够完善，部分代码逻辑难以理解，不利于项目的维护和扩展。在今后的开发中，应注重代码注释和文档编写，提高代码的可读性和可维护性。

1. 代码的可测试性不足，缺乏单元测试和集成测试代码，难以保证代码质量和功能的正确性。在后续项目中，应建立完善的测试体系，在开发过程中及时进行测试，确保代码质量。