proxy_pool 功能建议

a64a0gku 于 5个月前发布在其他

关注(0)|答案(9)|浏览(86)

在这两天的个人使用中，增加了一些接口并发现了一些功能完善建议，看下是否合理。

新增接口

1. 获取最优代理接口

爬取过程中我不并想要随机代理，即使我已经把校验代理可用性的周期已经改为了10s，但还是有很多的随机代理连续不可用的情况，导致抓取失败率较高。我更希望每次获取最优代理，在代理有效期内最大程度地利用此代理。选取标准基于 check_count 以及 fail_count 的差值。
核心语句：
choice = max(item_list, key=lambda d: json.loads(d)['check_count'] - json.loads(d)['fail_count'])

2. 更新 `check_count` 接口以及更新 `fail_count` 接口

当前check_count仅仅在校验过程中发生更新。但由于我新增了最优代理接口，希望在实际使用代理过程中可以实时更新其 check_count 以及 fail_count ，从而可以持续保持代理的最优性。
核心语句：

def update_check_count(self, proxy_str):
        self.db.changeTable(self.useful_proxy_queue)
        value = self.db.get(proxy_str)
        if value:
            dic = json.loads(value)
            dic['check_count'] += 1
            value = json.dumps(dic)
            try:
                self.db.update(proxy_str, value)
                return {'code': 1, 'msg': 'success', 'proxy': dic['proxy'], 'check_count': dic['check_count']}
            except Exception as e:
                print(e)
                return {'code': 0, 'msg': 'update failed'}
        else:
            return {'code': 0, 'msg': 'proxy is not exist'}

    def update_fail_count(self, proxy_str):
        self.db.changeTable(self.useful_proxy_queue)
        value = self.db.get(proxy_str)
        if value:
            dic = json.loads(value)
            dic['fail_count'] += 1
            value = json.dumps(dic)
            try:
                self.db.update(proxy_str, value)
                return {'code': 1, 'msg': 'success', 'proxy': dic['proxy'], 'fail_count': dic['fail_count']}
            except Exception as e:
                print(e)
                return {'code': 0, 'msg': 'update failed'}
        else:
            return {'code': 0, 'msg': 'proxy is not exist'}

功能建议

1. `fail_count` 的变化逻辑

在 /proxy_pool/ProxyHelper/ProxyUtil.py 中，校验成功则 check_count+=1, if fail_count>0: fail_count-=1 ; 校验失败则 check_count+=1, fail_count+=1 。可以看到， check_count 代表校验次数没有问题，而 fail_count 既承担了失败数的角色，又承担了成功数的角色，我认为模糊了此字段，不能达到应有的效果。比如说，我想找一个最优代理，自然是看成功次数或是成功率，但由于 fail_count 在校验成功反而会减1，那么我无法通过这两个字段得到确切的成功次数或是成功率。也就是说，在原有逻辑中，我想找最优代理，只能从 fail_count 最小的代理中去找，但这样是不足以找最优代理的，比如一个 fail_count=0, check_count=10 的代理可能代表成功10次，也可能代表成功5次失败5次，是一个模糊的组合。
改进逻辑：
要么增加一个新字段 suc_count 代表成功数，要么在校验成功时 fail_count 不自减，这样字段组合就可以唯一性确定代理的校验情况。我采用的是后者。见：

def checkProxyUseful(proxy_obj):
    """
    检测代理是否可用
    :param proxy_obj: Proxy object
    :return: Proxy object, status
    """

    if validUsefulProxy(proxy_obj.proxy):
        # 检测通过 更新proxy属性
        proxy_obj.check_count += 1
        proxy_obj.last_status = 1
        proxy_obj.last_time = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
        # if proxy_obj.fail_count > 0:
        #     proxy_obj.fail_count -= 1
        return proxy_obj, True
    else:
        proxy_obj.check_count += 1
        proxy_obj.last_status = 0
        proxy_obj.last_time = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
        proxy_obj.fail_count += 1
        return proxy_obj, False

以上新增功能及建议均不影响原有功能，可以讨论下合理性以及必要性。

proxy_pool

来源：https://github.com/jhao104/proxy_pool/issues/441

9条答案

按热度按时间

gjmwrych1#

3q, 这就相当于某种评分机制，代理某次请求不通了还保留认为其可能为恢复 . 其实在实际使用中，代理一次不通直接就扔掉，拿下一个，代理本身失效就快，代码里面默认 fail_count 大于0就扔掉的，设计之初就不想加入这个机制，因为这样会到整个池的ip有部分是不确定100%能用的，保留不好的代理来增加池子数量并不好。

如果说要筛选最优代理的话，应该是从响应速度和有效时长来考虑，对垃圾代理零容忍是我本身初衷，但是后面很多要求保留某次请求失败的代理才加入 fail_count 这个概念，后面应该不会在这方面往下扩展，

赞(0）回复(0）举报 5个月前

pb3skfrl2#