«Ленивый» парсинг: собираем данные, не загружая страницу целиком

1. Введение в "ленивый" парсинг

1.1. Традиционный парсинг: проблемы и ограничения

Традиционный подход к извлечению данных из веб‑страниц подразумевает загрузку полного HTML‑документа, после чего применяется анализ структуры для получения нужных элементов. При таком методе наблюдаются несколько характерных ограничений.

Полная загрузка ресурса требует значительного объёма сетевого трафика, что повышает затраты при работе с большим количеством страниц.
Время отклика увеличивается из‑за передачи всех ресурсов, включая изображения, стили и скрипты, которые не участвуют в формировании целевых данных.
Динамический контент, генерируемый клиентским JavaScript, остаётся недоступным без выполнения кода, что приводит к неполным результатам парсинга.
Защита от автоматизированного доступа (CAPTCHA, ограничения по частоте запросов, проверка пользовательского агента) часто срабатывает именно при полном получении страницы.
Объём памяти, необходимый для хранения полных документов, ограничивает масштабируемость решения при обработке миллионов запросов.
Ошибки в разметке, такие как несогласованные теги или нестандартные атрибуты, усиливают вероятность некорректного извлечения данных при полном парсинге.

Эти проблемы обусловливают необходимость альтернативных методов, позволяющих ограничить объём получаемой информации и снизить нагрузку на инфраструктуру. Как специалист в области веб‑интеграций, я отмечаю, что переход к выборочному получению данных открывает возможности повышения эффективности и надёжности процессов сбора информации.

1.2. Что такое "ленивый" парсинг и его преимущества

Ленивый парсинг - метод получения нужных элементов веб‑страницы без полной загрузки её HTML‑документа. Реализуется через запросы частичного контента (HTTP Range, HEAD) или через API‑интерфейсы, позволяющие сразу вернуть только требуемые блоки (JSON, XML‑фрагменты).

Преимущества подхода:

Сокращение объёма передаваемых данных: передаётся лишь небольшая часть ресурса, что уменьшает нагрузку на канал связи.
Ускорение получения информации: время отклика сокращается, поскольку сервер не формирует полный ответ.
Снижение нагрузки на целевой сайт: ограничивается количество запросов к полному документу, что снижает риск блокировки со стороны защиты.
Экономия вычислительных ресурсов: клиент обрабатывает только релевантные данные, что уменьшает потребление памяти и процессорного времени.
Гибкость интеграции: возможность комбинировать запросы к различным эндпоинтам без необходимости парсить весь DOM‑дерево.

Таким образом, ленивый парсинг оптимизирует процесс сбора данных, делая его более эффективным и менее затратным.

2. Инструменты и технологии

2.1. Headless браузеры (Puppeteer, Playwright)

Headless‑браузеры позволяют выполнять JavaScript‑код и получать DOM‑структуру без визуального отображения страницы. Это решает задачу получения динамического контента, когда традиционный HTTP‑запрос возвращает лишь статический HTML.

Puppeteer - библиотека для управления Chromium в режиме без графического интерфейса. Основные возможности:

запуск браузера с параметром headless: true;
навигация к URL, ожидание загрузки сетевых запросов;
выполнение скриптов в контексте страницы через page.evaluate;
перехват и модификация запросов с помощью page.route;
создание PDF и скриншотов без открытия окна.

Playwright - кросс‑браузерный фреймворк, поддерживающий Chromium, Firefox и WebKit. Ключевые отличия от Puppeteer:

единый API для трёх движков, что упрощает тестирование в разных средах;
более гибкая модель контекстов (browser.newContext) для изоляции сессий;
встроенные механизмы автодоступа к элементам (auto‑wait) при взаимодействии;
поддержка мобильных эмуляций и геолокации без дополнительных настроек.

Для «ленивого» парсинга важна возможность ограничить объём загружаемых ресурсов. Оба инструмента предоставляют функции блокировки запросов по типу (image, stylesheet, font) или по URL‑шаблону, что уменьшает нагрузку и ускоряет получение нужных данных. Пример фильтрации в Puppeteer:

await page.setRequestInterception(true);
page.on('request', req => {
 const blocked = ['image', 'stylesheet', 'font'];
 req.resourceType() in blocked ? req.abort() : req.continue();
});

