Парсер новостей: где ломается сбор ленты на масштабе
На десятке источников парсер новостей кажется рабочим: лента читается, материалы появляются. На сотнях изданий с разной периодичностью сбор новостных лент даёт сбои, о которых команда узнаёт от читателей, а не от системы. Часть источников отдаёт время публикации в своём часовом поясе, часть — только дату без часа, а порядок элементов при повторном опросе меняется, поэтому «последние N записей» не совпадают с тем, что реально вышло за сутки, — так появляются пропущенные публикации.
Отдельная головная боль — дубликаты при обновлении ленты. Издатель меняет структуру ссылки, дописывает служебные параметры адреса, переносит материал в другую рубрику, — и та же новость заходит в базу второй раз. Пока ключ записи зависит от порядка полей и украшений в ссылке, дедупликация опирается на заголовок, а его правят уже после выхода материала.
Узкое место сбора обычно одно: единый цикл опроса по всем источникам. Медленный ответ одного издания задерживает остальные, интервал растёт, а на пиках задачи отваливаются по времени ожидания — самые активные ленты остаются неопрошенными именно тогда, когда новостей больше всего. Дальше начинается ручная догрузка: редактор открывает сайты и копирует материалы вручную.
Разбираем, как это закрывается: отдельная очередь на источник, свой интервал опроса вместо общего круга, устойчивый ключ записи и повторный проход по окну времени после сбоя.
Какой эффект даёт управляемый сбор новостей
Полнота сбора публикаций перестаёт зависеть от того, как источник отдаёт ленту. Часть материалов терялась на постраничной навигации и в разметке — до 10–15% пропусков; после перевода сбора на несколько каналов сразу (лента, выдача, архив) пропуски падают до долей процента и подтверждаются сверкой с источником.
Задержка появления материала измеряется минутами. Интервал опроса адаптивный: активные источники проверяются чаще, спокойные реже, а при всплеске публикаций очередь не растёт — новая запись оказывается в системе в пределах нескольких минут, а не к следующему ручному прогону.
Доля ручных догрузок сокращается с 10–15% выпусков до единичных случаев. Редактор вмешивается только там, где источник отдал неполный текст или битую ссылку, и такая запись приходит с пометкой о причине, а не выясняется уже на вёрстке.
Отдельный эффект — ушедший класс отказов на смене вёрстки источника. Правила разбора вынесены в конфигурацию рядом с шаблонами типовых платформ вроде WordPress: переезд на новую тему ломает только один адаптер, остальные источники продолжают собираться, а расхождение видно в журнале разбора.
В сумме это стабильность сбора ленты: предсказуемая полнота, короткая задержка появления записи и короткий список мест, куда смотрит инженер.
Форматы сбора: парсер новостей по расписанию и по событию
У одного источника обычно несколько точек доступа к контенту, и выбор между ними определяет и полноту выборки, и стоимость поддержки. Ниже — режимы, которые мы комбинируем в одном сборщике, и честные ограничения каждого.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Разбор открытой ленты (RSS, Atom, JSON Feed) | Источник сам публикует ленту | В ленте часто только анонс и обрезанный текст, даты в разных зонах, у части изданий задержка публикации |
| Обход разделов источника | Ленты нет или она неполная | Привязка к разметке ломается при редизайне, нужны пагинация, обход зеркал и лимит запросов |
| Разбор полного текста статьи | Нужен текст целиком, а не анонс | В выборку попадают навигация, реклама и блоки «читайте также», нужны правила очистки и канонизация ссылок |
| Событийный опрос источников | Важна скорость реакции | Не все источники отдают уведомления, нужен запасной путь по расписанию и защита от повторной доставки |
| Сбор по расписанию | Базовый режим для всего массива | Интервал — компромисс между свежестью и нагрузкой, есть суточные окна публикаций и ограничения на число запросов |
Как комбинируем режимы
На практике мы не выбираем один вариант: сбор по расписанию закрывает весь список источников, а событийный опрос включается там, где задержка критична. Обязательные элементы любого режима — дедупликация по идентификатору записи и хешу текста, глубина окна публикации и предсказуемое поведение при недоступности источника: пропуск с отметкой и повтор в следующем цикле вместо остановки всего сбора. Если источник ужесточает ограничения сбора, часть источников переводится на более редкий обход — выборка остаётся полной, а нагрузка на издателя снижается.
Этапы внедрения парсера: от аудита источников до передачи
Парсер новостей редко ломается на коде — чаще отказывает источник: меняется разметка, включается ограничение частоты обращений, часть публикаций уходит в архив. Поэтому работа идёт последовательно, от аудита источников к передаче, и каждый следующий шаг опирается на результат предыдущего.
- Аудит источников. Разбираем список лент: какие отдают полный текст, какие только анонс, в каком виде приходят даты, есть ли архив и лимиты на частоту запросов. На выходе — перечень источников с приоритетом и режимом обхода.
- Схема нормализации полей. Публикации из разных лент приводим к единому набору: заголовок, дата, тело, ссылка, автор, рубрики. Отдельно описываем приведение дат к одному часовому поясу и разбор кодировок — иначе в хранилище появляются дубли и записи без содержания.
- Правила обхода ленты. Задаём периодичность опроса, глубину добора при первом запуске, дедупликацию по ссылке и отпечатку текста. Здесь же описываем поведение при недоступности источника и повторный добор пропущенного окна.
- Проверка на эталонной выборке. Собираем вручную размеченный набор публикаций за период и сверяем с ним результат: доля верно извлечённых полей, число ложных дублей, потерянные записи. Правила и разбор разметки правятся до стабильного результата.
- Передача решения заказчику. Отдаём конфигурации источников, описание схемы полей, инструкцию по подключению новой ленты и оповещения о сбоях, которые срабатывают раньше, чем проблему заметит читатель.
Дальше идёт сопровождение: обновление правил под изменённую разметку, добавление лент и контроль качества выгрузки держат поток публикаций непрерывным без переписывания ядра.
Комплект передачи: конфигурации, схемы обхода, регламенты
Комплект собирается так, чтобы сбор можно было вести и развивать своими инженерами, а не только силами авторов решения. Каждый артефакт привязан к конкретному источнику и отвечает на вопрос «что делать, если он изменится» — это отличает рабочую передачу от папки с документами.
- Описание источников: карта лент и разделов — формат выдачи, частота публикаций, часовой пояс, перечень забираемых полей.
- Правила обхода лент: интервалы опроса, порядок обхода, лимит параллельных запросов, пауза при ограничении частоты, инкрементальный сбор по дате и идентификатору.
- Политики доступа к данным: где допустим автоматический сбор, как хранится и ротируется авторизация, что делаем по запросу правообладателя.
- Схемы обхода ограничений: резервные маршруты через зеркала и официальные интерфейсы, пулы прокси, повторы с ростом паузы.
- Журналы сбора: по каждому источнику — сколько записей пришло, сколько отсеялось на валидации, задержка относительно публикации, доля ошибок.
- Модель данных: ключи дедупликации, правила нормализации текста и дат, сроки хранения и архивации.
- Регламент сопровождения: пороги оповещений, сроки реакции на упавший источник, чек-лист при смене разметки на стороне площадки.
- Инструкция по расширению: как добавить источник конфигурацией и прогнать его на тестовой выборке.
Артефакты лежат рядом с кодом и покрыты проверками: смена разметки ловится тестом, а не обращением к нам. Добавление нового источника сводится к правке конфигурации.
Кейс: как сбор ленты перестал падать на пиковых нагрузках
История про редакцию отраслевых новостей: лента собиралась вручную, обход источников — раз в сутки, поэтому анонсы и релизы выходили в окно с задержкой, а часть материалов догружали ночью в аварийном режиме. На пиках публикаций — крупное событие, конференция, сезон отчётности — очередь источников не разбиралась, и выпуск сдвигался на часы.
Что было до
Сбор держался на ручных операциях: редактор обходил источники, копировал материалы и сверял их с уже опубликованными глазами. Замеры за месяц: до трети записей — повторы одного и того же релиза, 5-7 аварийных догрузок в неделю, на пиковой волне терялось до 15% публикаций. Ленты опрашивались целиком, без учёта изменений, поэтому нагрузка на источники росла вместе с объёмом архива.
Что изменили и что получилось
Сбор разнесли на два контура: ленты партнёров по RSS и каналы в Telegram, у каждого — свой интервал опроса и свои правила разбора. Ключом записи стал хэш содержимого, поэтому повторный материал не создаёт новую карточку, а обновляет существующую; недоступный источник уходит в очередь повторов с нарастающей паузой, а не роняет выпуск.
Отдельно вынесли наблюдаемость: задержка по каждому источнику, число новых записей, доля отклонённых — всё видно в панели, и сбой источника перестал быть сюрпризом для редакции. После перехода пропуски на пиках — нулевые, доля дублей — ниже половины процента, пиковая волна разбирается за минуты, аварийные догрузки ушли как класс работ.
Чем отличается сбор по RSS от разбора страниц источника
Сбор по RSS — это работа с контрактом: источник сам отдаёт структурированный документ, где для каждой публикации уже размечены заголовок, ссылка, дата и текст или анонс. Парсер читает такой поток целиком, не зависит от вёрстки и дедуплицирует записи по идентификатору и адресу. Отсюда главное свойство: канал быстрый, стабильный и почти не требует сопровождения — ломается он в разы реже, чем разбор разметки.
Полнота открытой ленты — не гарантия, а вопрос политики редакции. Часть рубрик в поток не отдаётся, вместо полного текста приходит анонс, метки, авторы и разделы теряются, а история усечена до последних записей: при первом запуске архив собрать неоткуда. Именно здесь заканчивается зона RSS и начинается разбор страниц источника.
Разбор страниц идёт по обходу: разделы, пагинация, лента архива по датам, карта сайта. Селекторы привязываются к блокам публикации, дата вытаскивается из разметки или адреса и нормализуется, тексты чистятся от навигации. Полнота выше — видно всё опубликованное, включая материалы вне ленты, — но появляется хрупкость: смена шаблона или переход на подгрузку содержимого скриптами ломает выборку, поэтому нужны рендеринг, контроль сбоев и сверка с эталоном.
На практике сравнение способов сбора заканчивается гибридом. Лента работает основным каналом с малым интервалом опроса, разбор добирает архив и закрытые для ленты рубрики, а пересечение двух множеств показывает, сколько уникальных материалов даёт каждый путь и что именно теряется без обхода.
Выбор режима сбора определяется наличием и полнотой ленты, требуемой глубиной архива, частотой публикаций и допустимой задержкой появления материала в системе. Дальше разбираем, как из этого вырастает расписание опроса и правила дедупликации.
Технические сомнения, которые стоит снять до старта
Сомнения, которые стоит снять до старта, касаются не «прочитает ли парсер ленту», а границ самих источников. RSS и Atom отдают усечённое окно — только последние записи, закрытые источники требуют авторизации и лимитов на обращения, а одна новость приходит из нескольких лент с разными заголовками и ссылками.
Ниже — вопросы, которые чаще всего задают инженеры заказчика перед стартом.
Источник отдаёт только последние записи — старые новости потеряются?
Да, если первый запуск идёт по усечённой ленте. Поэтому на старте делаем первичный обход архива: пагинация по разделам, индексные страницы, карта сайта. Дальше храним идентификатор последней обработанной записи и на каждом цикле читаем только новое — пропуск возможен лишь при сбое, который шире окна ленты, поэтому обход ставим чаще, чем лента успевает переполниться.
Как подключаются закрытые источники?
Через штатный доступ по подписке: учётные данные храним в защищённом хранилище, соблюдаем лимит обращений на источник, при отказе авторизации останавливаем обход этого источника и подаём сигнал — вместо повторов, которые могут привести к блокировке.
Как контролируются дубликаты?
Новость сравнивается по канонической ссылке, нормализованному заголовку и отпечатку текста в скользящем окне времени. Совпадения сводятся в одну запись со списком источников — в базе нет «трёх одинаковых новостей», а видно, кто опубликовал первым.
С какой частотой обновляются данные?
Интервал настраивается по каждому источнику: от минут для новостных лент до часов для аналитических. Запрашиваем с условием «изменилось ли с прошлого раза», поэтому неизменённые страницы не перекачиваются, а параллельные обращения ограничены на уровне домена.
Что происходит, если источник недоступен?
Повторы с нарастающей паузой, затем временное отключение источника. Отказы изолированы: падение одного не останавливает остальные, накопленное дочитывается после восстановления, а инженер получает уведомление с историей ошибок.
Обсудим задачу и вернёмся с планом работ
Чтобы оценка была точной, а не «средней по рынку», нам нужен прикладной срез задачи: что собираем, откуда и с какой регулярностью. Ниже — перечень вводных, по которым мы считаем объём работ, схему хранения и планируем запуск. Чем конкретнее исходные данные, тем меньше допущений в смете.
- Перечень источников: адреса лент и разделов, открытые программные интерфейсы, обычные страницы, карты сайта. Отметьте, где нужна авторизация и где источники отдают данные нестабильно.
- Ожидаемая частота обновления: раз в минуту, раз в час или ежедневно — от этого зависит режим опроса, нагрузка и запас по времени до появления материала в системе.
- Целевые поля: заголовок, дата и время публикации, автор, полный текст или анонс, рубрика, ссылка на оригинал, изображения. Укажите, какие поля обязательны, а какие допустимо оставить пустыми.
- Правила обработки: нужны ли перевод, пересказ, приведение дат к единому часовому поясу, разметка тем и удаление повторов одного материала из разных источников.
- Требования к хранению: срок жизни записей, глубина архива, нужна ли история изменений материала при правке на стороне источника.
- Правила доступа: кто и как читает данные — внутренняя система, выгрузка в файл, отдельный интерфейс; какие нужны роли и ограничения.
- Критерии приёмки: какие источники и поля считаем закрытыми, как проверяем пропуски и как быстро источник должен восстанавливаться после сбоя на его стороне.
Пришлите эти вводные в любом виде — списком, таблицей или ссылками на существующие выгрузки. Мы разберём их, уточним спорные места и вернёмся с оценкой, планом работ и порядком запуска.
