做爬虫的人早晚会遇到一个尴尬的时刻小规模抓取时用脚本一把梭怎么都行一旦页面量上了几百上千运行过程中请求超时、解析报错、机器重启任何一个小问题都可能让整条抓取链路中断然后所有数据作废。这篇博文要聊的就是我从零构建的一套高可用静态网页抓取管道。它不像Scrapy那样需要学习框架本身的调度机制也不像临时脚本那样跑一次就扔而是用最朴素的Python工具把“发请求、解析页面、存数据”拆成一条能断点续跑、能并发加速、能应对常见异常的流水线。适合刚入门爬虫但已经写过几个小脚本、准备往工程化方向靠的同学。核心就一句话把一次性脚本改造成可恢复、可观测、可并发执行的抓取管道。下面整个过程我尽量按实操顺序展开能直接抄作业的代码会放出来踩过的坑也会标注清楚。1. 项目概述与整体设计思路1.1 静态网页抓取到底在做什么静态网页指的是内容由服务器直接渲染在HTML里、不依赖JavaScript二次加载的页面。这类页面的抓取逻辑很直观拿到URL用HTTP请求把HTML下载下来解析出需要的字段存进数据库。听起来简单但真正跑起来会发现一堆杂音——有的页面返回500有的超时有的结构里混着广告位干扰解析还有的站点会临时封掉频繁访问的IP。我这次处理的是一个典型的静态资讯站点归档任务需要抓取若干栏目下的列表页和详情页总量大概两万个页面。最初用一个requests循环逐个抓取跑到第三百多个页面时一个网络抖动把进程带崩了之前抓过的数据没有落盘只能重来。那时候我就意识到爬虫工程化不是为了炫技而是为了在真实网络环境下让任务能扛住意外、能追得回来。1.2 为什么是“管道”而不是“脚本”管道的核心特点是每个环节独立、环节之间通过明确的数据接口连接、整体状态可以随时掌握。对应到爬虫就是任务队列、下载器、解析器、存储四层分离。脚本式写法最大的问题在于职责混杂一个函数里既发请求又解析又写库任何一个环节出错整个任务就得从头再来而且看不到当前进度。管道式设计则把每个环节拆开各自处理自己的异常任务状态被持久化哪怕是程序崩溃重启后也能从断点继续。对我来说“高可用”的定义并不是7x24小时不宕机——那是运维层面的意思——而是任务在崩溃、报错、中断之后仍然能以最小的代价恢复并跑到最终完成状态。2. 核心组件拆解与技术选型2.1 requests BeautifulSoup最务实的组合选型这件事我一直觉得“够用且自己熟悉”比“功能强大”更重要。抓取静态页面requests足够可靠连接超时、读取超时、会话复用这些基础能力都具备BeautifulSoup解析HTML虽然不是最快的但API设计对新手极其友好find和select的表达式写起来很顺。有些场景下lxml的XPath效率确实更高但如果页面结构不算复杂BeautifulSoup的容错性反而帮你少踩很多坑——HTML标签不闭合、属性带奇怪空格这类脏数据它对处理的宽容度更高。我在管道里统一用BeautifulSoup的lxml解析器速度和容错比较平衡。2.2 重试、限速与代理策略高可用管道必须预设一个前提网络请求一定会失败。既然一定会失败就要设计失败后的行为。重试机制选择性地在requests的HTTPAdapter中配置Retry策略是可行的但更灵活的做法是自己封装一个带重试的fetch函数针对不同的异常类型执行不同的重试次数和退避策略。限速是我在早期脚本里最容易忽略的部分。很多静态站不会一开始封你而是突然在某个阈值触发保护。实践证明每请求之间增加一个随机的延时比任何花哨的反反爬技巧都管用。我这里会配合一个简单的延时队列让请求间隔在0.5到1.5秒之间随机波动。至于代理池普通任务根本用不上。我只有在目标站点明确限制同一IP并发或频率时才引入代理而且优先使用自己可控的代理资源。市面上那些免费代理稳定性很差很可能导致抓取成功率反而下降得不偿失。2.3 数据存储SQLite起步SQLAlchemy留后路抓下来的数据总得有个归宿。对两万页级别的任务SQLite完全够用单文件、零部署、支持事务断电崩溃也不会轻易坏库。唯一要注意的是写入并发——SQLite同一时间只允许一个写者所以如果后续要上多线程写入就必须在写入层加锁或使用队列串行化。我用SQLAlchemy作为ORM并不单纯为了SQLite更多是给未来迁移MySQL或PostgreSQL留一条平滑路径。在这套管道里ORM还起着一层“数据校验”的作用表结构定义了字段类型和约束解析器传进来的数据如果缺字段或类型不对在写入阶段就会暴露问题而不是等分析时才发现脏数据。3. 实操过程从零搭建抓取管道3.1 环境准备与依赖安装搭建这套管道Python版本我建议3.9以上3.11更佳。依赖就四个核心库requests、beautifulsoup4、lxml、sqlalchemy。另外推荐加上tqdm做进度展示、loguru做日志输出——这两个不是必需品但对可观测性的提升非常直观。安装命令很简单pip install requests beautifulsoup4 lxml sqlalchemy tqdm loguru项目的基本目录结构我会分成几个模块main.py负责启动与调度fetcher.py负责请求和重试parser.py负责HTML解析storage.py负责数据写入models.py放ORM表定义queue.py管理任务队列与去重。很多人写爬虫喜欢把所有逻辑塞进一个ipynb或者一个py文件两三百行还能忍受管道化之后还是建议拆开至少为了出问题时能快速定位。3.2 任务队列与去重设计管道运转的第一步是喂入初始URL列表。我这里的URL来源是栏目页分页规则可以程序化生成。在管道里任务队列不是一个内存list而是一个带状态的表结构。每条任务记录包含url、状态、重试次数、抓取时间、更新时间。状态枚举就四类pending、processing、done、failed。这么设计的好处很直接程序启动时查询有多少pending任务就知道从哪里继续处理中的任务如果因为崩溃没来得及更新状态启动时通过一个“超时恢复”机制把它重置回pending即可。去重则依靠url的唯一索引数据库层面兜底不需要额外引入Redis。用SQLite做任务队列的注意事项是并发写锁多个线程同时更新不同记录也可能触发“database is locked”。我的做法是让写队列的操作统一走单线程或者利用SQLAlchemy的连接池配合写锁把并发写控制在安全范围内。3.3 核心抓取与解析代码解析fetch函数是整个管道的心脏。我封装了proxies、headers、超时、重试逻辑统一出口返回HTML文本。核心参数按以下方式设计import random import time import requests from requests.adapters import HTTPAdapter session requests.Session() adapter HTTPAdapter(pool_connections20, pool_maxsize20, max_retries0) session.mount(http://, adapter) session.mount(https://, adapter) def fetch(url, max_retries3): headers { User-Agent: random.choice(USER_AGENTS), Accept-Language: zh-CN,zh;q0.9, } for attempt in range(max_retries): try: resp session.get(url, headersheaders, timeout(5, 15)) if resp.status_code 200: return resp.text elif resp.status_code in (403, 429): time.sleep(10 random.random() * 5) continue else: resp.raise_for_status() except (requests.Timeout, requests.ConnectionError) as e: wait 2 ** attempt random.random() * 2 time.sleep(wait) return None解析部分按栏目页和详情页分开。栏目页需要提取出详情页链接以及下一页URL详情页则提取标题、发布时间、正文。每个解析函数只负责解析返回结构化字典不做存储。这样修改站点模板时只需替换对应的解析函数。from bs4 import BeautifulSoup def parse_detail(html): soup BeautifulSoup(html, lxml) title soup.select_one(h1.article-title) pub_time soup.select_one(span.pub-time) content soup.select_one(div.article-content) if not all([title, content]): raise ValueError(关键字段缺失) return { title: title.get_text(stripTrue), pub_time: pub_time.get_text(stripTrue) if pub_time else None, content: content.get_text(\n, stripTrue), }3.4 异常处理与状态标记异常这块我要求所有可能失败的环节都必须显式处理不允许静默吞异常。HTTP层的超时、连接错误在fetch内部处理解析层抛出的ValueError在调度层捕获并把任务状态标记为failed存储层的数据库异常需要记录日志避免数据半截入库。还有一个容易被忽略的点同一个页面在解析过程中如果一半成功一半失败数据落库就会出现残缺。我的策略是解析结果先放在一个内存对象里所有字段都校验通过后再统一写入数据库一笔事务提交避免半成品数据污染结果表。4. 高可用细节并发、断点续抓与监控4.1 并发模型选择两万页面若单线程跑每个请求带延时平均1秒需要五个半小时以上。这个速度太磨人管道改造的收益很大一部分来自并发。并发模型我推荐ThreadPoolExecutor而非用asyncio。原因很实际静态网页抓取是IO密集型任务线程池写起来直观配合requests的阻塞调用几乎零心智负担asyncio虽然并发性能更好但需要把所有IO调用改成异步代理配置、超时处理、调试成本都高一截。线程数量不需要贪多8到16个是常见甜点区间。开三五十个线程对远程站点压力很大也容易把自己的内存耗在连接池上。实践中我用10个线程跑两万页面抓取时间压缩到70分钟左右成功率在99%以上。from concurrent.futures import ThreadPoolExecutor, as_completed def run_pipeline(): with ThreadPoolExecutor(max_workers10) as executor: futures [] for task in get_pending_tasks(): futures.append(executor.submit(process_task, task.id)) for future in as_completed(futures): future.result()4.2 断点续抓与去重策略断点续抓的实现核心就是任务状态表。每次处理任务前先把状态置为processing成功完成后置为done失败则置为failed并记录error信息。程序启动时只拉取pending和failed的任务失败任务会重新进入处理队列。这里要注意设置一个最大重试次数比如3次超过后保持failed状态不再自动拾取避免陷入无限重试的死循环。去重除了任务表本身的url唯一索引还可以在结果存储表上也加唯一键。比如标题发布时间组合防止同一个详情页被不同栏目页重复收录时产生重复数据。这个设计在归档任务中尤其重要因为列表页翻页时经常出现同一篇文章被挂在多个栏目下的情况。4.3 优雅退出与进程恢复高可用管道的最后一环是进程级容错。当程序收到SIGINT或SIGTERM信号时我正在处理的请求不能直接中断否则会留下半截processing状态的任务。我的处理方案是捕获退出信号设置一个全局的shutdown_flag所有线程在完成当前任务的瞬时检查该标记如果被置位就不再领取新任务待已领取任务执行完后再关闭线程池。进程崩溃则交由任务恢复机制兜底。启动时扫描所有状态为processing且最后更新时间早于当前时间三分钟的任务强制重置为pending。“三分钟”的阈值要大于单个任务的最大耗时避免正在处理的任务被误重置。这个机制很朴素但恰好合适不需要引入celery或supervisor这类重工具。4.4 日志与进度观测管道跑起来之后观察它的状态和观察业务系统同样重要。我用loguru把日志分成信息日志和错误日志。信息日志每隔一段时间输出已抓取数量、失败数量、当前速度和预计剩余时间错误日志则完整记录异常堆栈和关联的url。进度展示上tqdm配合任务队列的实时查询能显示一个动态进度条。但注意在日志系统和tqdm同时输出的情况下进度条容易和日志交错观感混乱。我会在进度条之外单独维护一个结构化日志字段统一用JSON格式输出关键指标后续不管是用awk分析还是接日志平台都很方便。5. 常见问题与排查技巧实录5.1 高频异常速查表下表整理了这套管道运行中最常遇到的问题以及对应的排查方向和处理建议。这些坑都与我在实际跑量过程中遇到的真实情况对应建议收藏。现象常见原因处理建议大量请求超时目标站响应变慢或本地连接池耗尽降低线程数调大连接池容量重试退避系数提高频繁收到403触发站点风控IP被临时限制放慢请求频率更换随机User-Agent等待恢复数据库锁异常SQLite多线程写入冲突写入任务串行化或迁移PostgreSQL解析结果缺失页面结构变更或部分字段为空解析函数先做字段存在性校验缺失则跳过详情页任务状态卡在processing进程被杀超时恢复机制没生效检查阈值时间设置确保启动扫描必执行内存缓慢增长大量响应对象未释放或队列堆积使用streamFalse默认形态及时清理抓取结果对象5.2 性能优化与抓取效率取舍抓取效率有一个明确的取舍关系速度越快对目标站的打扰越大被封的概率也越高。两万页面的任务与其追求一小时跑完被封后歇半小时不如用1.5小时平稳跑完。稳才是高可用管道的真正含义。一个比较有效的优化是接入HTTP缓存。requests-cache库可以把响应缓存到本地SQLite重复的URL直接走本地缓存对于列表页和详情页存在重叠的站点效果很明显。我在管道中给详情页解析做了二级缓存已经成功解析过的页面即使任务状态意外丢失再次拾取也能直接从结果表读取不重复请求网络。另外在IO层面可以把响应文本的编码判断写清楚。某些站点页面头部不标准requests的apparent_encoding判断会出现偏差。建议在解析层显式声明目标站点的字符集以utf-8为例可以防止中文乱码延误解析。5.3 设计管道时我最后悔没早想通的几件事第一个是持久化任务队列。我最初的单机版队列放在内存里一次重启就把任务搞丢了悔得肠子青。把任务队列放数据库后哪怕整体崩溃恢复也只需一个启动命令。这个教训让我建议所有人第一版就用SQLite做队列不要嫌麻烦。第二个是日志要打印到文件不要只打在控制台里。在终端里看到报错很容易以为记住了但真正排查时你说不清一百次失败里有多少种错误类型。文件日志配上grep就成了最简单的数据分析工具。第三个是解析函数加类型保护。不要直接信任页面给出的任何字符串尤其是时间格式有些站点会出现“1月1日”和“2025-01-01”混用的情况。我会在解析后统一转成datetime对象转换失败则返回空值并打印告警日志这样后端的校验才不会误杀数据。就我个人体会而言搭建这套静态网页抓取管道给我带来的帮助远不止两万条数据。它让我在做其他项目时也养成了“先设计状态流转再写业务逻辑”的习惯。如果你手里也有批量抓取静态页面的需求哪怕数据量暂时只有几百条按这个思路把管道搭起来后续扩容只是加线程和换数据库的问题不用推倒重写。最后分享一个实用小技巧管道写好之后先把抓取数量限制在50条跑通全流程再放开。第一次全流程跑通给你的信心比任何代码审查都管用。
从零构建高可用静态网页抓取管道：断点续跑与并发实践
做爬虫的人早晚会遇到一个尴尬的时刻小规模抓取时用脚本一把梭怎么都行一旦页面量上了几百上千运行过程中请求超时、解析报错、机器重启任何一个小问题都可能让整条抓取链路中断然后所有数据作废。这篇博文要聊的就是我从零构建的一套高可用静态网页抓取管道。它不像Scrapy那样需要学习框架本身的调度机制也不像临时脚本那样跑一次就扔而是用最朴素的Python工具把“发请求、解析页面、存数据”拆成一条能断点续跑、能并发加速、能应对常见异常的流水线。适合刚入门爬虫但已经写过几个小脚本、准备往工程化方向靠的同学。核心就一句话把一次性脚本改造成可恢复、可观测、可并发执行的抓取管道。下面整个过程我尽量按实操顺序展开能直接抄作业的代码会放出来踩过的坑也会标注清楚。1. 项目概述与整体设计思路1.1 静态网页抓取到底在做什么静态网页指的是内容由服务器直接渲染在HTML里、不依赖JavaScript二次加载的页面。这类页面的抓取逻辑很直观拿到URL用HTTP请求把HTML下载下来解析出需要的字段存进数据库。听起来简单但真正跑起来会发现一堆杂音——有的页面返回500有的超时有的结构里混着广告位干扰解析还有的站点会临时封掉频繁访问的IP。我这次处理的是一个典型的静态资讯站点归档任务需要抓取若干栏目下的列表页和详情页总量大概两万个页面。最初用一个requests循环逐个抓取跑到第三百多个页面时一个网络抖动把进程带崩了之前抓过的数据没有落盘只能重来。那时候我就意识到爬虫工程化不是为了炫技而是为了在真实网络环境下让任务能扛住意外、能追得回来。1.2 为什么是“管道”而不是“脚本”管道的核心特点是每个环节独立、环节之间通过明确的数据接口连接、整体状态可以随时掌握。对应到爬虫就是任务队列、下载器、解析器、存储四层分离。脚本式写法最大的问题在于职责混杂一个函数里既发请求又解析又写库任何一个环节出错整个任务就得从头再来而且看不到当前进度。管道式设计则把每个环节拆开各自处理自己的异常任务状态被持久化哪怕是程序崩溃重启后也能从断点继续。对我来说“高可用”的定义并不是7x24小时不宕机——那是运维层面的意思——而是任务在崩溃、报错、中断之后仍然能以最小的代价恢复并跑到最终完成状态。2. 核心组件拆解与技术选型2.1 requests BeautifulSoup最务实的组合选型这件事我一直觉得“够用且自己熟悉”比“功能强大”更重要。抓取静态页面requests足够可靠连接超时、读取超时、会话复用这些基础能力都具备BeautifulSoup解析HTML虽然不是最快的但API设计对新手极其友好find和select的表达式写起来很顺。有些场景下lxml的XPath效率确实更高但如果页面结构不算复杂BeautifulSoup的容错性反而帮你少踩很多坑——HTML标签不闭合、属性带奇怪空格这类脏数据它对处理的宽容度更高。我在管道里统一用BeautifulSoup的lxml解析器速度和容错比较平衡。2.2 重试、限速与代理策略高可用管道必须预设一个前提网络请求一定会失败。既然一定会失败就要设计失败后的行为。重试机制选择性地在requests的HTTPAdapter中配置Retry策略是可行的但更灵活的做法是自己封装一个带重试的fetch函数针对不同的异常类型执行不同的重试次数和退避策略。限速是我在早期脚本里最容易忽略的部分。很多静态站不会一开始封你而是突然在某个阈值触发保护。实践证明每请求之间增加一个随机的延时比任何花哨的反反爬技巧都管用。我这里会配合一个简单的延时队列让请求间隔在0.5到1.5秒之间随机波动。至于代理池普通任务根本用不上。我只有在目标站点明确限制同一IP并发或频率时才引入代理而且优先使用自己可控的代理资源。市面上那些免费代理稳定性很差很可能导致抓取成功率反而下降得不偿失。2.3 数据存储SQLite起步SQLAlchemy留后路抓下来的数据总得有个归宿。对两万页级别的任务SQLite完全够用单文件、零部署、支持事务断电崩溃也不会轻易坏库。唯一要注意的是写入并发——SQLite同一时间只允许一个写者所以如果后续要上多线程写入就必须在写入层加锁或使用队列串行化。我用SQLAlchemy作为ORM并不单纯为了SQLite更多是给未来迁移MySQL或PostgreSQL留一条平滑路径。在这套管道里ORM还起着一层“数据校验”的作用表结构定义了字段类型和约束解析器传进来的数据如果缺字段或类型不对在写入阶段就会暴露问题而不是等分析时才发现脏数据。3. 实操过程从零搭建抓取管道3.1 环境准备与依赖安装搭建这套管道Python版本我建议3.9以上3.11更佳。依赖就四个核心库requests、beautifulsoup4、lxml、sqlalchemy。另外推荐加上tqdm做进度展示、loguru做日志输出——这两个不是必需品但对可观测性的提升非常直观。安装命令很简单pip install requests beautifulsoup4 lxml sqlalchemy tqdm loguru项目的基本目录结构我会分成几个模块main.py负责启动与调度fetcher.py负责请求和重试parser.py负责HTML解析storage.py负责数据写入models.py放ORM表定义queue.py管理任务队列与去重。很多人写爬虫喜欢把所有逻辑塞进一个ipynb或者一个py文件两三百行还能忍受管道化之后还是建议拆开至少为了出问题时能快速定位。3.2 任务队列与去重设计管道运转的第一步是喂入初始URL列表。我这里的URL来源是栏目页分页规则可以程序化生成。在管道里任务队列不是一个内存list而是一个带状态的表结构。每条任务记录包含url、状态、重试次数、抓取时间、更新时间。状态枚举就四类pending、processing、done、failed。这么设计的好处很直接程序启动时查询有多少pending任务就知道从哪里继续处理中的任务如果因为崩溃没来得及更新状态启动时通过一个“超时恢复”机制把它重置回pending即可。去重则依靠url的唯一索引数据库层面兜底不需要额外引入Redis。用SQLite做任务队列的注意事项是并发写锁多个线程同时更新不同记录也可能触发“database is locked”。我的做法是让写队列的操作统一走单线程或者利用SQLAlchemy的连接池配合写锁把并发写控制在安全范围内。3.3 核心抓取与解析代码解析fetch函数是整个管道的心脏。我封装了proxies、headers、超时、重试逻辑统一出口返回HTML文本。核心参数按以下方式设计import random import time import requests from requests.adapters import HTTPAdapter session requests.Session() adapter HTTPAdapter(pool_connections20, pool_maxsize20, max_retries0) session.mount(http://, adapter) session.mount(https://, adapter) def fetch(url, max_retries3): headers { User-Agent: random.choice(USER_AGENTS), Accept-Language: zh-CN,zh;q0.9, } for attempt in range(max_retries): try: resp session.get(url, headersheaders, timeout(5, 15)) if resp.status_code 200: return resp.text elif resp.status_code in (403, 429): time.sleep(10 random.random() * 5) continue else: resp.raise_for_status() except (requests.Timeout, requests.ConnectionError) as e: wait 2 ** attempt random.random() * 2 time.sleep(wait) return None解析部分按栏目页和详情页分开。栏目页需要提取出详情页链接以及下一页URL详情页则提取标题、发布时间、正文。每个解析函数只负责解析返回结构化字典不做存储。这样修改站点模板时只需替换对应的解析函数。from bs4 import BeautifulSoup def parse_detail(html): soup BeautifulSoup(html, lxml) title soup.select_one(h1.article-title) pub_time soup.select_one(span.pub-time) content soup.select_one(div.article-content) if not all([title, content]): raise ValueError(关键字段缺失) return { title: title.get_text(stripTrue), pub_time: pub_time.get_text(stripTrue) if pub_time else None, content: content.get_text(\n, stripTrue), }3.4 异常处理与状态标记异常这块我要求所有可能失败的环节都必须显式处理不允许静默吞异常。HTTP层的超时、连接错误在fetch内部处理解析层抛出的ValueError在调度层捕获并把任务状态标记为failed存储层的数据库异常需要记录日志避免数据半截入库。还有一个容易被忽略的点同一个页面在解析过程中如果一半成功一半失败数据落库就会出现残缺。我的策略是解析结果先放在一个内存对象里所有字段都校验通过后再统一写入数据库一笔事务提交避免半成品数据污染结果表。4. 高可用细节并发、断点续抓与监控4.1 并发模型选择两万页面若单线程跑每个请求带延时平均1秒需要五个半小时以上。这个速度太磨人管道改造的收益很大一部分来自并发。并发模型我推荐ThreadPoolExecutor而非用asyncio。原因很实际静态网页抓取是IO密集型任务线程池写起来直观配合requests的阻塞调用几乎零心智负担asyncio虽然并发性能更好但需要把所有IO调用改成异步代理配置、超时处理、调试成本都高一截。线程数量不需要贪多8到16个是常见甜点区间。开三五十个线程对远程站点压力很大也容易把自己的内存耗在连接池上。实践中我用10个线程跑两万页面抓取时间压缩到70分钟左右成功率在99%以上。from concurrent.futures import ThreadPoolExecutor, as_completed def run_pipeline(): with ThreadPoolExecutor(max_workers10) as executor: futures [] for task in get_pending_tasks(): futures.append(executor.submit(process_task, task.id)) for future in as_completed(futures): future.result()4.2 断点续抓与去重策略断点续抓的实现核心就是任务状态表。每次处理任务前先把状态置为processing成功完成后置为done失败则置为failed并记录error信息。程序启动时只拉取pending和failed的任务失败任务会重新进入处理队列。这里要注意设置一个最大重试次数比如3次超过后保持failed状态不再自动拾取避免陷入无限重试的死循环。去重除了任务表本身的url唯一索引还可以在结果存储表上也加唯一键。比如标题发布时间组合防止同一个详情页被不同栏目页重复收录时产生重复数据。这个设计在归档任务中尤其重要因为列表页翻页时经常出现同一篇文章被挂在多个栏目下的情况。4.3 优雅退出与进程恢复高可用管道的最后一环是进程级容错。当程序收到SIGINT或SIGTERM信号时我正在处理的请求不能直接中断否则会留下半截processing状态的任务。我的处理方案是捕获退出信号设置一个全局的shutdown_flag所有线程在完成当前任务的瞬时检查该标记如果被置位就不再领取新任务待已领取任务执行完后再关闭线程池。进程崩溃则交由任务恢复机制兜底。启动时扫描所有状态为processing且最后更新时间早于当前时间三分钟的任务强制重置为pending。“三分钟”的阈值要大于单个任务的最大耗时避免正在处理的任务被误重置。这个机制很朴素但恰好合适不需要引入celery或supervisor这类重工具。4.4 日志与进度观测管道跑起来之后观察它的状态和观察业务系统同样重要。我用loguru把日志分成信息日志和错误日志。信息日志每隔一段时间输出已抓取数量、失败数量、当前速度和预计剩余时间错误日志则完整记录异常堆栈和关联的url。进度展示上tqdm配合任务队列的实时查询能显示一个动态进度条。但注意在日志系统和tqdm同时输出的情况下进度条容易和日志交错观感混乱。我会在进度条之外单独维护一个结构化日志字段统一用JSON格式输出关键指标后续不管是用awk分析还是接日志平台都很方便。5. 常见问题与排查技巧实录5.1 高频异常速查表下表整理了这套管道运行中最常遇到的问题以及对应的排查方向和处理建议。这些坑都与我在实际跑量过程中遇到的真实情况对应建议收藏。现象常见原因处理建议大量请求超时目标站响应变慢或本地连接池耗尽降低线程数调大连接池容量重试退避系数提高频繁收到403触发站点风控IP被临时限制放慢请求频率更换随机User-Agent等待恢复数据库锁异常SQLite多线程写入冲突写入任务串行化或迁移PostgreSQL解析结果缺失页面结构变更或部分字段为空解析函数先做字段存在性校验缺失则跳过详情页任务状态卡在processing进程被杀超时恢复机制没生效检查阈值时间设置确保启动扫描必执行内存缓慢增长大量响应对象未释放或队列堆积使用streamFalse默认形态及时清理抓取结果对象5.2 性能优化与抓取效率取舍抓取效率有一个明确的取舍关系速度越快对目标站的打扰越大被封的概率也越高。两万页面的任务与其追求一小时跑完被封后歇半小时不如用1.5小时平稳跑完。稳才是高可用管道的真正含义。一个比较有效的优化是接入HTTP缓存。requests-cache库可以把响应缓存到本地SQLite重复的URL直接走本地缓存对于列表页和详情页存在重叠的站点效果很明显。我在管道中给详情页解析做了二级缓存已经成功解析过的页面即使任务状态意外丢失再次拾取也能直接从结果表读取不重复请求网络。另外在IO层面可以把响应文本的编码判断写清楚。某些站点页面头部不标准requests的apparent_encoding判断会出现偏差。建议在解析层显式声明目标站点的字符集以utf-8为例可以防止中文乱码延误解析。5.3 设计管道时我最后悔没早想通的几件事第一个是持久化任务队列。我最初的单机版队列放在内存里一次重启就把任务搞丢了悔得肠子青。把任务队列放数据库后哪怕整体崩溃恢复也只需一个启动命令。这个教训让我建议所有人第一版就用SQLite做队列不要嫌麻烦。第二个是日志要打印到文件不要只打在控制台里。在终端里看到报错很容易以为记住了但真正排查时你说不清一百次失败里有多少种错误类型。文件日志配上grep就成了最简单的数据分析工具。第三个是解析函数加类型保护。不要直接信任页面给出的任何字符串尤其是时间格式有些站点会出现“1月1日”和“2025-01-01”混用的情况。我会在解析后统一转成datetime对象转换失败则返回空值并打印告警日志这样后端的校验才不会误杀数据。就我个人体会而言搭建这套静态网页抓取管道给我带来的帮助远不止两万条数据。它让我在做其他项目时也养成了“先设计状态流转再写业务逻辑”的习惯。如果你手里也有批量抓取静态页面的需求哪怕数据量暂时只有几百条按这个思路把管道搭起来后续扩容只是加线程和换数据库的问题不用推倒重写。最后分享一个实用小技巧管道写好之后先把抓取数量限制在50条跑通全流程再放开。第一次全流程跑通给你的信心比任何代码审查都管用。
