高可用分布式代理IP池:架构篇

历时大体两个月，到如今终于完成了高可用分布式代理IP池，目前开源在了Github上。写这个项目的缘由主要有两点，一是本身平时的部分工做须要和爬虫打交道，代理IP在有的时候能够发挥很是重要的做用，调研过一些开源的代理IP采集程序，发如今抓取、解析、校验、资源调度等这些方面总有一些不尽人意的地方；二是和一个网友（不严格的说算得上是伯乐）的交流让我有了关于使用Scrapy来写分布式爬虫的一些想法，正好能够借助这个机会来尝试证明这些想法。

---

这篇文章的目的是阐述haipproxy的主要架构和流程。该项目关键部分是

• 基于Scrapy和Redis的分布式爬虫，用做IP抓取和校验，对应于项目的crawler
• 基于Redis实现的分布式任务调度工具，对应于项目的scheduler和redis_util.py

Crawler分为代理抓取和校验，二者实现思想相似，主要使用Scrapy的spider_idle信号和DontCloseSpider异常来阻止Scrapy在没有数据的时候关闭，灵感来自scrapy-redis。为了方便阐述，我画了一张包含各个组件的流程图，以下

• 启动调度器，包括代理爬虫调度器和校验爬虫调度器。调度器会读取rules.py中待抓取的网站，将其编排成任务存入各个任务队列中
• 启动各个爬虫，包括IP抓取和校验程序。项目中爬虫和调度器都是高可用的，能够根据实际状况进行分布式部署，无需改动代码。因为本文的目标不是写成该项目的详细使用文档，因此省略了如指定启动爬虫类型和调度器类型的介绍
• 代理IP采集爬虫启动后会到对应的任务队列中获取任务并执行，再把获取到的结果存入一个init队列中
• init队列由一个特殊的校验器HttpbinInitValidator进行消费，它会过滤掉透明代理，再把可用代理输入各个Validated队列中
• 调度器会定时从Validated队列中获取代理IP，再将其存入一个临时的队列。这里用一个临时队列是为了让校验更加公平，若是直接从Validated队列中获取资源进行校验，那么会增大不公平性
• 这时候各个校验器(非init校验器)会从对应的临时队列中获取待校验的IP并对其进行校验，此处省略校验细节
• 校验完成后再将其放回到Validated队列中，等待下一轮校验
• 请求成功率(体现为分数)、响应速度和最近校验时间知足settings.py所配置要求的代理IP将会被爬虫客户端所消费
• 为了屏蔽各个调用语言的差别性，目前实现的客户端是squid客户端，它能够做为爬虫客户端的中间件

到此，整个流程便完了。

---

效果测试

以单机模式部署haipproxy和测试代码，以知乎为目标请求站点， 每一万条成功请求为统计结果，实测抓取效果以下

请求量	时间	耗时	IP负载策略	客户端
0	2018/03/03 22:03	0	greedy	py_cli
10000	2018/03/03 11:03	1 hour	greedy	py_cli
20000	2018/03/04 00:08	2 hours	greedy	py_cli
30000	2018/03/04 01:02	3 hours	greedy	py_cli
40000	2018/03/04 02:15	4 hours	greedy	py_cli
50000	2018/03/04 03:03	5 hours	greedy	py_cli
60000	2018/03/04 05:18	7 hours	greedy	py_cli
70000	2018/03/04 07:11	9 hours	greedy	py_cli
80000	2018/03/04 08:43	11 hours	greedy	py_cli

可见haipporxy的代理效果还算不错，在开始的时候能够达到1w/hour的请求量，几个小时候请求量请求量 降为了5k/hour。下降的结果可能有三个: (1)随着数据量的增大,Redis的性能受到了必定的影响(2)知乎校验器在把Init Queue中的代理消费完以后，因为是定时任务，因此致使某段时间内新鲜的IP空缺。而免费IP大多数都是短效的，因此这段时间出现了IP的空缺;(3)因为咱们采用的是greedy模式调用IP，它的调用策略是: 高质量代理IP会一直被调用直至该代理IP不能用或者被封，而低应速度IP会轮询调用。这也可能致使高质量IP的空缺。 可见IP校验和调用策略还有很大的优化空间。但愿志同道合的朋友加入进来一块儿优化，这也挺有意思的。

项目地址: https://github.com/SpiderClub/haipproxy

欢迎star和fork，也欢迎你们交流和PR。