Веб-краулер — это не попытка скачать весь интернет, а задача про то, что обходить сейчас, что отложить и как не перегружать чужие сайты.
Глава помогает связать очередь обхода, приоритизацию URL, ограничения по хостам, повторный обход и путь от сырой страницы до поискового индекса.
В интервью и инженерных обсуждениях кейс полезен тем, что проверяет умение проектировать систему с бесконечным входным пространством и очень неоднородным внешним миром.
Конвейерное мышление
Критичны приём данных, партиционирование, удаление дублей и задержки между стадиями обработки.
Слой сервинга
Решения по индексам, локальности кэша и пути запроса определяют пользовательскую задержку.
Окно консистентности
Явно фиксируйте, где допустима согласованность в конечном счёте и где нужны более строгие гарантии.
Стоимость и свежесть
Балансируйте скорость обновления данных и стоимость вычислений/хранения.
Источник
System Design Interview
Web Crawler — один из базовых кейсов, на котором удобно обсуждать очередь обхода, бережный режим и масштабирование.
Web Crawler — это система для , в которой нужно одновременно расширять покрытие и не превращать чужие сайты в собственный источник отказов. Поэтому архитектура строится вокруг , по доменам и повторного обхода страниц с разной важностью.
Требования
Функциональные
Принимать стартовый набор URL и постепенно расширять покрытие.
Соблюдать robots.txt, crawl-delay и ограничения частоты запросов для каждого хоста.
Извлекать контент и ссылки, приводить URL к каноническому виду и удалять дубликаты.
Планировать повторный обход с разной частотой для быстро меняющихся и стабильных страниц.
Передавать результат в контур индексации поиска.
Нефункциональные
Масштаб: миллиарды URL
Очередь обхода и хранилища должны масштабироваться горизонтально.
Актуальность обхода: минуты-часы
Важные и часто меняющиеся страницы должны переобходиться заметно быстрее.
Бережный режим обхода: справедливость по доменам
Нельзя бомбардировать один хост плотной серией запросов.
Надёжность: восстановление после сбоев
Очереди и контрольные точки не должны терять прогресс обхода.
Общая архитектура
Веб-краулер: общая схема
очередь обхода, планирование, загрузка, разбор и сохранение данныхКонтур управления
Контур обработки
Краулер разделён на контур управления и контур обработки: первый отвечает за приоритеты и ограничения, второй — за загрузку, разбор и публикацию данных.
Как и в других распределённых кейсах, здесь полезно явно разделять и . Так можно отдельно масштабировать приоритизацию и ограничения по доменам, не смешивая их с самой загрузкой и разбором страниц.
Поток обхода
Разбор потока обхода
Переключайте сценарии и просматривайте ключевые шаги.
Для краулера важно не путать URL и документов: первое убирает лишние варианты адресов, второе не даёт повторно тянуть один и тот же контент дальше в хранение и индекс. Повторный обход при этом всегда остаётся балансом между и стоимостью сетевого трафика.
Путь первой загрузки: заметки
- Очередь обхода выдаёт URL с учётом приоритета, глубины и справедливости между хостами.
- Планировщик проверяет бюджет хоста и выдерживает crawl-delay перед выдачей задания.
- Загрузчик запрашивает страницу, а парсер извлекает контент и ссылки.
- После приведения URL к каноническому виду новые адреса возвращаются в очередь обхода.
- Документ и метаданные передаются в контур индексации.
Путь повторного обхода: заметки
- Сервис оценки актуальности выбирает URL для переобхода по окну устаревания и сигналам важности.
- Для часто меняющихся страниц повторный обход запускается чаще, для стабильных — реже и пакетно.
- Условные запросы через идентификатор версии ресурса и Last-Modified уменьшают сетевой трафик и нагрузку на CPU.
- Результат обхода пишется в журнал событий краулера для повторных попыток и наблюдаемости.
- URL возвращается в очередь обхода с обновлённым `next_fetch_at`.
Упрощённая схема данных
queue_state: хэш URL, приоритет, `next_fetch_at`, ключ хоста, глубина обходаhost_budget: ключ хоста, число токенов, скорость пополнения, `crawl_delay_ms`seen_urls: хэш URL, время первого появления, статус последнего обходаpage_store: идентификатор страницы, URL, ссылка на контент, время загрузки, контрольная суммаcrawl_events: начало обхода, успешная загрузка, ошибка, постановка на повтор
Надёжность и типичные ошибки
Очередь обхода держит прогресс, но сама по себе не спасает от сбоев. Перезапуск без потери состояния дают , отдельный проблемный хост отсекает , а лавину повторов сдерживает .
Рабочие паттерны
- Идемпотентная обработка: повторный обход одного URL не ломает состояние системы.
- Контрольные точки в очереди обхода и смещениях очередей позволяют перезапуститься без потери прогресса.
- Размыкатель цепи по хостам защищает систему от проблемных доменов.
- Адаптивные повторные попытки: экспоненциальная пауза со случайным разбросом зависит от типа ошибки.
- Шардирование очереди обхода по хэшу хоста снижает конкуренцию за блокировки.
Ошибки, которые часто встречаются
- Глобальная FIFO-очередь без ограничений по хостам быстро приводит к блокировкам и банам.
- Отсутствие приведения URL к каноническому виду (`utm`, trailing slash, регистр) раздувает число дублей.
- Одинаковый переобход для всех страниц без оценки важности и актуальности.
- Хранение всего контента только в оперативных очередях без надёжного слоя хранения.
- Игнорирование robots.txt и юридических ограничений.
Спецификация
Robots Exclusion Protocol
Официальная спецификация robots.txt и правил взаимодействия crawler с сайтами.
Ключевой компромисс: против бережного режима обхода и юридических ограничений. На интервью важно показать, как вы ограничиваете скорость по доменам, управляете повторным обходом и сохраняете устойчивость при отказах внешних источников.
Связанные главы
- Search System - Показывает, как обход веб-страниц питает индекс, обработку запросов и ранжирование.
- Distributed File System - Снимки страниц и артефакты обхода нужно где-то надёжно хранить — здесь разбирают, как пережить сбой и не потерять накопленное.
- Rate Limiter - Углубляет разговор про ограничения по хостам, паузы между запросами и защиту внешних источников от перегрузки.
- CDN - География трафика и сетевые задержки напрямую бьют по стратегии обхода и свежести данных — этот кейс показывает, откуда они берутся.