Параллельные запросы через пул прокси
Один поток и один прокси собирают каталог из 100 000 страниц неделями. Параллелизм ускоряет задачу в разы, но без дисциплины быстро приводит к 429, банам подсетей и исчерпанию лимитов провайдера. Разберём, как выстроить concurrent-архитектуру с пулом прокси NEONPROXY так, чтобы масштабировать throughput, а не количество ошибок.
Зачем нужен пул, а не один адрес
Каждый IP несёт свой «бюджет» запросов к целевому сайту: типичный лимит — 1–10 rps на адрес для агрессивных антиботов. Пул из N прокси теоретически даёт N× пропускную способность. На практике узким местом становятся не только rate limit цели, но и пропускная способность самих прокси-серверов и вашего исходящего канала.
Для массового парсинга оптимален набор IPv6-адресов: они дешевле IPv4, а современные сайты принимают трафик по AAAA. Если целевой домен не поддерживает v6 — см. IPv6 vs IPv4. Для задач с авторизацией держите отдельный «sticky»-пул из приватных IPv4.
Архитектура: воркеры и очередь
Классическая схема: producer кладёт URL в очередь (Redis, RabbitMQ, in-memory asyncio.Queue), N worker-процессов или корутин забирают задачи и каждый закреплён за своим прокси. Правило «один воркер — один IP» упрощает отладку: вы всегда знаете, какой адрес получил 403.
Альтернатива — общий пул с round-robin: перед каждым запросом берётся следующий прокси из списка. Проще в коде, но сложнее отслеживать «битые» адреса. Рекомендуем помечать прокси unhealthy после серии ошибок и временно исключать из ротации.
Python: asyncio + aiohttp
Для I/O-bound задач asyncio эффективнее threading: тысячи корутин на одном процессе без GIL-конкуренции. Базовый паттерн:
Создайте семафор на concurrency (например, 50 одновременных запросов). Каждая корутина получает proxy из пула через itertools.cycle или asyncio-safe очередь. Используйте aiohttp.TCPConnector(limit=10) на прокси, чтобы не открывать сотни TCP-соединений к одному gateway.
Таймауты обязательны: connect 5 s, total 30 s. Зависший запрос блокирует слот семафора и снижает throughput всего пула. Подробнее о синхронном клиенте — в статье прокси и Python requests.
Threading и multiprocessing
Если библиотека не поддерживает async (старый Selenium, некоторые SDK), используйте ThreadPoolExecutor с фиксированным числом потоков = числу прокси. Каждый поток инициализирует свой Session с proxy и обрабатывает подочередь URL.
Multiprocessing оправдан при CPU-bound парсинге HTML (BeautifulSoup на больших документах). Прокси-конфиг передавайте через initializer воркера, не через глобальные переменные без синхронизации.
Лимиты и backoff
Не выставляйте concurrency «на максимум». Начните с 5–10 параллельных запросов на прокси и измеряйте долю 429/503. При росте ошибок — уменьшайте concurrency или добавляйте jitter между запросами (random.uniform(0.1, 0.5)).
Exponential backoff при 429: пауза 2^n секунд, максимум 60 s, затем retry с тем же или другим прокси. Не ретрайте бесконечно — после 3–5 попыток отправляйте URL в dead-letter очередь для ручного разбора.
Балансировка и health check
Периодически прогоняйте пул через прокси-чекер NEONPROXY или свой ping-эндпоинт. Прокси с latency > 3 s или packet loss исключайте из активной ротации. API v2 позволяет автоматизировать выдачу и замену адресов — см. интеграцию API.
Weighted round-robin: быстрым прокси отдавайте больше запросов. Least-connections — если один ворker «залип» на тяжёлой странице, остальные продолжают работу.
Типичные ошибки разработчиков
Sharing одного requests.Session между потоками без lock — race condition на cookies и connection pool. Отсутствие per-proxy rate limiter: 100 корутин бьют в один IP одновременно. Игнорирование DNS: при смене прокси резолвите домен заново или используйте keep-alive осознанно.
Запуск 500 воркеров на 10 прокси — вы не ускорите задачу, только создадите очередь ожидания и исчерпаете file descriptors. Соотношение воркеров к прокси держите близким к 1:1 или 2:1.
Метрики для мониторинга
Отслеживайте: requests/sec, error rate по кодам, p95 latency, active proxies, queue depth. Алерт при error rate > 5% или росте очереди более чем на 10 000 задач. Логируйте proxy_id в каждой строке — без этого невозможно понять, какой IP «горит».
NEONPROXY не логирует ваш трафик (zero logs policy), поэтому телеметрию стройте на своей стороне. Это плюс для приватности и минус, если вы не настроили observability.
Итоговая схема
Очередь URL → N воркеров → 1 прокси на воркер → семафор на concurrency → backoff при ошибках → health check раз в час. Для stateless-парсинга — IPv6-пул от 20 адресов. Для mixed-задач — два пула: crawl (IPv6, high concurrency) и session (IPv4, concurrency 1).