В Playwright аналогичный код выглядит так:

await page.route('**/*', route => {
 const blocked = ['image', 'stylesheet', 'font'];
 route.request().resourceType() in blocked ? route.abort() : route.continue();
});

Оперативная работа с сетью позволяет получать только нужный JSON‑ответ или часть HTML, минуя полную отрисовку. При этом обе библиотеки поддерживают асинхронные запросы, что упрощает интеграцию в пайплайны парсинга.

Выбор между Puppeteer и Playwright зависит от требований к кросс‑браузерности и наличию специфических функций, таких как автоматическое ожидание элементов или поддержка WebKit. Оба решения совместимы с Node.js, предоставляют типизацию через TypeScript и активно поддерживаются сообществом.

2.2. HTTP-клиенты с поддержкой частичной загрузки (aiohttp, requests)

HTTP‑клиенты, позволяющие получать лишь часть ресурса, реализуют два основных механизма: заголовок Range и потоковое чтение тела ответа. В Python наиболее распространённые библиотеки, поддерживающие эти возможности, - aiohttp (асинхронный) и requests (синхронный).

aiohttp
- формирует запрос с параметром headers={'Range': 'bytes=start-end'}; сервер возвращает статус 206 Partial Content, если диапазон поддерживается.
- метод response.content.iter_chunked(size) позволяет получать данные порциями без полной загрузки.
- асинхронный цикл async for chunk in response.content.iter_chunked(1024) обеспечивает минимальное потребление памяти и возможность параллельного получения нескольких диапазонов.
requests
- передача диапазона через headers={'Range': 'bytes=start-end'} аналогична aiohttp.
- включение параметра stream=True в requests.get отключает буферизацию полного тела и позволяет читать блоки через iter_content(chunk_size).
- response.iter_content(chunk_size=1024) последовательно отдаёт фрагменты, что удобно при работе с большими файлами или при необходимости остановить загрузку после получения нужных данных.

Оба клиента требуют, чтобы сервер поддерживал заголовок Range. При отсутствии поддержки сервер вернёт полный ответ (статус 200) и клиенту придётся обработать его полностью. Выбор между aiohttp и requests определяется требуемой моделью выполнения: асинхронная обработка больших объёмов данных более эффективна с aiohttp, синхронный код проще реализовать с requests.

2.3. Селекторы и XPath: выбор нужных данных

Селекторы и XPath - инструменты, позволяющие извлекать конкретные элементы из потока HTML‑кода без необходимости загрузки полной страницы. При «ленивом» парсинге запросы отправляются к серверу лишь с указанием интересующего фрагмента, а полученный кусок разбирается локально.

CSS‑селекторы оперируют простыми правилами, основанными на типах тегов, классах, идентификаторах и их вложенности. Пример: div.article > h2.title выделит заголовки статей, находящиеся непосредственно внутри контейнера div.article. Селекторы поддерживают комбинирование атрибутов (a[href$=".pdf"]) и псевдо‑классы (li:nth-child(3)). Их преимущество - читаемость и быстрота обработки в большинстве парсеров, построенных на библиотеках типа BeautifulSoup или Cheerio.

XPath предоставляет более гибкий способ адресации узлов, позволяя использовать оси, функции и логические выражения. Пример: //ul[@id='menu']//li[position()<4]/a[contains(@href,'download')] выберет первые три ссылки в меню, содержащие слово «download». XPath поддерживает обратный поиск (ancestor::div), проверку наличия атрибутов (@data-id) и работу с текстовыми узлами (text()). Такой уровень детализации упрощает выбор элементов в сложных DOM‑деревьях, где CSS‑селекторы могут быть ограничены.

Практические рекомендации:

При простых структурах предпочтать CSS‑селекторы; они быстрее компилируются и легче поддерживаются.
Для вложенных или условных запросов использовать XPath; он позволяет задать точные ограничения без дополнительных фильтров.
Сохранять запросы в виде констант, чтобы избежать дублирования кода и облегчить обновление при изменении разметки.
Проверять корректность селекторов на небольшом наборе страниц, используя инструменты разработчика браузера.

Сравнительная таблица:

