背景介绍
pyspider 架构,大概的流程如下图所示:
整个 pyspider 的各个模块间的任务传递是由**消息队列**传输的,其中任务的调度则是由「scheduler」模块控制,所以按作者的意思,除了「scheduler」调度模块只能单点,其他的「fetcher」,「processor」,甚至是「monitor & webui」,都可以实现多实例分布式部署。
这样一来分布式 pyspider 的瓶颈就在单点的 「scheduler」 节点的消费能力了,实际跑起来观察后发现确实「processor」到「scheduler」发送任务的队列经常消费不过来。
言归正传
之前将单机的 pyspider 部署在一台机子上,这一台负责「数据存储」,「消息队列」,「任务调度」,「URL请求」,「页面处理」全部的爬虫相关任务,导致 CPU 利用率一直很高。
所以现在单独开了一台机子,专门负责「URL请求」和「页面处理」,即上述的「fetcher」和「processor」模块。
主机地址、数据库、消息队列
- 爬虫机器1: 192.168.1.33
- 爬虫机器2: 192.168.1.71
- 数据库: mongodb://192.168.1.33:27017
- 消息队列: redis://192.168.1.33:6379
依赖安装
- docker & docker-compose
- docker pull pyspider
- docker pull redis
- docker pull mongodb
非爬虫部分配置
-
docker 配置网络接口:
docker network create --driver bridge pyspider
-
数据库服务:我使用
mongoDB
,由于之前就把服务起起来了,所以我没有进行 docker 封装,如果你是新起一个分布式爬虫,建议数据库服务也使用Docker。 -
消息队列服务:
redis
。命令:docker run --network=pyspider --name redis -d -p 6379:6379 redis
- 注意: 我下面用的非原生 pyspider,因为我需要依赖一些 pyspider 没有的库,请注意替换 (
my/pyspider</