Проектирование веб-краулера. Как решать System Design?

От «Hello World» до кернел-паники

Базовый скрипт с бесконечным циклом обхода URL — это не краулер, а DDoS-генератор с обратной связью. На первом же шаге вы упираетесь в три стены: rate limiting со стороны целевых сайтов (и ваш IP в бане за пять минут), отсутствие какой-либо дедупликации (вы будете парсить одну и ту же страницу тысячу раз) и отсутствие обработки ошибок (таймаут одного сайта роняет весь процесс).

Реальный краулер начинается не с кода, а с очередей. Вам нужна очередь задач (URL для обхода) и очередь результатов. Именно здесь начинается настоящий System Design: как сделать систему распределённой, устойчивой к падениям нод и умеющей масштабироваться.

Анатомия живого краулера

Сердце системы — менеджер очередей (часто на базе Redis, RabbitMQ или Kafka). Он решает две главные проблемы: дедупликацию URL (чтобы не лезть на одну страницу дважды) и приоритизацию (какие ссылки обходить первыми).

Далее идут воркеры. Это изолированные процессы (или контейнеры), которые берут URL из очереди, делают HTTP-запрос, парсят ответ, извлекают новые ссылки и кладут их обратно в очередь. Ключевой момент — изоляция. Падение одного воркера не должно уронить систему. Если ваш воркер — это один большой скрипт с глобальным состоянием, у вас не система, а костыль.

Не забываем про хранение. Сырые HTML-страницы, метаданные (время обхода, код ответа), извлечённые данные. Реляционная БД для структурированных данных, S3-подобное хранилище для сырых дампов. И отдельный сервис для проверки `robots.txt` и соблюдения задержек между запросами к одному домену — иначе вас забанят по IP-блоку.

Что делать на практике

Если вы проектируете систему для собеседования или реального проекта, начните с простой схемы: `Scheduler -> Queue -> Worker Pool -> Storage`. Затем добавляйте слои: кеширование DNS, обход JavaScript-рендеринга (здесь PhantomJS или headless Chrome в отдельном контейнере), ротацию User-Agent, обработку зеркал и дубликатов контента.

И главное: проектируйте для провалов. Воркер упал посередине обработка? Задача должна вернуться в очередь с таймаутом. Сайт вернул 429 (Too Many Requests)? Добавляем экспоненциальную задержку. Ваш IP заблокировали? Меняем прокси-пул.

Итог прост. Краулер — это не скрипт, это распределённая система с десятками точек отказа. Если вы не можете на схеме нарисовать, что происходит при падении любого компонента, у вас нет дизайна — у вас есть мечта, которая упадёт на проде в пятницу вечером.

А если всё-таки пишете прототип — начните с бэкапов. Это не шутка.