Синтаксис - короткий, ориентированный на классы/идентификаторы (CSS) vs подробный, основанный на путях и функциях (XPath).
Поддержка - большинство парсеров реализуют CSS‑селекторы; XPath часто требует отдельного движка.
Гибкость - XPath позволяет адресовать родственные узлы и выполнять логические операции; CSS ограничен прямой иерархией.
Производительность - в типовых сценариях CSS быстрее; при сложных запросах разница нивелируется за счёт оптимизаций XPath‑движков.

Выбор между селекторами и XPath определяется структурой целевого HTML‑документа и требуемой точностью выборки. При «ленивом» парсинге, когда передаётся лишь часть страницы, правильное формирование запросов существенно снижает объём передаваемых данных и ускоряет обработку.

3. Реализация "ленивого" парсинга

3.1. Запрос только необходимых ресурсов (HTML, CSS, JavaScript)

Запрос только тех компонентов, которые действительно требуются для извлечения целевых данных, позволяет сократить объём передаваемого трафика и ускорить процесс парсинга. При этом необходимо отделить основной документ (HTML) от вспомогательных файлов (CSS, JavaScript) и получать их только в случае, когда они участвуют в формировании нужной информации.

Для реализации такого подхода применяются следующие приёмы:

отправка HEAD‑запроса для получения метаданных ресурса без передачи тела;
использование заголовка Accept с указанием предпочтительных типов (например, text/html);
фильтрация запросов через промежуточный слой (proxy, middleware) и блокировка загрузки файлов, не включённых в список необходимых;
применение функций fetch/axios с параметром range для частичной загрузки больших файлов;
в средах автоматизации (Puppeteer, Playwright) включение перехвата запросов и отмена загрузки скриптов и стилей, не влияющих на целевые элементы.

Определение перечня необходимых ресурсов происходит на этапе анализа структуры целевой страницы. Анализируются селекторы, атрибуты, скриптовые вызовы, которые модифицируют DOM. Если требуемые данные формируются исключительно серверным HTML, запросы к CSS и JavaScript исключаются. В противном случае, при необходимости выполнения клиентского кода, включаются только те скрипты, которые непосредственно влияют на формирование искомых элементов.

Контроль за запросами реализуется через настройки HTTP‑клиента или через API браузерных движков. При каждом запросе проверяется соответствие URL заданному шаблону (регулярное выражение, список доменов). Запросы, не попадающие в список, отменяются, что предотвращает загрузку лишних ресурсов и снижает нагрузку как на клиентскую машину, так и на сервер.

3.2. Использование API (если доступно)

При наличии публичного API предпочтительно использовать его вместо обращения к HTML‑странице. API предоставляет структурированные ответы (JSON, XML), что исключает необходимость анализа разметки и уменьшает объём передаваемых данных.

Для интеграции API следует выполнить следующие действия:

получить ключ доступа (если требуется аутентификация);
изучить документацию: форматы запросов, ограничения по частоте и объёму;
сформировать запрос с указанием только необходимых параметров;
обработать полученный ответ, извлекая требуемые поля;
реализовать обработку ошибок: статус‑коды, тайм‑ауты, сообщения об исчерпании лимитов.

Использование API повышает надёжность парсинга: изменения в представлении данных на сайте не влияют на работу, а ограничение трафика сохраняет ресурсы сети и ускоряет сбор информации. При отсутствии API необходимо прибегать к традиционному сканированию, однако в большинстве случаев API обеспечивает более «ленивый» способ получения данных.

3.3. Парсинг динамически подгружаемого контента

Парсинг контента, который подгружается после первоначального отображения страницы, требует доступа к данным, формируемым клиентским скриптом. Прямой запрос к HTML‑файлу часто не содержит интересующей информации, потому что она появляется в результате выполнения JavaScript‑запросов к серверу.

Для получения таких данных без полной загрузки визуального представления применяются следующие подходы:

Перехват запросов XHR/Fetch: анализ сетевого трафика позволяет выявить URL‑адреса, возвращающие JSON‑структуры или фрагменты HTML, которые затем можно запросить напрямую.
Использование API‑эндпоинтов: многие сайты предоставляют публичные или скрытые API, обслуживающие динамический контент; запрос к этим эндпоинтам возвращает готовый набор данных.
Эмуляция браузерного окружения в headless‑режиме: инструменты вроде Playwright или Puppeteer позволяют выполнить только необходимые скрипты, а не рендерить весь DOM, после чего извлекаются нужные элементы.
Применение библиотек для анализа реактивных состояний: в случае приложений на React, Vue или Angular можно получить состояние компонентов через их внутренние свойства, минуя визуальное представление.

