举个接地气的例子：你接到个活，要把老图书馆里10万本书的信息全抄下来，书名、作者、出版日期一个都不能落。

刚开始你干劲十足，一天抄几百本，抄着抄着就崩溃了：书东一本西一本，A区跑B区，大半时间都浪费在路上；更闹心的是，中途有事出门，回来彻底忘光抄到哪了，只能从头翻。

这就是咱们平时用的单机爬虫，毛病全一样。

任务队列：给爬虫配个“待办小本本”

后来你学机灵了：每天早上花半小时，把要抄的书写在便利贴上，一张贴一本，按书架排好。抄完一本就撕一张，临时有事？看一眼剩下的便利贴，立马知道从哪接着干，一点不耽误。

这个便利贴清单，就是爬虫里的任务队列。

放到爬虫里，作用一模一样：把要爬的网址存起来，爬完一个标记一个，谁要用谁来取，取走就处理。Python自带的queue模块，就是干这个的：

from queue import Queue
task_queue = Queue()
# 往队列里放要爬的网址
task_queue.put('https://books.com/page1')
# 取出一个任务，队列里就少一个
next_url = task_queue.get()

有了这个队列，爬虫再也不用“靠脑子记”。就算中途崩了重启也没事，队列里没取完的任务还在；想提速？多开几个线程，大家从同一个队列里拿网址，互不干扰。

分布式：从一个人干，变成一群人搭伙干

可10万本书实在太多，就算有便利贴，你一个人一天也就抄几百本，得熬到什么时候？这时候你就想：喊几个朋友一起来，每人管一排书架，速度不就直接翻倍了？

问题来了：便利贴就你手里这一份，总不能让大家抢着撕吧？“这张是我先拿的！”“别抢别抢！”，当场乱成一锅粥。

这时候你就需要一个共享便利贴板：所有人看的都是同一份清单，谁拿走了哪个任务，别人就看不到了，不会重复干。这个共享板，就是分布式爬虫里的消息队列，平时常用的Redis、RabbitMQ、Kafka，都是干这个的。

你负责前100页，我管101-200页，他专门下载图片，一个公共的任务队列，就能让几十台机器同时干活，谁也不耽误谁。

这就是分布式爬虫：多台机器，共用一个任务池，分工配合一起干活。

这个架构到底长啥样？

画个最简单的结构，一眼就看懂：

任务队列（比如Redis）：专门存所有还没爬的网址

爬虫节点（多台服务器）：每台机器都从队列里取任务，爬完后把新解析出来的网址再扔回队列

数据存储：爬下来的内容，统一存到数据库或者云存储里

讲究点的还会加个调度器，它不亲自干活，专门管安排：判断同一个网址别爬两次、给重要页面优先爬、控制爬取速度，别把人家网站搞崩。

实际搭建时，容易踩这些坑

看着简单，真动手搭就会遇到一堆麻烦事：

第一个是去重：两台机器同时拿到同一个网址怎么办？常用布隆过滤器，用一点点内存就能快速判断这个网址爬没爬过；也可以在放进队列前，先统一查一遍有没有重复。

第二个是反爬：分布式一启动，几十台机器同时访问一个网站，人家立马就能察觉不对劲。解决办法就是给每台机器配代理IP池，再控制好请求速度，让流量看起来跟普通人访问一样。

第三个是节点挂掉：某台服务器突然宕机，它正在处理的任务不就丢了？可以用“超时重入队”：任务取走后先标记“正在处理”，等机器处理完再删掉；要是超时没反馈，任务就自动回到队列里，让别的机器接着干。

什么时候才需要用分布式？

千万别一上来就搞分布式，大多数爬虫，单机加个任务队列就完全够用。

只有遇到这些情况，再考虑上分布式：

单机带宽跑满、CPU一直100%，实在带不动了

每天要爬几千万个页面，单机得跑好几周

目标网站有严格时间限制，必须几小时内爬完

分布式不是万能的，它会变复杂：调试更难、部署更麻烦，出问题得查好几台机器。但从一个人累死累活，变成一群人高效干活，这点复杂度完全值得。

最后说句实在的：光看文字永远觉得简单，真自己写一个从Redis队列取任务的爬虫，放在三台服务器上跑，看着日志里三个IP同时输出“已爬取第xxx条”，这种实操感受，比看十篇文章都管用。