高质量, 高灵活
我们HTTP/HTTPS的代理是从网上获取来的.
所有天生具有不稳定的属性.
我们就需要通过持续的校验来判断代理是否可靠.
问题是我们怎么定义高质量呢?
起初, 我们认为高质量为 代理的可用性=校验成功次数/校验总共次数
但这个思路不严谨, 举个栗子:
有个代理A, 一个月前总共校验500次, 成功校验486次, 代理的可用性=486/500=97.2%
看起来似乎不错, 然而, 有个问题, 假如这个代理突然无效了.
那这个代理的可用性会慢慢的降低, 486/501=97%, 486/502=96.81%, 486/503=96.62%
这个数字看起来依然是一个可用性很高的代理, 但却无法正常使用.
所以我们需要额外的信息来判断一个高质量的代理是否可以使用.
这个额外的信息就是代理最后一次校验的状态.
所以我们通过可用性和最后一次成功的状态来过滤高质量的代理.
怎么定义高灵活呢? 不太好理解.
换个角度, 作为一个代理池, 如何才能更好的提供服务.
一开始的设计是通过RESTful API暴露接口提供服务.
但这种方式对代码有侵入性, 使用的体验非常不好.
于是, 我们可以在做一个动态代理.
客户端 -> 动态代理 -> 一般代理 -> WEB服务器
在这个动态代理里, 我们可以根据统计的数据做一些过滤, 以及对代理进行反馈.
实现没什么问题, 关键是在于规模.
当代理池的代理数量非常大时, 会导致大量校验, 但其中大部分的校验是无效的.
根据最近最少使用算法的思想:
如果一个代理, 之前大部分时间不可用, 那它在以后不可用的概率非常大.
但是, 如果一个代理, 之前大部分时间可用, 那它在以后可用的概率其实是未知的.
所以我们不需要对一直不能用的代理进行校验, 而对一直可用的代理进行校验.
关键在于应该多久校验一次呢?
大部分时间不可用, 换个说法也就是校验失败次数的占比较大.
大部分时间可用, 换个说法也就是校验成功次数的占比较大.
于是, 我们可以把校验的时间间隔与校验成功次数/校验失败次数做关联.
想法没什么问题, 但实现起来有点麻烦.
这里我们可以使用一个额外的信息来代表代理的质量, 这个额外的信息就是
每次校验代理后, 如果成功, 我们就+1分, 如果失败, 我们就-1分.
最后我们用代理的评分 乘以 常量间隔数, 就能减少一直不能用代理的校验次数.
而一直可用的代理, 我们直接用常量间隔数频率来验证.
这样其实就能大量的减少无效的校验.
总结一句话: 太差的代理不管了, 表现好的代理要紧盯着.