При реализации следует учитывать характер загрузки:

Отложенная подгрузка при скролле - запросы инициируются при достижении нижней границы окна; необходимо эмулировать событие прокрутки или напрямую вызвать соответствующий API‑метод.
Пагинация через кнопки - каждый клик генерирует запрос с параметром страницы; запросы можно сформировать вручную, изменяя параметр «page» в URL.
Таймерные обновления - данные обновляются через интервалы; достаточно выполнить один запрос к источнику обновления, получив актуальную информацию.

Оптимизация процесса достигается за счёт ограничения количества запросов, использования кэширования полученных ответов и применения сжатия (gzip, brotli) при передаче данных. Ошибки сетевого уровня (429, 403) требуют внедрения стратегии повторных попыток с экспоненциальным бэкофом.

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

4. Практические примеры

4.1. Парсинг комментариев без загрузки полной страницы

Парсинг комментариев без полной загрузки страницы реализуется через прямой запрос к источнику данных, минуя отрисовку HTML‑контента.

Определение конечной точки - в инструментах разработчика (Network) отследите XHR‑запрос, который возвращает массив комментариев в формате JSON.
Формирование запроса - воспроизведите параметры (идентификатор объекта, токен доступа, параметры пагинации) в HTTP‑запросе к найденному URL.
Постраничный вывод - используйте параметры offset/limit или cursor для последовательного получения порций данных; каждый запрос возвращает только необходимый набор комментариев.
Обработка ответа - распарсите JSON, извлеките поля author, timestamp, text, при необходимости выполните очистку HTML‑тегов внутри текста.
Контроль изменения - примените заголовки If-Modified-Since или ETag для получения только новых или изменённых комментариев, тем самым уменьшая объем передаваемых данных.

Технические детали:

При наличии защиты (CSRF‑токен, авторизационные cookies) включайте соответствующие заголовки в запрос.
Для сайтов, использующих динамический подгруз комментариев через GraphQL, формируйте запросы в соответствии со схемой, указывая требуемые поля в query.
При необходимости обхода ограничений скорости запросов соблюдайте интервалы между запросами, задавая sleep или используя асинхронные очереди.

Эти шаги позволяют собрать полную коллекцию комментариев, не загружая полностью страницу и не инициируя рендеринг клиентского кода.

4.2. Извлечение данных из бесконечно прокручивающихся страниц

Извлечение информации с сайтов, реализующих бесконечную прокрутку, требует обхода механизмов динамической подгрузки без полной загрузки HTML‑документа. Основная цель - получить требуемый набор записей, минимизируя количество запросов к серверу и объем передаваемых данных.

Для решения задачи применяется последовательный запрос ресурсов, формируемых клиентским скриптом при скроллинге. Наиболее надёжный способ - анализировать сетевой трафик браузера и определить URL‑адреса, использующие параметры offset, page, cursor или токен последней полученной записи. После идентификации шаблона запроса можно воспроизводить его программно, получая данные в формате JSON, XML или CSV.

Ключевые этапы реализации:

Открыть страницу в инструментах разработчика, включить мониторинг XHR/Fetch‑запросов.
Выполнить несколько скроллов вручную, зафиксировать параметры запроса, которые меняются при каждой подгрузке (например, page=2, cursor=abc123).
Сформировать шаблон HTTP‑запроса, включив необходимые заголовки (User‑Agent, Referer, cookies).
Автоматизировать цикл запросов:
- отправить запрос с текущим значением параметра;
- распарсить полученный ответ, извлечь нужные поля;
- обновить параметр согласно значению из ответа (например, next_cursor).
Остановить процесс, когда сервер вернёт пустой набор данных или отсутствие токена следующей порции.

При отсутствии явного API возможен вариант с имитацией поведения браузера: использовать безголовый движок (Playwright, Puppeteer), выполнять скролл страницы небольшими шагами и фиксировать изменения DOM. После каждой итерации следует извлекать уже загруженные элементы через селекторы, а не скачивать весь HTML‑документ.

Дополнительные рекомендации:

