近日使用haipproxy作为代理源，对知乎进行了数据抓取相关的性能测试，测试结果简单说起来就是，高峰期请求量可达到1w/hour，低谷期不低于5k/hour，单机一天大概可以达到18~20w的请求量。测试结果的细节可以点击项目主页查看。要知道它的所有代理IP均来自互联网公开采集的代理IP，无任何付费IP源，所以这样的测试结果还算令笔者满意，感觉这几个月的努力没白费。但是它仍有继续优化的空间，笔者打算单独写一篇文章来单独阐述它现有的IP筛选策略，也就是题目说的高可用策略，一是为了推广haipproxy，二是为了抛砖引玉，希望对大家有一些启发，能有志同道合的朋友参与其中进行优化。关于部署的高可用后续文章会谈及到，这里暂时按下不表。
下文主要会谈到校验器和客户端的IP筛选策略。
目录
校验器
我们知道，一个代理IP有多个属性，比如成功请求率、响应速度、是否支持Get/Post方法、是否匿名和该IP所处位置等。这些往往也是衡量一个IP质量的可参照标准。而从互联网上采集的免费IP大多数是短效的，所以代理IP对应的最近验证时间也是一个很重要的参考标准。haipproxy目前主要参照请求成功率、响应速度、最近验证时间和是否匿名这四个维度对代理IP进行筛选。精力所限，目前还未打算对IP位置进行完善，而IP位置对于已登录的账户来说具有比较重要的意义。还有一点是，对于同一个代理IP，代理不同网站的效果可能大不相同，所幸的是，haipproxy可以根据自己需求定制校验器
根据haipproxy架构篇的介绍，我们可以知道haipproxy initvalidator会过滤掉部分透明的代理ip，另外一个过滤透明IP的地方是proxy spiders，它在抓取代理IP的时候会直接丢弃透明代理IP。因此，是否匿名这个标注我们已经实现了，后续所有的validated queues中存储的都是匿名及高匿IP。
请求成功率是以打分的方式来做的，这样做的原因是不需要对历时成功请求次数和失败请求次数进行记录和计算，优化了部分性能，又可以体现一个IP的稳定性。那么打分的标准又是怎样的呢？haipproxy会先给定一个初始分数(5分)。当成功一次，我们就对该代理加1分，为了防止分数短时间急剧增大，在分数大于一定阈值(10分)后就对其进行更平滑的加分处理，具体为round(10/score, 2)，这样，分数会越来越难升高，但是足够衡量每个代理IP的稳定性了。当失败一次，就要分情况处理了。我们知道，很多免费代理IP可能短时间失效，比如代理端口被关了。这种情况下，haipproxy会直接丢弃该代理IP，因为它没有继续校验的必要性了，再对它进行校验只会增加校验器的负担。但是如果本次校验超时了，校验器会将该代理IP减一分，直到分数为0，则删除。对于不同分数的IP的选取会在客户端部分进行说明。
响应速度这个标准比较容易评判，haipproxy的做法是为校验器爬虫加载一个profilemiddleware，从而获取到请求成功的代理IP的响应时间。同理，最近校验时间也比较容易获取到，我们使用redis的zset数据结构来存储它。
以上维度都成了客户端对可用代理进行筛选的参照标准。
客户端
目前，haipproxy实现了两种形式的客户端：squid和py_cli。前者是语言无关的，它使用squid作为二级代理，它会定时自动更新squid配置文件，以获取新的可用代理，获取的方法和使用py_cli相同，下面会讲到。使用squid作为二级代理的好处是便于服务化，同时是语言无关的，我们的爬虫端只需要将代理设置为:3128就可以了，不用关心其它，但是这么做有两点不好的是，一是它的调度是轮询IP，并且对于不可用或者低质量IP的处理和反馈是不透明的，二是squid容易成为项目的单点或者性能瓶颈。基于这两点，有必要实现基于不同语言的客户端。
py_cli是haipproxy代理获取的python实现。挑选可用代理的具体做法如下:
根据配置文件的设置分别从validated_queue、ttl_queue和speed_queue中挑选出满足配置参数需求的代理再对其求交集，参数默认值是LOWEST_SCORE = 6、TTL_VALIDATED_RESOURCE = 2和LONGEST_RESPONSE_TIME = 10，表示的意思是选择分数大于６且最近验证时间在２分钟以内且最长响应时间不超过10s的代理。这样可以对上述的各个标准做合理的保证。在上述挑选方式选出来的代理数量不足(len(proxies) < len(pool)*2)的时候，会放宽挑选要求，对速度和最近验证时间求交集，然后和成功率做并集。如果代理数量还不足，它还会放低要求，对满足最近验证时间和成功率的集合做并集。在爬虫客户端调用py_cli的时候，代理客户端ProxyFetcher会首先调用refresh()方法，如果ProxyFetcher中的可用代理量不够，那么就会通过上一步的算法对IP池进行扩充，如果数量足够，那么就会根据代理的调度策略选取合适的IP进行使用。目前共有两种代理调度策略。(1)轮询策略。代理池是一个队列结构，每次从队首拿一个IP进行使用，如果该IP请求成功，则放到队尾，如果不成功，则需要调用ProxyFetcher的proxy_feedback()方法将结果进行反馈。这种策略的好处是IP负载比较均衡。但是缺点在于，IP质量参差不齐，有的响应时间很快，有的响应时间很慢，并且高质量的免费代理IP的生命周期可能很短，这样就无法充分利用。(2)贪婪策略。使用此种策略的时候，需要爬虫端对每次请求的响应时间进行记录，每次使用后调用proxy_feedback()方法以决定该代理IP是否继续下一次请求的时候被使用。如果使用某个代理IP的响应时间低于传入的response_time参数，那么就会一直使用它，直到不能用就从代理池中删除。如果时间高于了response_time，那么它会把该IP放入队尾。概括起来，该策略就是低质量IP轮询，高质量IP一直使用。上述便是目前关于haipproxy的代理IP挑选策略的所有细节。如果该文章或者该项目对你有帮助，不妨在Github上给个star，以鼓励笔者继续优化。同时，也希望能有志同道合的朋友加入进来做