基于Docker的分布式爬虫服务：架构、编排与踩坑实战

简介一份基于Docker的分布式爬虫服务项目资料面向Python与爬虫方向的学习者、毕业设计及课程设计使用者。资源以Go语言实现核心爬虫服务配套Docker容器化部署方案涵盖单机抓取、客户端调用、服务端调度等完整模块适合需要快速搭建分布式爬虫体系或进行二次开发的场景。包内共11个文件以go源码、dockerfile、shell脚本、proto接口定义及Markdown说明文档为主压缩包仅311KB目录结构清晰便于对照阅读和部署实践。目前已有54人学习下载。资料附有项目授权码与运行测试记录代码经过验证可正常使用文档部分包含构建镜像脚本、爬虫协议定义及示例程序能帮助使用者理解容器化环境下分布式爬虫的启动流程与调用方式也可作为课设、毕设演示或初学者的进阶参考。1. 基于 Docker 的分布式爬虫服务是什么为什么说它是工程组合而不是新框架把基于docker的分布式爬虫服务这几个词拆开看它并不是某个新框架而是一套工程组合调度器、抓取节点、消息队列、存储各自跑在容器里用 docker compose 统一编排需要更多吞吐时多拉一个 worker 容器就完事。它要解决单机爬虫的两类老大难一是环境不一致换台机器依赖装到怀疑人生二是单机并发撞天花板任务一多全部堵在同一个进程里。适合已经写过多线程或 scrapy 抓取脚本、准备上规模但不想把运维搞重的团队也适合想把手写脚本改造成可扩展架构的个人。下面按我自己的落地习惯把这套服务的组件拆分、编排方式、参数配置和踩坑记录一次讲清楚。2. 拆解四个容器角色调度、抓取、队列、存储谁该独立跑分布式爬虫和多线程爬虫的最大区别是把抓取流程切成几个独立进程彼此不共享内存只通过 Redis 这类消息通道通信。这样切的好处是任何一个进程死了别的进程照常工作任何一个进程压力大了就多拉一个容器分摊。四个角色里最容易被忽视边界的是调度器和 worker很多人把它们混在一个进程里写结果一发任务整个进程卡死。下面四个角色是我在文档里最优先固定下来的。2.1 调度器定时触发、任务分发与分布式锁调度器的职责不是抓网页而是决定什么任务、什么时候、交给谁。它在容器方案里一般有两种形态。第一种是纯队列型调度器定时把种子 URL 和增量 URL 写入 Redis 队列worker 从队列里取任务。这种形态的调度器本身不带状态挂了重启就好不会造成重复分发实现最简单我推荐新项目从这里起步。第二种是带状态型调度器维护一张任务表记录每个任务的 pending / running / failed / retry 状态同时用 Redis 的 SET 来维护已抓取 URL 去重表。这时候如果调度器容器被扩容成两个副本两个调度器可能同时把同一个任务派发出去就必须引入 Redis 分布式锁。常见的做法是用 SETNX 抢一个带过期时间的锁谁抢到谁负责本轮派发到期自动释放避免死锁。这是资料里的核心设计点也是面试里常被追问的分布式锁使用场景在爬虫工程里的实际落地。调度频率一般写在定时任务里容器方案里用 cron 表达式决定每 5 分钟、10 分钟还是一小时刷新一次。这里有个容易忽略的点容器默认是 UTC 时区cron 里的0 8 * * *指的是 UTC 时间 8 点不是北京时间 8 点。时区问题可以靠设置 TZ 环境变量解决后面踩坑章节会再说但调度器设计文档里最好一开始就写明所有定时表达式统一使用 Asia/Shanghai否则等线上任务每天错峰跑起来你会在 8 点和 16 点的数据差异里浪费整整一个上午。2.2 抓取节点 worker无状态才能随便扩容worker 是整个系统里唯一真正发起 HTTP 请求的容器。它的内部链条通常是从 Redis 取 URL、发送请求、解析响应、提取结构化数据、把数据写入存储。这个链条上不能保存任何本地状态比如下一个 URL 是什么这个任务跑到第几页了这些都必须放回 Redis 或数据库。为什么因为一旦 worker 被调度到别的机器、或者容器被杀掉重建状态就丢了。无状态是水平扩展的前提这也是为什么 worker 镜像本身的构建必须可重复同一个镜像在任何机器上拉起来行为完全一致。worker 镜像的选择直接影响镜像大小和稳定性。纯文本抓取用python:3.11-slim就够装上 requests、parsel 和 redis 客户端。如果需要渲染 JavaScript常见的做法是使用 playwright 或 selenium但要在 Dockerfile 里额外安装 chromium 的系统依赖镜像会从几百兆膨胀到 2GB 以上worker 的内存占用也会从一两百兆跳到 1.5GB 起。我一般建议把纯抓取和 JS 渲染拆成两种 worker 镜像用不同队列名隔开而不是塞进同一个进程否则一个页面渲染慢会拖垮整批纯文本任务。worker 消费 Redis 队列时常见做法是 BRPOP 阻塞读取超时设为 5 到 10 秒拿到空结果继续循环同时打印心跳日志方便判断 worker 是否还活着。注意不要用 LPOP 加 sleep 的方式在高吞吐下它会多出大量空轮询Redis 的 CPU 会被无意义地打高这一点在线上一旦队列长度上到几十万差异非常明显。2.3 队列与存储中间件选型和数据落库怎么分工队列是整个系统的黑匣子。我见过太多分布式爬虫项目代码里直接往 Redis 里 push 一个字符串就当队列用了等任务量上来才发现问题。对于文档里的架构设计我会明确这样定义任务队列用 Redis List生产端 RPUSH 写入消费端 BRPOP 读取。按优先级分配时改用 Sorted Set用 ZADD 写入、ZRANGEBYSCORE 弹出score 即优先级。普通爬虫场景用 List 就够了别一开始就上 Kafka那会把架构复杂度抬高一个量级。去重用 Redis Set 或布隆过滤器。URL 数量在百万以下用 Set精确无误URL 数量过千万考虑布隆过滤器缺点是实际存在的 URL 也可能被过滤掉出现少量漏抓误判率参数通常设置在 0.001 到 0.0001 之间。存储选择取决于数据用途结构化业务数据进 MySQL 或 PostgreSQL检索需求多进 Elasticsearch网页快照、图片、CSS/JS 文件进 MinIO 或本地对象存储。队列和存储都应该拆成独立的 compose 服务尽量不要和 worker 放同一个容器。原因很简单Redis 崩了worker 和调度器只是堵住数据不丢如果 Redis 和 worker 同生共死崩溃时连日志和现场都留不下来排错根本没有抓手。此外队列的持久化策略要显式开启用 AOF 或 RDB 至少保住一种。Redis 容器一崩溃内存里没来得及落盘的任务会全部丢失这种队列堆积后重启全丢的翻车现场我遇到过不止一次从那以后我对任何不带持久化的队列服务都保持警惕。2.4 文档该怎么组织这份资料包里应有的四份关键内容标题既然叫详细文档资料齐全一份合格的资料包应该覆盖四类内容架构说明、部署手册、配置清单、排错记录。架构说明里至少要有上面的角色图、职责边界和数据流部署手册要从零开始包括 docker 安装、compose 文件、启动命令、验证步骤配置清单要把每个环境变量、参数的作用列成表格让人能对着改而不需要翻代码排错记录则按现象归类方便后人检索。我自己的习惯是如果部署手册写不出从一台干净机器到跑通任务这条链路这份文档就是不合格的。所谓资料齐全不是文件多而是每个文件都能回答一个具体问题。3. 用 docker compose 跑起最小分布式爬虫集群从编排文件到首次扩容理论讲完直接给一个最小可运行方案。下面这个方案包含四个服务Redis 队列、调度器、worker、MySQL全部由 docker compose 管理。这套配置我在本地和一台 4C8G 的服务器上都跑过是可以作为脚手架复用的后面所有参数调整都以它为基础。3.1 最小 compose 文件服务划分与启动顺序常见的做法是项目根目录放一个 docker-compose.yml四个服务各占一段。下面这份是最精简的版本version: 3.8 services: redis: image: redis:7-alpine command: redis-server --appendonly yes --maxmemory 512mb restart: always ports: - 6379:6379 mysql: image: mysql:8.0 environment: - MYSQL_ROOT_PASSWORDroot123 - MYSQL_DATABASEcrawler volumes: - mysql_data:/var/lib/mysql restart: always scheduler: build: ./scheduler depends_on: - redis environment: - REDIS_HOSTredis - SCHEDULE_CRON*/10 * * * * restart: always worker: build: ./worker depends_on: - redis environment: - REDIS_HOSTredis - CONCURRENT_REQUESTS8 - DOWNLOAD_DELAY1 restart: always volumes: mysql_data:说明几个关键参数。redis 的 command 里同时挂上了 AOF 持久化和内存上限--appendonly yes保证队列数据不丢--maxmemory 512mb防止爬虫任务暴增时 Redis 吃光宿主机内存restart: always让容器在异常退出后自动拉起这是生产环境的基本要求。MySQL 的MYSQL_DATABASEcrawler会在首次启动时自动建库省去手动建库的步骤。scheduler 和 worker 都用build: ./scheduler、build: ./worker的形式意味着它们需要各自的 Dockerfile 在本地构建。这里要特别注意depends_on只保证容器启动顺序不保证 Redis 已经可以接收连接所以应用代码里必须做重连否则容器起来时 Redis 还在初始化worker 就会反复报连接错误。3.2 worker 镜像的 Dockerfile安装、依赖与启动细节worker 的 Dockerfile 是整个项目里最值得花心思写的文件因为它决定了每次代码变更后重建镜像的速度以及容器跑起来后的可观测性。FROM python:3.11-slim WORKDIR /app COPY requirements.txt /app/requirements.txt RUN pip install --no-cache-dir -r /app/requirements.txt \ -i https://mirrors.aliyun.com/pypi/simple/ COPY . /app ENV PYTHONUNBUFFERED1 CMD [python, worker.py]这里有两个我一直坚持的细节。第一COPY requirements.txt和pip install放在COPY . /app之前是为了利用 docker 的层缓存只要 requirements.txt 没变重建镜像时 pip install 这一层不会重跑构建速度会有肉眼可见的提升代码每次变动只重建最后那一层。第二PYTHONUNBUFFERED1让 Python 日志实时输出到容器 stdout否则 docker logs 看到的日志会滞后甚至丢失排错时会非常被动。pip 换阿里云镜像源解决的是构建速度问题如果构建环境访问外网稳定这一步可以省略但保留代价很低我一般不会省。requirements.txt 里最少要有requests、parsel、redis、pymysql。如果用 scrapy 框架则加上 scrapy 和 scrapy-redis。scrapy-redis 本身已经把从 Redis 取 URL、结果去重这套逻辑封装好了可以少写一半代码代价是它的调度策略偏通用遇到自定义去重或优先级需求还是要自己改。注意不要把所有依赖一股脑装进镜像每个角色单独一个镜像调度器镜像甚至可以只用 redis 客户端加定时任务脚本体积会比 worker 小很多启动也快。3.3 启动、验证与扩容三步确认集群真的在干活编排文件和 Dockerfile 都准备好了接着就是启动。第一步先把全部服务拉起来# 启动全部服务 docker compose up -d # 查看四个容器状态 docker compose ps # 跟 worker 日志确认是否在消费 docker compose logs -f worker启动后先看容器状态确认 redis、scheduler、worker 都是 Up 而不是 Restarting。Restarting 说明容器启动后立即崩溃最常见的元凶是代码里 Redis 连接配置没写对。然后手动往队列里塞一个测试 URL模拟一次真实调度docker compose exec redis redis-cli RPUSH crawl_queue https://example.com接着观察 worker 日志如果看到请求成功、解析出字段、写入数据库说明这条链路已经通了。最后一步是扩容验证docker compose up -d --scale worker3扩容后 worker 变成三个容器Redis 队列里的任务会被三个 worker 并行消费。去docker stats观察各容器的 CPU 和内存确认资源没有被瞬间打满。如果数据正常落库、队列长度在下降链路就真正成立了。这里要强调一个很常见的认知偏差一扩容就以为自己是分布式了。如果调度器只有一个进程、Redis 也是单容器那集群依然是单点扩容只解决了抓取侧的吞吐调度和队列的短板还在等任务量再涨一轮瓶颈会转移到 Redis 或数据库上。3.4 MySQL 容器初始化慢导致的连接失败启动顺序的隐藏坑第一次启动时MySQL 8 容器要做初始化快的一分钟慢的要两三分钟期间 3306 端口虽然已打开但服务并没有就绪。如果 worker 启动得比 MySQL 快就会反复报错Cant connect to MySQL server on mysql (111)这不是配置写错了是启动顺序问题。我一般建议给 MySQL 加健康检查在 compose 的 mysql 服务里配置 healthcheck再让 worker 的 depends_on 增加 condition。如果用的是偏老版本的 compose 引擎对 condition 支持不好那就退一步在 worker 的代码里做启动等待连接失败时指数退避重试最多等 60 到 90 秒。这个坑几乎每个第一次搭这套方案的人都会踩值得写进部署手册的显眼位置不然排查方向会一路偏到防火墙和网络配置上去。4. 抓取效率参数怎么调并发、间隔、重试与去重的合理区间架构通了之后性能就到了参数调优阶段。这一章的参数按影响面从明显到隐晦排序覆盖 worker 进程、Redis 和任务生命周期。每个参数都不是独立存在的改一个往往要连带看另外两三个下面的表格是我验证过的基线组合。4.1 并发与请求间隔参数组合决定快慢也决定会不会被封worker 容器内部一般会维护一个线程池或协程池。以 requests 加线程池为例核心参数是并发数CONCURRENT_REQUESTS和请求间隔DOWNLOAD_DELAY。我的基线经验值如下参数推荐值说明CONCURRENT_REQUESTS8 - 32单容器并发数内网资源站可高公网站建议从 8 起步DOWNLOAD_DELAY1 - 3 秒单 worker 内两次请求的最小间隔公网站建议不少于 1DOWNLOAD_TIMEOUT10 - 20 秒连接和读取总超时动态站点需要放大到 30RETRY_TIMES2 - 3 次超过 3 次重试的边际收益很低反而放大对目标站的冲击RETRY_HTTP_CODES500,502,503,5044xx 错误通常不值得重试重试了也是白搭这几个参数不能孤立地看。并发 32 加上间隔 1 秒一个 worker 的瞬时 RPS 并不会高到哪里去因为每个请求之间至少要等一个间隔并发高、间隔小对目标站的访问节奏会非常密集容易触发反爬被限流后再想恢复就很难。另一个容易忽略的是文件描述符限制并发开到 64 以上时容器内会报Too many open files需要在 compose 里给服务加上ulimits把 nofile 提到 65535。这不是玄学是内核的硬限制压测时几乎必然会碰到。请求间隔我强烈建议加一点 jitter也就是随机偏移。比如基础间隔 1.2 秒实际等待 0.8 到 1.6 秒之间随机这样抓下来的请求时间分布更像真人浏览。如果写成固定的 1 秒Web 服务器的访问日志会呈现非常规律的等间距脉冲这是最容易被识别出来的机器特征之一很多风控系统第一个盯的就是这种节奏。4.2 Redis 去重与分布式锁不重复抓取比抓得快更重要分布式爬虫最怕的不是抓不到数据而是重复抓。一个 URL 被两个 worker 同时抓到解析结果写两次库业务侧再去重非常痛苦。所以去重要在任务分发之前完成而不是入库之后。一个简单实用的去重方案调度器在把 URL 写进 Redis 队列之前先执行SADD hashed_urls url_md5。返回值是 0 说明这个 URL 已经存在跳过返回值是 1 说明是新 URL再 RPUSH 进队列。这段逻辑最好用 Lua 脚本原子完成避免两个调度器同时判断不存在然后同时入队。Python 里的等价写法如下import redis import hashlib r redis.Redis(hostredis, port6379) def push_new_url(url: str) - bool: url_hash hashlib.md5(url.encode()).hexdigest() added r.sadd(seen_urls, url_hash) if added: r.rpush(crawl_queue, url) return bool(added)上面这段逻辑里sadd返回 1 才入队天然解决了重复调度问题。如果调度器存在多个副本还需要在更外层加分布式锁常见做法是SET lock_key value EX 30 NX抢到锁的调度器才执行批量派发。任务量大、单次派发超过 30 秒时要记得续租锁的时间不然两个调度器会在锁过期后重叠派发。这个锁还没干完就过期的坑在长任务里非常常见而且很难通过日志定位因为两次派发间隔时间不长数据层面看起来只是偶发的重复。去重表seen_urls要不要设置过期策略我的经验是不要轻易给整个 key 设置 TTL。TTL 设为 7 天7 天后爬虫可能重复抓取旧内容TTL 设为 30 天内存又会被撑爆。更合理的做法是按天给 key 加后缀比如seen_urls_20250218每天自然过期同时保证短期内不重抓。如果项目对数据时效性要求不高甚至可以保留 30 天的去重 key用定期任务在凌晨清理。4.3 重试策略与失败任务回收队列里躺着的任务不一定是已完成的每个任务在队列里消失之前可能经历多次重试、超时、手动丢弃。我习惯在设计文档里画一张任务状态流转表把每个状态的可观测性和恢复路径写清楚状态判定条件处理动作pending已入队未消费无需处理等待 workerrunningworker 已取走处理中超过 DOWNLOAD_TIMEOUT 的 3 倍仍未完成判定为超时任务重新入队failed重试次数用尽写失败日志生产中把失败 URL 存到单独的 Redis List便于复盘ignored4xx 或明确反爬响应直接丢弃并为反爬写入告警重试参数的选取逻辑是连接超时 5 秒、读超时 10 秒、重试 3 次退避时间按 2 的幂次递增并加 random jitter即第一次等 2 秒第二次 4 秒第三次 8 秒。这个组合下单个 URL 最长等待约 35 秒不会让 worker 卡在一个失败任务上太久。反爬类 403 响应不值得重试直接进 failed 队列交给人工分析更省事重试只会让目标站更早把你的 IP 拉黑。4.4 参数验证方法用一个小任务验证并发和延迟的实际效果参数不是调完就完事的要拿真实验证。我会做两件事。第一构造一个有 50 到 100 个 URL 的小任务集用docker compose scale worker3跑一遍记录总耗时、每秒完成数、失败数在 worker 日志里打印每个请求的开始和结束时间戳确认并发确实提升了吞吐而不是把资源吃满导致互相排队。第二用LLEN crawl_queue观察队列积压曲线。任务量峰值时队列长度在下降说明消费速度大于生产速度如果持平或上涨说明 worker 数不够或者单个 worker 的并发已经触顶。验证的时候一定要留记录不然下一次调参就忘了当前基线是多少。5. 容器化分布式爬虫的高频踩坑排查从 docker api 权限到队列堆积任何一套跑起来的服务真正拉开差距的是排错能力。这一章挑了五条最常遇到的坑全部按现象、原因、解决三段式展开。每一条都是我自己或身边同事踩过的真实场景写成文档时也建议照这个结构来后人查起来最快。5.1 docker api permission denied新机器上第一条命令就翻车现象在 Ubuntu 上执行docker compose up -d报错permission denied while trying to connect to the Docker daemon socket连docker ps都跑不了。原因Docker 安装完成后docker 组里默认没有当前用户。只有 root 或 docker 组成员才有权限访问 /var/run/docker.sock。很多安装教程只帮你装了 Docker没帮你加用户组所以加 sudo 就能跑不加 sudo 全部被拒。解决执行sudo usermod -aG docker $USER然后重新登录一次让用户组生效。这里不要用newgrp docker糊弄了事重新登录才最稳。另外不要在同一条命令里混杂sudo docker和普通dockersudo 环境下的 HOME 变量和配置经常带来另一类说不清的权限问题保持命令风格统一。5.2 镜像下载慢、构建超时依赖源决定了你的构建体验现象docker build或docker pull卡在下载阶段pip install 报 timeoutapt-get update 慢到像死机长时间构建后直接失败。原因默认的 pip 源、apt 源和 Docker Hub 都在境外国内网络环境下访问这些源不稳定。镜像下载慢几乎成了 docker 爬虫项目的第一道门槛很多人误以为是机器性能差其实只是网络路径的问题。解决在 Dockerfile 里把 pip 源换成阿里云或清华的镜像源apt 换对应发行版的国内源docker pull 阶段在/etc/docker/daemon.json里配置 registry-mirror然后重启 docker 使配置生效。构建时不要手写死版本号用或~组合可以避免某些包被迫重下虽然这不直接解决源慢但能减少无意义的构建层刷新。5.3 worker 频繁被 OOM KillJS 渲染场景的内存账要提前算现象worker 容器运行十几分钟后进程消失docker logs里没有错误堆栈docker inspect的 State 显示 OOMKilled 为 true宿主机 dmesg 里能看到 oom-killer 的记录。原因加载了 playwright 或 chromium 的 worker每个并发浏览器实例大约占 300 到 600 兆内存。如果容器 memory limit 设为 1GB而并发设成 4内存早就超了。普通文本抓取的 worker 内存占用不到 100 兆于是很多人把内存限制设得很小换了渲染型任务就翻车。解决在 compose 里给渲染型 worker 单独预留资源例如mem_limit: 4g并发按每实例约 500M倒推4G 内存上限下并发不要超过 6。同时确保被杀掉之前把当前任务标记为 pending 重新入队避免 OOM 导致任务丢失。如果目标是大型页面还可以在请求阶段拦截图片、字体、CSS 等非关键资源能省下三成内存代价是页面样式相关的解析字段可能拿不到需要按业务取舍。5.4 Redis 队列堆积但 worker 闲置key 不一致和阻塞超时现象查LLEN crawl_queue发现任务数持续上涨但 worker 日志长时间没有输出像死了一样docker stats 显示 worker 的 CPU 几乎为零。原因最常见的是调度器写入的 key 是task_queueworker 读的是crawl_queue两边配置不一致任务进了 Redis 但 worker 永远读不到。其次是 worker 的消费循环写成了BRPOP queue 0第二次调用时被 Redis 连接池里失效的连接卡住没有重连逻辑。解决把队列 key 统一放到一个环境变量QUEUE_KEY里调度器和 worker 都从环境变量读避免硬编码。消费循环里给 BRPOP 设置 5 秒超时每次超时后打印心跳日志确认循环还活着 Redis 连接初始化时开启 socket_timeout并捕获连接异常做重连。加上这两条队列堆积就会变成可观测问题要么日志在跳要么队列在降不会再出现两个系统各自安好的假象。5.5 容器时区与 MySQL 连接初始化两个和时间有关的隐蔽问题现象调度器设置的每天 8 点抓取实际在下午 4 点才触发容器内date显示 UTC 时间。同时MySQL 容器第一次启动后worker 一直报Cant connect to MySQL server过两分钟自己又好了。原因容器镜像默认使用 UTC 时区cron 表达式没有做时区转换MySQL 第一次初始化数据目录需要一分钟以上期间 3306 端口虽然已打开但服务不可用。这两个问题单独看都不难问题在于报错信息都不直接非常容易被当成网络故障去排查。解决compose 里给所有服务统一设置TZ: Asia/Shanghai并在调度器代码里用系统时区解析 cron 表达式。MySQL 初始化慢的问题在 worker 启动逻辑里增加最长 90 秒的连接重试或者用 compose 的 healthcheck 判断 MySQL 真正就绪后再启动 worker。这些细节写进部署手册能让后来的人少走一整天弯路。6. 从能跑到稳跑三个监控指标、一套压测方法与一条扩展路径集群能跑通只是第一步稳定运行才是持续投入的前提。我的做法是先选三个最简单的指标抓取成功率、队列积压长度、容器重启次数。成功率小于 95% 时先看是不是触发反爬LLEN 持续上涨时加 worker容器重启次数大于 0 时优先查 OOM 和崩溃日志。这三个指标不需要一上来就上 Prometheus一个脚本每分钟采样一次写进日志或表格就够了。趋势出现时再决定要不要上 Grafana。分布式爬虫的体系越是复杂越要保持每个指标都可解释否则你扩了容也不知道它为什么快、缩了容也不知道它为什么慢。压测方法我也固定成一条路径准备 200 个 URL从单 worker 跑 5 分钟记录基准 RPS然后依次 scale 到 3、6、12 个 worker分别统计吞吐曲线。如果吞吐不随 worker 数线性增长瓶颈大概率在 Redis 单线程或目标站带宽再往上堆 worker 只会增加无效请求。我的习惯是每次压测都留一份记录注明日期、worker 数、队列积压曲线这样下次调参有据可查而不是靠感觉拍脑袋。扩展路径上只建议一个方向先横向加 worker再拆分代理池最后才考虑跨主机编排。跨主机可以先用 docker swarm 把 compose 文件原样跑在多台机器上任务量再大才迁移到 k8s不要为了排面第一天就上 k8s。说一个我自己的血泪教训早期我把调度器也 scale 成两个副本没有加分布式锁结果同一批种子 URL 被派发两次MySQL 里多了一倍的重复数据清洗花了整整两天。那次之后我给自己定了一条规矩任何一次扩容动作先写进文档再动命令。分布式爬虫服务最贵的不是机器而是它悄悄重复劳动时你毫无察觉的运维时间。希望帮到你。本文还有配套的精品资源点击获取