Ограничить частоту запросов (например, 1‑2 секунды) во избежание блокировки IP.
При работе с токенами учитывать их срок жизни; при истечении токена требуется выполнить повторную авторизацию.
Сохранять промежуточные результаты в локальном кэше, чтобы при сбое можно возобновить процесс с последней полученной позиции.
При необходимости использовать компрессию (Accept-Encoding: gzip) для снижения объёма передаваемых данных.

Применяя описанные методы, можно собрать полные наборы данных с бесконечно прокручиваемых страниц, избегая полной загрузки визуального представления и существенно экономя ресурсы сетевого взаимодействия.

4.3. Получение информации из AJAX-запросов

Получение данных из AJAX‑запросов является ключевым элементом стратегии «ленивого» сбора информации, позволяющей избежать полной загрузки HTML‑документа. При этом подходе парсер направлен непосредственно к сетевому трафику, генерируемому клиентским скриптом, и извлекает нужные ответы в их оригинальном виде.

Для реализации этой техники требуется выполнить несколько последовательных действий:

Проанализировать сетевой журнал браузера (например, инструменты разработчика) и определить URL‑адреса, используемые для асинхронных запросов. Часто такие запросы относятся к эндпоинтам /api/…, /ajax/… или к параметрам fetch.
Выяснить тип HTTP‑метода (GET, POST и другое.) и набор передаваемых параметров. При POST‑запросах следует зафиксировать тело (payload) в формате application/json, form-data или x-www-form-urlencoded.
Сформировать запрос из кода парсера, воспроизводя заголовки, необходимые для аутентификации (cookies, токены, CSRF‑поле). Точная копия заголовков гарантирует получение того же ответа, что и при работе в браузере.
Выполнить запрос к целевому эндпоинту, используя библиотеку, поддерживающую асинхронный ввод‑вывод (например, aiohttp или httpx). Асинхронный режим сохраняет «ленивый» характер процесса, позволяя параллельно обрабатывать несколько запросов.
Обработать полученный JSON‑ или XML‑ответ: распарсить структуру, выделить интересующие поля, выполнить необходимую трансформацию (приведение типов, удаление дубликатов).

Особенности, влияющие на корректность получения данных:

Динамические токены - часто генерируются при каждой загрузке страницы. Их можно извлечь из предварительного GET‑запроса к странице‑контейнеру или из JavaScript‑переменных, встроенных в HTML.
Пагинация - API может поддерживать смещение (offset) или курсор (cursor). Параметры пагинации следует включать в последовательные запросы до момента, когда сервер вернёт пустой набор.
Ограничения по частоте - сервер может ограничивать количество запросов в единицу времени. Реализация задержек (await asyncio.sleep) и обработка кода 429 позволяют избежать блокировки.
Кеширование - заголовки ETag и If-None-Match позволяют сократить объём передаваемых данных, получая только изменения.

В результате, построив поток запросов к AJAX‑эндпоинтам и обработав ответы в их исходном формате, можно собрать требуемую информацию без загрузки полной разметки страницы, что существенно снижает сетевой трафик и ускоряет процесс анализа.

5. Оптимизация и лучшие практики

5.1. Обработка ошибок и повторные запросы

В процессе «ленивой» выборки данных ошибки неизбежны; их корректная обработка определяет надёжность системы.

Существует несколько категорий проблем: сбои соединения, превышение времени ожидания, полученные HTTP‑коды ≥ 400, а также исключения, возникающие при разборе частичных фрагментов HTML. Каждая из них требует отдельного реагирования.

Для восстановления работы применяются проверенные схемы:

ограничение числа повторных запросов (например, 3 попытки);
экспоненциальное увеличение интервала ожидания между попытками (1 с → 2 с → 4 с);
случайный «джиттер» для распределения нагрузки;
прекращение попыток при получении конечных ошибок (4xx кроме 429);
использование «цепочки» отказов, которая временно блокирует запросы к проблемному ресурсу.

Реализация обычно включает блок try‑catch, фиксирование типа исключения, запись в журнал и условный переход к следующей попытке. При повторных запросах следует сохранять идентификаторы уже полученных фрагментов, чтобы избежать дублирования и обеспечить идемпотентность операции.

Пример псевдокода:

