第3章 候车大厅：调度器、去重与配置
文档摘要
第3章 · 候车大厅：调度器、去重与配置 本章要回答的三个问题：框架凭什么保证同一张地址只下载一次，重复票是在哪一步被拦下的？上百个配置项里，哪些真正决定了爬虫的行为边界？Spider 之外的事件——开关、异常、统计——框架通过什么机制通知你？ 为什么会有这一章 第 2 章结束时，你的车票已经能循环出生、到站、续票。但你可能没意识到一个问题：那些续出来的票，全都被悄悄查过一遍身份证——同一地址第二次排队时，框架直接拒收。这套机制发生在候车大厅，也就是调度器与去重过滤器的地盘。对它们的认知空白，是大多数爬虫诡异问题的根源：为什么这个页面明明删了旧版还是抓不到？为什么优先级设了像没设？为什么重启之后旧请求全回来了？ 本章同时解决另一个隐疾：配置意识的缺席。
第3章 · 候车大厅：调度器、去重与配置
本章要回答的三个问题：框架凭什么保证同一张地址只下载一次，重复票是在哪一步被拦下的？上百个配置项里，哪些真正决定了爬虫的行为边界？Spider 之外的事件——开关、异常、统计——框架通过什么机制通知你？
为什么会有这一章
第 2 章结束时，你的车票已经能循环出生、到站、续票。但你可能没意识到一个问题：那些续出来的票，全都被悄悄查过一遍身份证——同一地址第二次排队时，框架直接拒收。这套机制发生在候车大厅，也就是调度器与去重过滤器的地盘。对它们的认知空白，是大多数爬虫诡异问题的根源：为什么这个页面明明删了旧版还是抓不到？为什么优先级设了像没设？为什么重启之后旧请求全回来了？
本章同时解决另一个隐疾：配置意识的缺席。第 1 章你见过 settings 模块是"总花名册"，但当时只用了装配数字。这一章把真正日常的三组配置——并发与限速、去重与礼貌、日志与统计——逐组讲透。配置调不好，前面的代码写得再好也白搭：要么被目标站封禁，要么慢到失去采集意义。
信号系统放在本章末尾还有一层用意：它是框架机制的"公开广播频道"。候车、发车、到站、关闭，每个旅程节点都有对应信号可订阅。理解了双程动线上的这些节点（第 1 章的架构图此时该能默画了），信号的用途便水到渠成——它是你给框架行为打补丁的正规入口。
读完能解决什么
- 说清去重指纹的生成位置与算法，判断"该不该 dont_filter"，并实现过期请求的重新放行；
- 理解调度器的优先级队列与磁盘队列，为"断点续抓""按站点分配带宽"打下认知基础；
- 独立调出一组合理的并发与礼貌参数，让爬速贴着目标站容忍度的上限走；
- 用信号订阅关键事件：爬虫开关、请求失败、Item 落库，把统计与告警挂到旅程节点上。
各节怎么分工
| 节 | 回答哪个问题 | 关键产出 |
|---|---|---|
| 3.1 调度器与去重指纹 | 排队与查重的内部机制 | 队列选型、指纹机制、放行决策 |
| 3.2 Settings 全局配置 | 行为边界在哪配置 | 三组核心参数的调法与取舍 |
| 3.3 Signals 信号系统 | 事件怎么广播订阅 | 挂在旅程节点上的钩子 |
三节共享一个认知底座：框架的默认行为都写在配置里，配置的每个键都对应旅程上的一个决策点。3.1 讲"决策点在哪"，3.2 讲"怎么拨"，3.3 讲"怎么监听"。
本章知识点清单
- 能画出请求进入调度器后的分流：内存队列、磁盘队列、优先级堆，各自适合的场景；
- 能解释指纹由请求方法、地址排序后的参数拼接摘要而成，并由此推断哪些请求会被误判为重复；
- 能在"重复票被拦"与"必须重复发"两类需求间做出正确决策，说出 dont_filter 的代价；
- 能调出并发组参数的总并发、单域并发、每请求延迟，并解释三者对目标站压力的不同含义；
- 能用信号订阅 spider_closed 与 item_scraped 两个高频事件，实现收尾统计与落库计数。
先决条件
- 第 2 章的多回调 Spider 已能运行，见过 crawl 命令的启动日志；
- 对字典与哈希有直觉——指纹机制就是一次哈希；
- 知道 settings 模块的位置（第 1 章 1.3 节）。
往下走到哪
本章全部发生在请求"还没发出去"的阶段。下一章车票真正上路：穿过下行隧道的中间件关卡，接受改头、换代理、限速与重试的处置。3.2 节配置的那些开关，届时会一一被点亮；而 3.1 节里"被拒收的票"若有冤情，翻案工具也在第 4 章的中间件里。