简介这是一份基于Docker的分布式爬虫服务项目资料定位清晰内容完整面向Python爬虫开发者、运维人员以及计算机相关专业的在校学生和教师。核心技术采用Go语言实现配套容器化部署方案能够帮助读者理解分布式爬虫的任务调度、服务通信、镜像构建与容器编排流程也可直接作为毕业设计、课程设计或初期项目立项演示的参考。压缩包共含11个文件整体仅311KB以Go源码、proto接口定义、Dockerfile与构建脚本、Markdown说明文档为主要类型结构紧凑便于按模块查阅。资源涵盖了分布式服务端、客户端、单机爬虫示例以及运维构建脚本基本覆盖从环境搭建到功能验证的完整链路代码经过测试运行成功具备较高的可参考性和二次开发空间。目前已有54人浏览学习适合需要在Docker、分布式爬虫方向快速落地的中初级开发者参考。1. 为什么分布式爬虫服务要跑在 Docker 里爬虫的任务量一旦从“一天抓几百页”变成“一小时就要清洗全站”单机进程必然先碰壁。目标网站的反爬策略会因为你一个 IP 的请求频率直线上升而直接封掉而核心代码散落在不同工程师的本地环境里换个机器跑就报依赖错误。分布式爬虫服务正是用来解决这两个问题的把抓取任务切分到多个节点并发执行同时用统一的环境把这些节点包起来。而 Docker 几乎是目前最省事的打包方式——同一个镜像在所有机器上行为一致启动一个抓取节点和启动一个 Redis 只差一条 docker run 命令。下面这套基于 Docker 的分布式爬虫方案会把架构、部署、调优和排错按一条可复现的路径讲透适合已经写过 Scrapy 但还没有真正把任务拆到多台机器上跑过的工程师也适合刚接手一个爬虫项目、需要快速建起多节点任务流的后端开发者。2. 分布式爬虫服务的基础架构建模调度器、去重队列与抓取节点要跑分布式先想清楚任务从哪里来、由谁分发、各节点之间怎么避免重复抓取。绝大多数开箱即用的方案是Redis 作为消息队列和去重集合Scrapy 的 Spider 在 Docker 容器里运行所有节点都从同一个 Redis 读取待抓取 URL。这样任意一个节点挂掉任务还留在队列里不会丢失。2.1 调度器与去重队列选型为什么 Redis 是主力单机爬虫的调度器是内存里的队列进程一重启全部归零。分布式环境里必须有一个外部存储来承载队列Redis 的 list 类型天然适合先进先出。常用操作是lpush写入待抓取链接brpop阻塞式弹出多个节点同时消费时 Redis 自带原子性不会出现两个节点抓到同一个 URL 的第一层去重。去重不能靠每个节点各自维护一个set那等于没有去重。常见做法是把已经抓取过的 URL 存入 Redis 的set节点在取 URL 前先sadd试探或者直接用pipeline减少来回。下面这段代码展示了队列和去重的交互方式import redis r redis.Redis(hostredis, port6379, db0) # 生产者把新发现的 URL 放入队列并尝试加入去重集合 def produce(url): if r.sadd(seen_urls, url): # 返回值 1 表示之前不存在 r.lpush(pending_urls, url) # 真正的新链接才进队列 # 消费者从队列取出 URL已经由 produce 保证了唯一性 def consume(): _, url r.brpop(pending_urls, timeout30) return url这里用到sadd的返回值作为去重判断Redis 中集合元素已经存在时返回 0成功添加返回 1。只有新 URL 才被压入待抓取队列避免后续重复请求。brpop的阻塞特性让所有 worker 都挂起等待而不是空转查询CPU 占用保持在很低水平。去重队列如果只有一个 list在调度节奏很快时会遇到单点压力。一个折中是拆成多个 key 来分片比如按 URL 的 hash 分到pending_urls_0到pending_urls_15worker 各自绑定两个分片。这个改造放在后文调优部分再说初期单队列足够。2.2 抓取节点如何做到无状态要支持横向扩容每个抓取节点的容器内部都不能保留任务状态。常见做法是把 scrapy-redis 之类组件接入项目中Spider 从 Redis 读取起始 URL调度逻辑完全交给 Redis节点自身只负责下载网页、解析内容、把新链接重新放回队列。在代码层面Spider 的start_requests不再返回固定地址而是监听 Redis key。以 scrapy-redis 的实现为例配置文件的改动只有两处SCHEDULER scrapy_redis.scheduler.Scheduler DUPEFILTER_CLASS scrapy_redis.dupefilter.RFPDupeFilter SCHEDULER_PERSIST True REDIS_HOST redis REDIS_PORT 6379对应地在爬虫类里引用RedisSpider而不是普通的Spiderredis_key指定队列名称。这样任何一个节点启动后都会从 Redis 里抢任务任务量的大头在需要采集的 URL 量节点的数量只是决定并发上限。有一个细节常被忽略网页解析的结果中包含相对链接落地前要urljoin成绝对地址否则多个节点各自的Request会因相对路径不同而绕过去重。写个简单函数处理即可不需要额外依赖。2.3 数据采集结果的落地从节点到存储每个节点解析出结构化字段后如果各写各的 MySQL 连接高峰期很容易把数据库连接数打满。更好的做法是让节点把结果写入 Redis 的另一个 list由专门的存储进程批量写库。这个进程也可以是 Docker 容器和 worker 分开这样写库失败时不会影响抓取进度。采集结果的格式统一用 JSON 行天然兼容 Redis list 的字符串存储。存储进程启动后循环brpop结果队列攒够一百条或时间间隔超过一秒就批量执行executemany。这个“缓冲批量”的思路能明显降低数据库压力实测在同样抓取量下MySQL 的 QPS 只相当于单条写入的百分之五。下面这张表格列出各组件在 compose 编排中的角色定位方便后面写配置文件时对齐容器服务作用依赖redis队列、去重集合、结果缓冲无worker运行 Scrapy 爬虫抓取与解析redissaver从结果队列批量写数据库redis, mysql组件之间的关系是单向的worker 只认 redis不直接碰数据库saver 只从 redis 取数据不管抓取逻辑。这样任何一个环节都能独立重启、单独扩容。3. 用 Docker Compose 部署分布式爬虫服务的核心步骤架构明确之后落到具体的 Docker 部署上。以 docker-compose 编排一套包含 redis、worker 和 saver 的服务是本标题最常见的落地方式。下面给出最小可运行配置并解释每个文件为什么这样写。3.1 编写爬虫项目的 Dockerfile假设项目根目录有 scrapy.cfg、spiders 文件夹和 requirements.txt。一个克制的基础镜像能显著缩短构建时间和减小体积。用 python:3.9-slim 而不是 python:3.9理由是精简版去掉了编译工具链运行时只需要解释器和标准库。FROM python:3.9-slim WORKDIR /app # 先复制依赖文件利用构建缓存避免每次都重装 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 再复制项目代码 COPY . . # 启动命令用定制的 runner脚本内容见下文 CMD [python, run_worker.py]这里的先后顺序不是随意写的。requirements.txt在项目里一般比代码稳定先复制这一层只要依赖不变之后修改爬虫代码构建镜像时不会重新执行pip install构建速度会快很多。--no-cache-dir避免镜像里残留 pip 缓存文件顺手把镜像体积压掉几十 MB。对应的run_worker.py里需要做的是在进程内启动 Scrapyfrom scrapy.crawler import CrawlerProcess from scrapy.utils.project import get_project_settings from myproject.spiders.my_spider import MySpider process CrawlerProcess(get_project_settings()) process.crawl(MySpider, categorydigital) process.start()用CrawlerProcess的好处是同一个容器里可以加载多个爬虫类后面想在一个 worker 中运行多个 Spider 实例时只需加一条process.crawl调用。get_project_settings()会从 scrapy.cfg 指定的 settings 模块读取所有配置。3.2 用 docker-compose.yml 定义服务集群接下来是核心编排文件。这里不追求过度抽象先把三个服务写清楚version: 3.8 services: redis: image: redis:7-alpine ports: - 6379:6379 volumes: - redisdata:/data restart: unless-stopped worker: build: . command: python run_worker.py restart: unless-stopped environment: - REDIS_HOSTredis - TZAsia/Shanghai - MY_SPIDER_THREADS4 depends_on: - redis deploy: replicas: 3 volumes: - logs:/app/logs saver: build: . command: python run_saver.py restart: unless-stopped environment: - REDIS_HOSTredis - MYSQL_HOSTmysql - MYSQL_DATABASEspider - MYSQL_USERspider - MYSQL_PASSWORDsecret depends_on: - redis - mysql mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: spider MYSQL_USER: spider MYSQL_PASSWORD: secret volumes: - mysqldata:/var/lib/mysql restart: unless-stopped volumes: redisdata: mysqldata: logs:注意几个细节。worker 的depends_on只是控制启动顺序不保证 redis 在 worker 初始化时已经可连接所以应用层代码还是要有重试逻辑。deploy.replicas在 compose 的默认模式下会被忽略真正生效需要docker stack deploy或使用--scale参数这部分放到下一章。mysql 服务里通过环境变量初始化了数据库和账号避免 saver 启动时还要连上去建库。配置文件写好后一条命令拉起全部服务docker-compose up -d --build docker-compose ps docker-compose logs -f --tail100 worker redis第一条命令里-d表示后台运行--build会强制重新构建镜像确保代码修改被打进容器第二条ps用来查看容器当前状态判断是不是有服务退出第三条logs加上-f会持续输出日志--tail100只显示最后 100 行适合排查启动失败时最先报错的原因。3.3 “资料齐全”的文档包应该包含哪些内容标题里提到的“详细文档资料齐全”在实际交付项目中通常意味着仓库里至少要有 README、配置示例、部署手册和目录说明。我会在有README.md的基础上额外放进一个docs/目录里面按下面结构组织docs/ ├── architecture.png ├── deploy.md ├── settings.md ├── faq.md └── api.mddeploy.md写清楚 Docker 安装、docker-compose 版本、构建命令和启动裸机的步骤settings.md逐项解释 settings.py 里的参数faq.md放常见报错和排查记录。为了方便快速查找我给每类文档都标注了目标读者核心内容如下文档核心内容使用者deploy.mdDocker 安装、构建、启动、停止命令运维/测试settings.md所有 Scrapy 配置参数及推荐值爬虫开发faq.md常见错误、排查命令、恢复步骤接手维护者api.md自定义入口脚本和扩展接口说明二次开发者有了这套文档接手的人不需要翻完代码才能跑起来也能减少“换个环境就挂”的反复沟通。文档里的命令尽量用脚本固化少让读者手工拼路径。4. 分布式爬虫服务的并发参数与资源配额调优服务跑起来只是第一步大多数团队会在任务量上来之后面对两类问题目标网站来不及响应或者本机的 CPU/内存被爬虫容器占满。这需要从 Scrapy 的并发设置和 Docker 的资源限制两个层面配合调优。4.1 根据目标站点的响应速度调节 Scrapy 并发基础参数Scrapy 最直接的并发控制有三个设置CONCURRENT_REQUESTS、DOWNLOAD_DELAY和CONCURRENT_REQUESTS_PER_DOMAIN。在分布式场景下这些参数在每一个 worker 容器内生效它们的值必须考虑 worker 数量。表格里列的是常用起点和适用场景参数常用值场景CONCURRENT_REQUESTS16 - 32站内页面平均响应时间低于 300msCONCURRENT_REQUESTS_PER_DOMAIN8 - 16单站点防封需要限速时DOWNLOAD_DELAY0.5 - 3目标网站有反爬频率检测举例来说CONCURRENT_REQUESTS32会让单个容器同时维持 32 个 TCP 连接。如果 compose 里起了 5 个 worker总并发就是 160差不多是单机的 5 倍。但此时内存占用也会跟随响应体大小线性上涨每个未关闭的响应体在解析前都有一部分驻留在内存里。最好在settings.py里同时限制DOWNLOAD_TIMEOUT15让超时请求尽快释放连接池。4.2 用 Docker 的 cpu 和 mem_limit 约束容器资源没有资源限制时某个 worker 解析超大 HTML 页面可能导致 OOM进而拖垮整个宿主机。compose 的deploy.resources字段可以设置软硬限制但要注意使用--compatibility模式才能在 docker-compose 的经典版本下生效。下面给出一个兼容写法的示例services: worker: build: . command: python run_worker.py deploy: resources: limits: cpus: 2 memory: 1G reservations: cpus: 0.5 memory: 256M在终端执行时用docker-compose --compatibility up -d启动。limits.cpus2表示最多使用两个逻辑核memory1G限制容器最大能使用的内存。reservations是软声明提示调度器预留资源但在单机环境下不会强制隔离。另一个好用的点是为容器设置ulimits比如nofile: 65536: 65536避免需要建立大量连接时碰到文件描述符上限。设定容器内存后Scrapy 的MEMUSAGE_LIMIT_MB参数最好设成容器内存的 80%。容器里跑的是单进程Scrapy 自身有内存监控超过阈值会主动停止爬虫进程并退出通过 restart 策略实现自动重启MEMUSAGE_LIMIT_MB 800这里 800 对应容器内存 1G 的 80%留出余量给操作系统缓存和运行时依赖。如果容器内存设成 2G这个值也应同步调整为 1600。4.3 通过 docker-compose scale 实现动态扩容任务量临时上涨时不需要修改任何代码和配置。在编排文件所在目录执行docker-compose --compatibility up -d --scale worker8 --scale saver1这个命令会把 worker 从原来的数量调整到 8。--scale会创建多个同名容器compose 会自动给它们设置不同的后缀名。扩容前先确认宿主机还有足够的可分配 CPU 和内存否则系统会频繁进行进程切换抓取效率反而下降。扩容有一个前提worker 必须是无状态的Redis 里存放的队列和去重集合是唯一的事实来源。如果某个 worker 正在抓取一个长任务缩容直接把容器杀掉那这个请求就会丢失但任务链上还没产生的后续请求不会丢失因为新链接已经由其他 worker 解析并写回了队列。5. 验证抓取进度与排查容器故障的实用技巧5.1 用 redis-cli 观察任务积压和去重数量分布式爬虫运行中最想知道的三个指标是待抓取列表还剩多少已经抓了哪些去重命中率如何。Redis 提供了现成的命令直接在宿主机上执行即可不用额外装监控系统。# 进入正在运行的 redis 容器 docker exec -it $(docker ps -qf nameredis) redis-cli # 查看待抓取队列长度 LLEN pending_urls # 查看去重集合元素数量 SCARD seen_urls # 随机查看一条待处理链接判断调度是否正常 LRANGE pending_urls 0 9LLEN返回的数字如果持续增长说明数据生产速度快于抓取速度此时适当的做法是增加 worker 数量或降低DOWNLOAD_DELAY。SCARD返回的是去重集合中 URL 的数量如果把应用里的sadd放到每次Request的errback里这个值会比实际抓取成功数略大因为它包含了解析失败但已经访问过的链接。用这两个命令的差值可以估算解析失败比例。另外一个常用技巧是用MONITOR命令观察 Redis 在一秒内收到的brpop调用频率。该命令输出所有命令仅适合短时间排查不要在生产环境长期开着。5.2 三个常见故障的快速定位手段故障一worker 容器反复重启。先看日志docker-compose logs --tail200 worker日志里出现redis.exceptions.ConnectionError说明容器启动早于 Redis 就绪。此时在run_worker.py开头加入带重试的连接检查常见做法是用一个简单的循环每两秒尝试执行一次 Redis PING最多尝试三十次。也可用depends_on的condition: service_healthy但需要在 Redis 服务里定义healthcheck相对麻烦。故障二抓取速度低但 CPU 占用也不高。用docker stats看每个容器的资源使用如果 worker 的 CPU 长时间低于 30%瓶颈多半在目标网站的响应上。此时调低CONCURRENT_REQUESTS或提高DOWNLOAD_DELAY反而更稳因为网络等待占据了绝大部分时间。故障三MySQL 写入延迟过高。断开 saver 容器单独测试确认是executemany语句的问题还是数据库连接池耗尽。常见修复是提升 saver 的批量阈值例如攒到 500 条再写入一次或者增加 saver 的副本数量。写库失败时Redis 的结果队列不会丢数据等 saver 恢复后自动续跑。5.3 进阶在 worker 中通过环境变量切换目标站点同一个镜像部署多套环境很常见比如一套连测试库、一套连正式库。把不同的Scrapy启动参数变成环境变量用os.getenv读取再在 compose 文件里为不同服务设置environment。这样只需要一个镜像就能通过变量切换目标集合、数据库名和logging级别。避免为每个环境单独打镜像既省时间也少维护一个 Dockerfile。本文还有配套的精品资源点击获取
简介这是一份基于Docker的分布式爬虫服务项目资料定位清晰内容完整面向Python爬虫开发者、运维人员以及计算机相关专业的在校学生和教师。核心技术采用Go语言实现配套容器化部署方案能够帮助读者理解分布式爬虫的任务调度、服务通信、镜像构建与容器编排流程也可直接作为毕业设计、课程设计或初期项目立项演示的参考。压缩包共含11个文件整体仅311KB以Go源码、proto接口定义、Dockerfile与构建脚本、Markdown说明文档为主要类型结构紧凑便于按模块查阅。资源涵盖了分布式服务端、客户端、单机爬虫示例以及运维构建脚本基本覆盖从环境搭建到功能验证的完整链路代码经过测试运行成功具备较高的可参考性和二次开发空间。目前已有54人浏览学习适合需要在Docker、分布式爬虫方向快速落地的中初级开发者参考。1. 为什么分布式爬虫服务要跑在 Docker 里爬虫的任务量一旦从“一天抓几百页”变成“一小时就要清洗全站”单机进程必然先碰壁。目标网站的反爬策略会因为你一个 IP 的请求频率直线上升而直接封掉而核心代码散落在不同工程师的本地环境里换个机器跑就报依赖错误。分布式爬虫服务正是用来解决这两个问题的把抓取任务切分到多个节点并发执行同时用统一的环境把这些节点包起来。而 Docker 几乎是目前最省事的打包方式——同一个镜像在所有机器上行为一致启动一个抓取节点和启动一个 Redis 只差一条 docker run 命令。下面这套基于 Docker 的分布式爬虫方案会把架构、部署、调优和排错按一条可复现的路径讲透适合已经写过 Scrapy 但还没有真正把任务拆到多台机器上跑过的工程师也适合刚接手一个爬虫项目、需要快速建起多节点任务流的后端开发者。2. 分布式爬虫服务的基础架构建模调度器、去重队列与抓取节点要跑分布式先想清楚任务从哪里来、由谁分发、各节点之间怎么避免重复抓取。绝大多数开箱即用的方案是Redis 作为消息队列和去重集合Scrapy 的 Spider 在 Docker 容器里运行所有节点都从同一个 Redis 读取待抓取 URL。这样任意一个节点挂掉任务还留在队列里不会丢失。2.1 调度器与去重队列选型为什么 Redis 是主力单机爬虫的调度器是内存里的队列进程一重启全部归零。分布式环境里必须有一个外部存储来承载队列Redis 的 list 类型天然适合先进先出。常用操作是lpush写入待抓取链接brpop阻塞式弹出多个节点同时消费时 Redis 自带原子性不会出现两个节点抓到同一个 URL 的第一层去重。去重不能靠每个节点各自维护一个set那等于没有去重。常见做法是把已经抓取过的 URL 存入 Redis 的set节点在取 URL 前先sadd试探或者直接用pipeline减少来回。下面这段代码展示了队列和去重的交互方式import redis r redis.Redis(hostredis, port6379, db0) # 生产者把新发现的 URL 放入队列并尝试加入去重集合 def produce(url): if r.sadd(seen_urls, url): # 返回值 1 表示之前不存在 r.lpush(pending_urls, url) # 真正的新链接才进队列 # 消费者从队列取出 URL已经由 produce 保证了唯一性 def consume(): _, url r.brpop(pending_urls, timeout30) return url这里用到sadd的返回值作为去重判断Redis 中集合元素已经存在时返回 0成功添加返回 1。只有新 URL 才被压入待抓取队列避免后续重复请求。brpop的阻塞特性让所有 worker 都挂起等待而不是空转查询CPU 占用保持在很低水平。去重队列如果只有一个 list在调度节奏很快时会遇到单点压力。一个折中是拆成多个 key 来分片比如按 URL 的 hash 分到pending_urls_0到pending_urls_15worker 各自绑定两个分片。这个改造放在后文调优部分再说初期单队列足够。2.2 抓取节点如何做到无状态要支持横向扩容每个抓取节点的容器内部都不能保留任务状态。常见做法是把 scrapy-redis 之类组件接入项目中Spider 从 Redis 读取起始 URL调度逻辑完全交给 Redis节点自身只负责下载网页、解析内容、把新链接重新放回队列。在代码层面Spider 的start_requests不再返回固定地址而是监听 Redis key。以 scrapy-redis 的实现为例配置文件的改动只有两处SCHEDULER scrapy_redis.scheduler.Scheduler DUPEFILTER_CLASS scrapy_redis.dupefilter.RFPDupeFilter SCHEDULER_PERSIST True REDIS_HOST redis REDIS_PORT 6379对应地在爬虫类里引用RedisSpider而不是普通的Spiderredis_key指定队列名称。这样任何一个节点启动后都会从 Redis 里抢任务任务量的大头在需要采集的 URL 量节点的数量只是决定并发上限。有一个细节常被忽略网页解析的结果中包含相对链接落地前要urljoin成绝对地址否则多个节点各自的Request会因相对路径不同而绕过去重。写个简单函数处理即可不需要额外依赖。2.3 数据采集结果的落地从节点到存储每个节点解析出结构化字段后如果各写各的 MySQL 连接高峰期很容易把数据库连接数打满。更好的做法是让节点把结果写入 Redis 的另一个 list由专门的存储进程批量写库。这个进程也可以是 Docker 容器和 worker 分开这样写库失败时不会影响抓取进度。采集结果的格式统一用 JSON 行天然兼容 Redis list 的字符串存储。存储进程启动后循环brpop结果队列攒够一百条或时间间隔超过一秒就批量执行executemany。这个“缓冲批量”的思路能明显降低数据库压力实测在同样抓取量下MySQL 的 QPS 只相当于单条写入的百分之五。下面这张表格列出各组件在 compose 编排中的角色定位方便后面写配置文件时对齐容器服务作用依赖redis队列、去重集合、结果缓冲无worker运行 Scrapy 爬虫抓取与解析redissaver从结果队列批量写数据库redis, mysql组件之间的关系是单向的worker 只认 redis不直接碰数据库saver 只从 redis 取数据不管抓取逻辑。这样任何一个环节都能独立重启、单独扩容。3. 用 Docker Compose 部署分布式爬虫服务的核心步骤架构明确之后落到具体的 Docker 部署上。以 docker-compose 编排一套包含 redis、worker 和 saver 的服务是本标题最常见的落地方式。下面给出最小可运行配置并解释每个文件为什么这样写。3.1 编写爬虫项目的 Dockerfile假设项目根目录有 scrapy.cfg、spiders 文件夹和 requirements.txt。一个克制的基础镜像能显著缩短构建时间和减小体积。用 python:3.9-slim 而不是 python:3.9理由是精简版去掉了编译工具链运行时只需要解释器和标准库。FROM python:3.9-slim WORKDIR /app # 先复制依赖文件利用构建缓存避免每次都重装 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 再复制项目代码 COPY . . # 启动命令用定制的 runner脚本内容见下文 CMD [python, run_worker.py]这里的先后顺序不是随意写的。requirements.txt在项目里一般比代码稳定先复制这一层只要依赖不变之后修改爬虫代码构建镜像时不会重新执行pip install构建速度会快很多。--no-cache-dir避免镜像里残留 pip 缓存文件顺手把镜像体积压掉几十 MB。对应的run_worker.py里需要做的是在进程内启动 Scrapyfrom scrapy.crawler import CrawlerProcess from scrapy.utils.project import get_project_settings from myproject.spiders.my_spider import MySpider process CrawlerProcess(get_project_settings()) process.crawl(MySpider, categorydigital) process.start()用CrawlerProcess的好处是同一个容器里可以加载多个爬虫类后面想在一个 worker 中运行多个 Spider 实例时只需加一条process.crawl调用。get_project_settings()会从 scrapy.cfg 指定的 settings 模块读取所有配置。3.2 用 docker-compose.yml 定义服务集群接下来是核心编排文件。这里不追求过度抽象先把三个服务写清楚version: 3.8 services: redis: image: redis:7-alpine ports: - 6379:6379 volumes: - redisdata:/data restart: unless-stopped worker: build: . command: python run_worker.py restart: unless-stopped environment: - REDIS_HOSTredis - TZAsia/Shanghai - MY_SPIDER_THREADS4 depends_on: - redis deploy: replicas: 3 volumes: - logs:/app/logs saver: build: . command: python run_saver.py restart: unless-stopped environment: - REDIS_HOSTredis - MYSQL_HOSTmysql - MYSQL_DATABASEspider - MYSQL_USERspider - MYSQL_PASSWORDsecret depends_on: - redis - mysql mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: spider MYSQL_USER: spider MYSQL_PASSWORD: secret volumes: - mysqldata:/var/lib/mysql restart: unless-stopped volumes: redisdata: mysqldata: logs:注意几个细节。worker 的depends_on只是控制启动顺序不保证 redis 在 worker 初始化时已经可连接所以应用层代码还是要有重试逻辑。deploy.replicas在 compose 的默认模式下会被忽略真正生效需要docker stack deploy或使用--scale参数这部分放到下一章。mysql 服务里通过环境变量初始化了数据库和账号避免 saver 启动时还要连上去建库。配置文件写好后一条命令拉起全部服务docker-compose up -d --build docker-compose ps docker-compose logs -f --tail100 worker redis第一条命令里-d表示后台运行--build会强制重新构建镜像确保代码修改被打进容器第二条ps用来查看容器当前状态判断是不是有服务退出第三条logs加上-f会持续输出日志--tail100只显示最后 100 行适合排查启动失败时最先报错的原因。3.3 “资料齐全”的文档包应该包含哪些内容标题里提到的“详细文档资料齐全”在实际交付项目中通常意味着仓库里至少要有 README、配置示例、部署手册和目录说明。我会在有README.md的基础上额外放进一个docs/目录里面按下面结构组织docs/ ├── architecture.png ├── deploy.md ├── settings.md ├── faq.md └── api.mddeploy.md写清楚 Docker 安装、docker-compose 版本、构建命令和启动裸机的步骤settings.md逐项解释 settings.py 里的参数faq.md放常见报错和排查记录。为了方便快速查找我给每类文档都标注了目标读者核心内容如下文档核心内容使用者deploy.mdDocker 安装、构建、启动、停止命令运维/测试settings.md所有 Scrapy 配置参数及推荐值爬虫开发faq.md常见错误、排查命令、恢复步骤接手维护者api.md自定义入口脚本和扩展接口说明二次开发者有了这套文档接手的人不需要翻完代码才能跑起来也能减少“换个环境就挂”的反复沟通。文档里的命令尽量用脚本固化少让读者手工拼路径。4. 分布式爬虫服务的并发参数与资源配额调优服务跑起来只是第一步大多数团队会在任务量上来之后面对两类问题目标网站来不及响应或者本机的 CPU/内存被爬虫容器占满。这需要从 Scrapy 的并发设置和 Docker 的资源限制两个层面配合调优。4.1 根据目标站点的响应速度调节 Scrapy 并发基础参数Scrapy 最直接的并发控制有三个设置CONCURRENT_REQUESTS、DOWNLOAD_DELAY和CONCURRENT_REQUESTS_PER_DOMAIN。在分布式场景下这些参数在每一个 worker 容器内生效它们的值必须考虑 worker 数量。表格里列的是常用起点和适用场景参数常用值场景CONCURRENT_REQUESTS16 - 32站内页面平均响应时间低于 300msCONCURRENT_REQUESTS_PER_DOMAIN8 - 16单站点防封需要限速时DOWNLOAD_DELAY0.5 - 3目标网站有反爬频率检测举例来说CONCURRENT_REQUESTS32会让单个容器同时维持 32 个 TCP 连接。如果 compose 里起了 5 个 worker总并发就是 160差不多是单机的 5 倍。但此时内存占用也会跟随响应体大小线性上涨每个未关闭的响应体在解析前都有一部分驻留在内存里。最好在settings.py里同时限制DOWNLOAD_TIMEOUT15让超时请求尽快释放连接池。4.2 用 Docker 的 cpu 和 mem_limit 约束容器资源没有资源限制时某个 worker 解析超大 HTML 页面可能导致 OOM进而拖垮整个宿主机。compose 的deploy.resources字段可以设置软硬限制但要注意使用--compatibility模式才能在 docker-compose 的经典版本下生效。下面给出一个兼容写法的示例services: worker: build: . command: python run_worker.py deploy: resources: limits: cpus: 2 memory: 1G reservations: cpus: 0.5 memory: 256M在终端执行时用docker-compose --compatibility up -d启动。limits.cpus2表示最多使用两个逻辑核memory1G限制容器最大能使用的内存。reservations是软声明提示调度器预留资源但在单机环境下不会强制隔离。另一个好用的点是为容器设置ulimits比如nofile: 65536: 65536避免需要建立大量连接时碰到文件描述符上限。设定容器内存后Scrapy 的MEMUSAGE_LIMIT_MB参数最好设成容器内存的 80%。容器里跑的是单进程Scrapy 自身有内存监控超过阈值会主动停止爬虫进程并退出通过 restart 策略实现自动重启MEMUSAGE_LIMIT_MB 800这里 800 对应容器内存 1G 的 80%留出余量给操作系统缓存和运行时依赖。如果容器内存设成 2G这个值也应同步调整为 1600。4.3 通过 docker-compose scale 实现动态扩容任务量临时上涨时不需要修改任何代码和配置。在编排文件所在目录执行docker-compose --compatibility up -d --scale worker8 --scale saver1这个命令会把 worker 从原来的数量调整到 8。--scale会创建多个同名容器compose 会自动给它们设置不同的后缀名。扩容前先确认宿主机还有足够的可分配 CPU 和内存否则系统会频繁进行进程切换抓取效率反而下降。扩容有一个前提worker 必须是无状态的Redis 里存放的队列和去重集合是唯一的事实来源。如果某个 worker 正在抓取一个长任务缩容直接把容器杀掉那这个请求就会丢失但任务链上还没产生的后续请求不会丢失因为新链接已经由其他 worker 解析并写回了队列。5. 验证抓取进度与排查容器故障的实用技巧5.1 用 redis-cli 观察任务积压和去重数量分布式爬虫运行中最想知道的三个指标是待抓取列表还剩多少已经抓了哪些去重命中率如何。Redis 提供了现成的命令直接在宿主机上执行即可不用额外装监控系统。# 进入正在运行的 redis 容器 docker exec -it $(docker ps -qf nameredis) redis-cli # 查看待抓取队列长度 LLEN pending_urls # 查看去重集合元素数量 SCARD seen_urls # 随机查看一条待处理链接判断调度是否正常 LRANGE pending_urls 0 9LLEN返回的数字如果持续增长说明数据生产速度快于抓取速度此时适当的做法是增加 worker 数量或降低DOWNLOAD_DELAY。SCARD返回的是去重集合中 URL 的数量如果把应用里的sadd放到每次Request的errback里这个值会比实际抓取成功数略大因为它包含了解析失败但已经访问过的链接。用这两个命令的差值可以估算解析失败比例。另外一个常用技巧是用MONITOR命令观察 Redis 在一秒内收到的brpop调用频率。该命令输出所有命令仅适合短时间排查不要在生产环境长期开着。5.2 三个常见故障的快速定位手段故障一worker 容器反复重启。先看日志docker-compose logs --tail200 worker日志里出现redis.exceptions.ConnectionError说明容器启动早于 Redis 就绪。此时在run_worker.py开头加入带重试的连接检查常见做法是用一个简单的循环每两秒尝试执行一次 Redis PING最多尝试三十次。也可用depends_on的condition: service_healthy但需要在 Redis 服务里定义healthcheck相对麻烦。故障二抓取速度低但 CPU 占用也不高。用docker stats看每个容器的资源使用如果 worker 的 CPU 长时间低于 30%瓶颈多半在目标网站的响应上。此时调低CONCURRENT_REQUESTS或提高DOWNLOAD_DELAY反而更稳因为网络等待占据了绝大部分时间。故障三MySQL 写入延迟过高。断开 saver 容器单独测试确认是executemany语句的问题还是数据库连接池耗尽。常见修复是提升 saver 的批量阈值例如攒到 500 条再写入一次或者增加 saver 的副本数量。写库失败时Redis 的结果队列不会丢数据等 saver 恢复后自动续跑。5.3 进阶在 worker 中通过环境变量切换目标站点同一个镜像部署多套环境很常见比如一套连测试库、一套连正式库。把不同的Scrapy启动参数变成环境变量用os.getenv读取再在 compose 文件里为不同服务设置environment。这样只需要一个镜像就能通过变量切换目标集合、数据库名和logging级别。避免为每个环境单独打镜像既省时间也少维护一个 Dockerfile。本文还有配套的精品资源点击获取
