Розподілений парсинг: масштабування через кілька воркерів
Відзначимо: коли один парсер впирається в ліміти цільового сайту і швидкість власної мережі, ми пропонуємо розподілену архітектуру. Наш досвід показує: 5 воркерів з різними проксі дають не просто ×5 швидкість — вони паралельно обходять різні розділи і не конфліктують при записі в загальну базу. Ви отримуєте готове рішення під ключ: від координатора до дедуплікатора. Розподілений парсинг дозволяє обійти обмеження за частотою запитів та IP-блокування. Кожен воркер використовує свій пул резидентних проксі, що знижує ймовірність блокування. Для управління завданнями застосовується черга Redis з пріоритетами, що забезпечує рівномірне завантаження. Система спроектована з урахуванням відмовостійкості: при падінні воркера завдання переходить іншому.
На відміну від простого запуску кількох копій, наша архітектура гарантує відсутність дублювання та узгодженість даних. Завдяки Bloom filter та дворівневій черзі, система масштабується без втрати продуктивності. Ми гарантуємо стабільність при навантаженні до 5000 сторінок на хвилину. Економія на інфраструктурі порівняно з послідовним обходом може сягати 40%. Така продуктивність досягається за рахунок паралельної роботи воркерів та ефективного управління чергою.
Ми маємо 5 років досвіду в парсингу та реалізували понад 15 проєктів. Наша команда підбере оптимальну конфігурацію: кількість воркерів, тип проксі, ємність черги. Оцінимо ваш проєкт безкоштовно протягом 1–2 днів. Отримайте консультацію інженера.
Як розподілений парсинг вирішує проблему блокувань?
Воркери працюють з різними IP, кожен має свій ліміт запитів. Ми використовуємо ротацію проксі з автоматичним карантином забанених адрес. Це дозволяє збирати дані з агресивним захистом, зберігаючи стабільність. Додатково застосовується затримка між запитами (jitter), щоб не створювати рівномірний патерн.
Чому дедуплікація критична для розподіленого парсингу?
Без дедуплікації один і той самий URL може бути оброблений кількома воркерами, що призводить до надлишкових запитів та неконсистентних даних. Ми використовуємо Bloom filter для перевірки унікальності URL перед додаванням у чергу. Bloom filter займає в 50–100 разів менше пам'яті, ніж Set, при допустимій похибці менше 0.1%. Це ефективно для масштабів понад 10 млн URL. Bloom filter — оптимальний вибір.
Архітектура розподіленого парсингу
Загальна схема
Координатор (Scheduler) → Черга завдань (Redis + BullMQ) → Воркери (stateless) → Shared Storage (PostgreSQL + S3) → Дедуплікатор (Bloom filter). Координатор не парсить сам — він генерує завдання та моніторить прогрес. Кожен воркер бере завдання з черги, виконує та повертає результат. Для розпаралелювання лістингів використовується дворівнева черга: спочатку сторінки каталогу, потім картки товарів з різними пріоритетами.
Управління проксі та дедуплікація
Кожен воркер прив'язаний до пулу проксі. Ротація — round-robin з карантином. Приклад реалізації на Python:
class ProxyRotator:
def __init__(self, proxies: list[str]):
self.proxies = proxies
self.banned: dict[str, datetime] = {}
self.idx = 0
def get_proxy(self) -> str:
for _ in range(len(self.proxies)):
proxy = self.proxies[self.idx % len(self.proxies)]
self.idx += 1
ban_until = self.banned.get(proxy)
if ban_until and ban_until > datetime.utcnow():
continue
return proxy
raise NoProxyAvailable("All proxies are in cooldown")
def report_banned(self, proxy: str, cooldown_minutes: int = 30):
self.banned[proxy] = datetime.utcnow() + timedelta(minutes=cooldown_minutes)
Узгоджений запис результатів
Кілька воркерів пишуть одночасно. Використовуємо INSERT ... ON CONFLICT DO UPDATE з умовою за часом, щоб уникнути нескінченного перезапису.
INSERT INTO scraped_products (site_id, external_id, url, data, scraped_at)
VALUES (%s, %s, %s, %s, NOW())
ON CONFLICT (site_id, external_id)
DO UPDATE SET
data = EXCLUDED.data,
scraped_at = EXCLUDED.scraped_at,
updated_at = NOW()
WHERE scraped_products.scraped_at < EXCLUDED.scraped_at - INTERVAL '1 hour';
Масштабування та моніторинг
Горизонтальне масштабування
Воркери запускаються в Docker. Горизонтальне масштабування через docker-compose або Kubernetes HPA. При додаванні нових воркерів навантаження розподіляється автоматично.
services:
scraper-worker:
image: scraper:latest
environment:
- REDIS_URL=redis://redis:6379
- DB_URL=postgresql://...
- PROXY_LIST=/run/secrets/proxies
deploy:
replicas: 5
restart: unless-stopped
Моніторинг прогресу
Координатор веде лічильники в Redis: total, done, failed. Розрахунковий час завершення простий. Дашборд (BullMQ Board) показує активні завдання та швидкість обробки.
Типові конфігурації та продуктивність
| Воркерів | Проксі | Швидкість | Підходить для |
|---|---|---|---|
| 3 | 10 датацентрових | ~500 стор/хв | Каталоги до 100 тис. товарів |
| 10 | 50 резидентних | ~1500 стор/хв | Великі маркетплейси |
| 20+ | 100+ резидентних | ~5000 стор/хв | Щоденний повний обхід |
Типові проблеми та рішення
| Проблема | Рішення |
|---|---|
| Блокування по IP | Ротація резидентних проксі з карантином |
| Дублювання завдань | Bloom filter для дедуплікації |
| Конфлікти запису | UPSERT з часовим захистом |
Що входить у роботу та етапи реалізації
Ми надаємо: архітектурну схему, налаштування черг (Redis), вибір та інтеграцію проксі, написання воркерів на Python, дедуплікацію через Bloom filter, дашборд моніторингу, документацію та навчання вашої команди. Система тестується під ваше навантаження.
Етапи:
- Аналіз цільового сайту та вимог до даних.
- Проектування архітектури: вибір стеку (Redis, PostgreSQL, Python).
- Налаштування черги та воркерів.
- Тестування під навантаженням.
- Деплой та навчання команди.
Терміни реалізації
Базова система з 2–3 воркерами, Redis та PostgreSQL: 8–10 робочих днів. Додавання динамічної ротації проксі, Bloom filter, автомасштабування та дашборду: ще 5–7 днів. Повне рішення під ключ — до 3 тижнів.
Чому варто обрати нашу реалізацію?
Ми розробили та впровадили подібні системи для 15+ клієнтів, працюємо на ринку більше 5 років. Гарантуємо стабільність при пікових навантаженнях. Зв'яжіться з нами, щоб обговорити ваш проєкт. Отримайте консультацію інженера. Замовте впровадження розподіленого парсингу.