Парсинг цен без блокировок: вежливый сбор данных

Сначала правила: что можно собирать

Прежде чем писать парсер, ответьте на три вопроса. Первый: данные публичные? Цены, наличие и описания товаров на витрине, как правило, видны любому посетителю. Данные из личных кабинетов и закрытых разделов - нет. Второй: что говорят условия использования сайта и файл robots.txt? Третий: есть ли официальный API или выгрузка?

• Официальный API или фид - лучший вариант: стабильный формат, понятные лимиты, меньше трафика.
• robots.txt показывает, какие разделы владелец сайта просит не обходить роботам, а иногда и желаемую паузу между запросами.
• Условия использования могут прямо ограничивать автоматический сбор. Если запрещено, поищите другой источник или договоритесь с владельцем.

Темп запросов: лимиты, паузы и параллельность

Главный рычаг - частота. Задайте ограничение на число запросов в секунду к одному домену и число одновременных соединений. Начинайте с малого и повышайте, только убедившись, что сайт отвечает без ошибок.

• Пауза между запросами к одному домену, а не только между пачками.
• Случайный разброс (jitter): вместо ровных интервалов добавляйте небольшое случайное отклонение, чтобы запросы не шли строго по таймеру.
• Лимит параллельности на домен и на каждый IP: несколько потоков вместо десятков.
• Расписание: тяжёлые обходы удобнее запускать в часы, когда у сайта меньше посетителей.

Честный User-Agent

Не выдавайте робота за браузер без необходимости. Понятный User-Agent с названием вашего сервиса и контактом позволяет владельцу сайта связаться с вами, а не сразу закрывать доступ. Если сайт отдаёт данные только браузеру, это повод задуматься, разрешён ли такой сбор.

Меньше запросов: кеш и условные запросы

Лучший запрос - тот, который не пришлось делать. Если цена товара обновляется раз в день, проверять её каждые пять минут бессмысленно. Храните ответы и задавайте каждому типу страниц свой срок актуальности.

Многие сайты поддерживают условные запросы. В первом ответе сервер присылает заголовки ETag или Last-Modified. При следующем обращении вы передаёте их обратно в If-None-Match или If-Modified-Since, и если страница не изменилась, сервер отвечает коротким 304 Not Modified без тела. Это экономит трафик и нагрузку с обеих сторон.

• Запрашивайте сжатые ответы (Accept-Encoding: gzip).
• Не скачивайте картинки, шрифты и скрипты, если нужен только текст.
• Если у сайта есть JSON-эндпоинт для витрины, он обычно легче HTML-страницы.

Слушайте сервер: 429, 503 и Retry-After

Сайт сам сообщает, что вы торопитесь. Код 429 Too Many Requests означает превышение лимита, 503 Service Unavailable - перегрузку или обслуживание. Часто к ним прилагается заголовок Retry-After с числом секунд или датой, после которой можно повторить запрос.

1. 1Получили 429 или 503 - остановите запросы к этому домену с этого адреса.
2. 2Если есть Retry-After, подождите указанное время.
3. 3Если нет, используйте экспоненциальную задержку: каждый повтор ждёт дольше предыдущего, с верхней границей и случайным разбросом.
4. 4Ограничьте число повторов. Не получилось за несколько попыток - отложите задачу на потом.
5. 5Капча - тоже сигнал. Не пытайтесь её обойти: снизьте темп.

MAX_RETRIES = 4
BASE_DELAY  = 2      # секунды
MAX_DELAY   = 120

function polite_get(url, proxy):
    wait_for_domain_slot(url)          # лимит запросов и потоков на домен
    sleep(random(0.5, 1.5) * PAUSE)    # пауза с разбросом (jitter)
    headers = cached_validators(url)   # If-None-Match / If-Modified-Since
    for attempt in 0..MAX_RETRIES:
        resp = http_get(url, headers, proxy)
        if resp.status == 304:
            return cache.get(url)
        if resp.status in (429, 503):
            delay = resp.header('Retry-After')
                    or min(MAX_DELAY, BASE_DELAY * 2^attempt)
            sleep(delay + random(0, 1))
            proxy = pool.cooldown(proxy)   # дать адресу отдохнуть
            continue
        cache.put(url, resp)               # сохранить тело и ETag
        return resp
    defer(url)                             # отложить, не долбить

Пул прокси: распределять, а не прятаться

Даже при аккуратном темпе один адрес упирается в лимит сайта, если страниц много. Пул прокси позволяет распределить нагрузку: каждый IP делает немного запросов, а суммарно задача выполняется в срок. Важно, что общий темп к сайту при этом не должен расти безгранично. Пул нужен, чтобы уложиться в разумные лимиты на адрес, а не чтобы обойти их и нагрузить сайт сильнее.

• Держите счётчик запросов и ошибок по каждому адресу.
• Адрес, получивший 429, отправляйте «отдыхать» на время, а не сразу в следующий запрос.
• Для сайтов с сессиями закрепляйте сессию за одним адресом, чтобы IP не менялся посреди сценария.

Как посчитать объём трафика для резидентских прокси, описано в статье резидентские прокси по ГБ. Если сайт отказывает даже при вежливом темпе, загляните в разбор почему сайт блокирует прокси.

Короткий чек-лист перед запуском

1. 1Данные публичные, условия сайта и robots.txt проверены, официального API нет или его недостаточно.
2. 2Задан лимит запросов и потоков на домен, паузы со случайным разбросом.
3. 3Работает кеш, используются ETag и If-Modified-Since.
4. 4Обрабатываются 429 и 503 с учётом Retry-After, число повторов ограничено.
5. 5Пул прокси с учётом ошибок по каждому адресу, персональные данные не собираются.

Список адресов в нужном формате для вашего парсера можно подготовить в конвертере прокси, а выгружать и продлевать адреса автоматически через REST API. Подробнее о сценариях на странице прокси для парсинга.