Это заняло около двух месяцев, и вот, наконец, это сделано.Высокодоступный распределенный пул 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Получение ресурсов в очереди на проверку увеличит несправедливость - В настоящее время каждый валидатор (не
initVerifier) получит проверяемый IP-адрес из соответствующей временной очереди и проверит его, а детали проверки здесь опущены. - После завершения проверки вставьте его обратно в
ValidatedВ очереди, ожидая следующего раунда проверки - Показатели успешных запросов (представленные в виде дроби) и скорость ответа в соответствии с последним временем проверкиsettings.pyНастроенный IP-адрес прокси-сервера будет использоваться клиентом сканера.
- Чтобы скрыть различия между языками вызова, в настоящее время реализованный клиент
squidКлиент, его можно использовать в качестве промежуточного программного обеспечения для клиента сканера.
На этом весь процесс закончен.
тест на эффект
Развертывание в автономном режимеhaipproxyитестовый код, запросите сайт с Zhihu в качестве цели,
каждые десять тысячуспешный запросДля статистических результатов измеренный эффект сканирования выглядит следующим образом.
| объем запроса | время | кропотливый | Стратегия загрузки 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) верификатор Zhihu ставитInit QueueПосле того, как прокси на сервере будут израсходованы, поскольку это временная задача, свежие IP-адреса будут свободны в течение определенного периода времени. Большинство бесплатных IP-адресов недолговечны, поэтому в этот период существует вакансия IP; (3) Поскольку мы используемgreedyРежим вызова IP, его стратегия вызова: высококачественный прокси-IP всегда будет вызываться до тех пор, пока прокси-IP не будет недоступен или заблокирован, в то время как низкоскоростной IP-адрес будет вызываться путем опроса. Это также может привести к вакансиям качественных ИС.
Можно видеть, что стратегия вызова контрольной суммы IP все еще имеет много возможностей для оптимизации. Надеюсь друзья-единомышленники смогут присоединиться и оптимизировать вместе, что тоже очень интересно.
Адрес проекта: https://github.com/SpiderClub/haipproxy
Добро пожаловать на звездочку и форк, и приглашаю всех к общению и пиару.