attempt = 0
max_attempts = 3
delay = 1
while attempt < max_attempts:
 try:
 fragment = fetch_partial(url, offset, size)
 process(fragment)
 break
 except (TimeoutError, ConnectionError) as e:
 attempt += 1
 if attempt == max_attempts:
 raise
 sleep(delay)
 delay *= 2
 except ParseError:
 log(e)
 raise

Такой подход гарантирует, что при временных сбоях система автоматически восстанавливается, а при постоянных ошибках предоставляет исчерпывающую информацию для дальнейшего анализа.

5.2. Соблюдение robots.txt и этикета парсинга

В процессе «ленивого» сбора данных соблюдение правил, описанных в robots.txt, и соблюдение общепринятого этикета парсинга является обязательным условием корректной работы скриптов.

Файл robots.txt размещается в корневом каталоге сайта и содержит директивы, ограничивающие доступ автоматических клиентов к определённым ресурсам. Доступ к файлу осуществляется отдельным HTTP‑запросом, что позволяет избежать загрузки полной страницы. После получения содержимого необходимо проанализировать директивы User-agent, Disallow и Allow в соответствии с выбранным идентификатором клиента.

Для обеспечения соответствия рекомендуется выполнить следующие действия:

выполнить запрос GET /robots.txt перед началом любого обхода;
извлечь правила, относящиеся к текущему User-agent (или к *);
проверить каждый целевой URL на соответствие ограничениям Disallow;
при отсутствии явного разрешения запросить только разрешённые пути;
учитывать директиву Crawl-delay, если она присутствует, и внедрять паузы между запросами.

Этикет парсинга подразумевает дополнительные меры, помогающие снизить нагрузку на сервер и избежать блокировок:

указывать в заголовке User-Agent корректную строку, содержащую контактные данные разработчика;
ограничивать количество одновременных соединений (не более 1‑2 запросов в секунду, если нет указаний о более низкой частоте);
обрабатывать коды ответа 4xx/5xx, прекращать запросы к ресурсам, возвращающим постоянные ошибки;
сохранять журнал запросов для последующего анализа и корректировки стратегии обхода.

Нарушение правил robots.txt или игнорирование этикета приводит к блокировке IP‑адресов, ухудшению репутации проекта и возможным юридическим последствиям. Поэтому каждый этап «ленивого» парсинга должен включать проверку и соблюдение указанных требований.

5.3. Масштабирование и параллельная обработка данных

Масштабирование процесса извлечения данных при «ленивом» парсинге подразумевает распределение нагрузки между независимыми вычислительными блоками, что позволяет обрабатывать запросы без полной загрузки целевых страниц. При росте объёма целевых URL‑адресов увеличивается количество одновременных подключений и требуемая пропускная способность, поэтому монолитный скрипт быстро теряет эффективность.

Для организации параллельной обработки применяется модель «producer‑consumer». Основной поток формирует задачи - отдельные запросы к ресурсам, минимизируя объём передаваемых данных (заголовки, частичные тела). Задачи помещаются в очередь, откуда их берут воркеры. Воркеры могут быть реализованы как процессы, потоки или асинхронные корутины, в зависимости от доступных системных ресурсов. Асинхронный ввод‑вывод (asyncio, libuv) уменьшает количество блокирующих операций, позволяя одновременно обслуживать сотни соединений.

Ключевые приёмы масштабирования:

Шардирование очереди: разделение задач по отдельным брокерам (RabbitMQ, Kafka) снижает конкуренцию за ресурсы.
Пул соединений: предварительное создание TCP‑соединений с целевыми серверами, повторное их использование.
Кеширование заголовков и метаданных: хранение часто запрашиваемых параметров в Redis или Memcached уменьшает количество повторных запросов.
Автоматическое масштабирование: запуск дополнительных воркеров в облаке (AWS Lambda, Google Cloud Run) при превышении порога нагрузки.
Балансировка нагрузки: распределение запросов между несколькими IP‑адресами или прокси‑сервером для обхода ограничений целевых сайтов.

Эффективность параллельной обработки измеряется показателями QPS (запросов в секунду), латентностью отклика и использованием CPU/Memory. Балансировщик должен учитывать текущую загрузку воркеров, перенаправляя задачи к менее загруженным экземплярам. При возникновении ошибок (тайм‑аут, 5xx) задача помещается в отдельный ретраи‑очередь с экспоненциальным увеличением задержки.