Импорт прайса на пятьдесят тысяч позиций, который валит сайт на полчаса. YML-фид, собирающийся заново на каждый запрос маркетплейса и съедающий процессор. Рассылка, которая после сбоя ушла клиентам дважды. Знакомые истории? Все они об одном — о неправильно организованных фоновых задачах. Пока каталог маленький и писем немного, любая реализация «работает». С ростом объёмов наивные подходы начинают ронять сайт, задваивать данные и молча ломаться.
В этой статье разберём, как грамотно строить фоновую обработку в 1С-Битрикс: чем отличаются агенты, cron и очереди, почему тяжёлые операции режут на батчи, что такое идемпотентность и как применить всё это к трём типовым задачам — импорту прайсов, генерации фидов и рассылкам. Материал технический и практический; сложные интеграции такого рода мы закрываем в рамках автоматизации на 1С.
Коротко
- Любую тяжёлую операцию выносите в фон и запускайте через cron, а не агентами «на хитах».
- Режьте большие задачи на батчи с сохранением прогресса, чтобы они не падали по лимитам и продолжались после сбоя.
- Делайте задачи идемпотентными: повторный запуск не должен задваивать товары, фиды и письма.
- Обязательны блокировки от параллельного запуска, логирование и алерты — иначе задача сломается молча.
Зачем выносить работу в фон
Веб-запрос должен отвечать быстро — за доли секунды. Всё, что занимает секунды и минуты, нельзя делать в момент захода посетителя: пользователь ждёт, соединение висит, сервер занят. Импорт прайса, сборка фида, отправка тысяч писем, пересчёт остатков — это тяжёлые операции, которым не место в цикле обработки страницы.
Решение — фоновые задачи: работа выполняется отдельно от пользовательских запросов, по расписанию или из очереди, не блокируя витрину. Правильно вынесенная в фон обработка делает две вещи: сохраняет сайт быстрым для посетителей и делает саму операцию устойчивой — её можно повторить, разбить на части, отследить. Это фундамент любой серьёзной интеграции магазина.
Агенты, cron и очереди
В 1С-Битрикс для фоновой работы есть несколько инструментов, и их важно не путать.
| Инструмент | Что это | Когда применять |
|---|---|---|
| Агенты | Функции Битрикс по расписанию | Регулярные задачи платформы, обмен |
| Cron | Планировщик ОС | Чёткий запуск агентов и скриптов вне трафика |
| Очередь | Таблица/брокер задач с воркером | Нагруженные сценарии, повторы, приоритеты |
Практическая схема почти всегда одинакова: cron дёргает воркер по расписанию, воркер разбирает очередь задач батчами и обновляет их статусы. Агенты Битрикс при этом тоже запускают через cron, а не «на хитах». Выбор между простой очередью в базе и внешним брокером зависит от объёмов — не нужно тащить тяжёлую инфраструктуру туда, где хватит cron и таблицы.
Почему агенты «на хитах» — ловушка
По умолчанию агенты в Битрикс выполняются «на хитах»: платформа запускает их при заходе посетителей на сайт. Это удобно для установки, но опасно в бою. На сайте с низким трафиком агент может не запуститься вовремя — некому «пнуть» его хитом. На нагруженном сайте, наоборот, тяжёлый агент выполнится прямо в запросе случайного посетителя и затормозит ему страницу.
Итог — непредсказуемость: задача выполняется то раньше, то позже, то в самый неподходящий момент. Поэтому первое, что делают на боевом проекте, — переводят агенты на запуск через cron, отключая выполнение на хитах. Тогда фоновая работа идёт по чёткому расписанию, независимо от посещаемости, и не мешает пользователям. Как выстроить надёжный запуск и деплой таких скриптов, мы разбираем в статье про CI/CD и деплой в Битрикс.
Батчи вместо одного большого прохода
Главная причина падения тяжёлых задач — попытка сделать всё за один проход. Импорт пятидесяти тысяч строк одним куском упирается в лимит времени выполнения, память или блокировки таблиц, падает на середине и оставляет данные в противоречивом виде. Лечение — батчи: обработка порциями с сохранением прогресса.
- Разбейте вход на порции. Обрабатывайте по несколько сотен-тысяч записей за один запуск воркера.
- Сохраняйте прогресс. Запоминайте, до какой позиции дошли, чтобы продолжить с этого места.
- Держите операцию короткой. Один батч укладывается в лимиты по времени и памяти с запасом.
- Продолжайте после сбоя. Упавшая задача возобновляется с последнего сохранённого прогресса, а не с нуля.
Идемпотентность и защита от дублей
Фоновые задачи падают и перезапускаются — это норма, а не исключение. Значит, повторный запуск не должен портить результат. Свойство «повторный запуск с теми же данными даёт тот же результат» называется идемпотентностью, и без него любой сбой рождает дубли: задвоенные товары, повторные письма, дублирующиеся строки фида.
Достигается идемпотентность через уникальные ключи и отметки состояния. Товар обновляют по внешнему коду или XML_ID, а не создают заново; перед отправкой письма проверяют отметку «уже отправлено»; перед вставкой строки проверяют её наличие. При работе с сущностями каталога и заказов это удобно делать через D7-ORM Битрикс, где обращение к данным по ключам явное и контролируемое.
Импорт прайсов и обмен с 1С
Импорт прайса — классическая тяжёлая фоновая задача. Файл может весить сотни мегабайт, содержать десятки тысяч позиций с ценами, остатками и характеристиками. Наивный импорт «в один проход на хите» здесь категорически не годится.
Правильный импорт прайса собирает вместе всё, о чём мы говорили: запуск по cron, обработка батчами с сохранением прогресса, обновление по уникальному коду для идемпотентности, блокировка от параллельного запуска. Отдельно важна валидация входных данных — битый прайс не должен обнулять цены и остатки в каталоге. Когда прайсы приходят из 1С обменом CommerceML, устойчивость импорта прямо влияет на корректность витрины; наладить это помогает аудит и оптимизация 1С, а полную настройку обмена и склада — автоматизация продаж и склада на 1С.
Генерация YML-фидов
Фиды для маркетплейсов и рекламы — вторая типовая фоновая задача. Ошибка, которую делают часто: генерировать фид на каждый запрос площадки. Маркетплейс дёргает файл регулярно, и если каждый раз собирать его заново из базы, сервер задыхается, а под пиком отдаёт то битый, то устаревший фид.
Правильно — генерировать фид фоновой задачей по расписанию и складывать готовый файл, который отдаётся статикой. Для больших каталогов сборку делают порционно во временный файл, который атомарно подменяет старый по завершении — тогда площадка всегда получает целый актуальный фид, а не «полусобранный». Логику генерации фидов под разные площадки и их форматы мы подробно разбираем в материале про разработку модуля маркетплейса на Битрикс.
Рассылки без задвоений
Массовая рассылка — задача, где идемпотентность важнее всего: отправить письмо дважды хуже, чем не отправить. Наивная рассылка «в цикле по всем адресам за один проход» падает на середине по лимитам или тайм-ауту, а перезапуск шлёт письма заново тем, кто их уже получил.
- Батчи получателей. Рассылку делят на порции, каждая укладывается в лимиты выполнения.
- Отметка отправки. По каждому получателю фиксируется факт отправки; перед отправкой — проверка отметки.
- Контроль темпа. Ограничение скорости, чтобы не превысить лимиты почтового провайдера и не уйти в спам.
- Возобновление после сбоя. Перезапуск продолжает с неотправленных, а не начинает всю базу заново.
Если рассылка запускается по внешним событиям (заказ, статус, действие клиента), её удобно ставить в очередь через интеграционный слой. Как безопасно принимать такие события извне, разбираем в статье про REST, вебхуки и безопасность.
Блокировки и параллельный запуск
Cron с коротким интервалом таит подвох: если предыдущий запуск задачи ещё не завершился, cron стартует второй экземпляр. Две копии одной задачи над одними данными — это гонки, дубли и повреждение прогресса. Особенно опасно для импорта и рассылок.
Защита — блокировка (lock): перед стартом задача проверяет, не выполняется ли уже другой экземпляр, и если да — просто выходит. Блокировку реализуют через файл-флаг, запись в базе или системный механизм. Разные независимые задачи параллелить безопасно, если они не пересекаются по данным, а вот один и тот же тяжёлый процесс должен идти строго в одном экземпляре. Это одно из базовых требований к надёжной фоновой обработке.
Логирование и мониторинг
Фоновая задача опасна тем, что ломается незаметно: у неё нет пользователя, который пожалуется. Импорт молча упал — цены не обновились; фид не собрался — площадка получает старый; рассылка не ушла — акция провалилась. Всё это обнаруживают по последствиям через дни, если нет мониторинга.
- Логи с прогрессом. Старт, обработанные порции, результат и ошибки — по каждой задаче.
- Отметка последнего успеха. Задача обновляет «когда последний раз отработала успешно».
- Алерты. Не отработала в срок или упала с ошибкой — приходит уведомление ответственному.
- Метрики. Время выполнения и объёмы, чтобы видеть деградацию до того, как всё встанет.
Надёжность фоновых задач неотделима от надёжности площадки в целом: логи, ресурсы и стабильность окружения. Базовые вопросы инфраструктуры для этого мы разбираем в статье про хостинг и инфраструктуру BitrixVM.
Частые ошибки фоновых задач
- Агенты на хитах. Тяжёлая обработка выполняется в запросе посетителя и тормозит сайт.
- Один большой проход. Импорт или рассылка без батчей падает по лимитам и портит данные.
- Нет идемпотентности. Перезапуск после сбоя задваивает товары и письма.
- Фид на каждый запрос. Маркетплейс дёргает генерацию заново — сервер задыхается.
- Нет блокировки. Cron запускает второй экземпляр поверх работающего — гонки и дубли.
- Битый вход не проверяется. Повреждённый прайс обнуляет цены и остатки в каталоге.
- Нет мониторинга. Задача сломалась молча, узнали по жалобам через дни.
Чек-лист внедрения
- Запуск через cron. Агенты и воркеры стартуют по расписанию, выполнение на хитах отключено.
- Батчи настроены. Тяжёлые задачи режутся на порции с сохранением прогресса.
- Идемпотентность обеспечена. Обновление по ключам, отметки «обработано», проверка перед действием.
- Фиды кэшируются. Готовый файл отдаётся статикой, генерация атомарна.
- Рассылки защищены. Батчи, отметки отправки, контроль темпа, возобновление после сбоя.
- Блокировки стоят. Один экземпляр тяжёлой задачи, защита от параллельного запуска.
- Мониторинг работает. Логи, отметки успеха и алерты по сбоям и просрочкам.
Вывод
Фоновые задачи — та часть проекта, которую не видно на витрине, но именно она чаще всего роняет сайт и портит данные, когда сделана наивно. Импорт прайсов, генерация фидов и рассылки подчиняются одним и тем же принципам: выносить в фон и запускать через cron, резать на батчи с сохранением прогресса, делать идемпотентными, защищать блокировками и покрывать мониторингом.
В 1С-Битрикс для этого есть всё необходимое — агенты, cron, механизмы работы с данными, — но по умолчанию платформа настроена на удобство установки, а не на боевую нагрузку. Переведите фоновую обработку на правильные рельсы, и импорты перестанут ронять сайт, фиды всегда будут актуальны, а рассылки — уходить ровно один раз.
