Интернет-магазин на 50 000 SKU синхронизируется с 1С:УТ каждые 5 минут. Прямые OData-запросы блокируют базу на 40 секунд. При росте каталога синхронизация перестаёт укладываться в интервал: заказы обрабатываются с задержкой, остатки на сайте расходятся с реальными.
Что было до оптимизации
Сайт на Next.js, 1С:УТ 11.4, интеграция через OData. Раз в 5 минут Node.js-сервис забирал изменения по номенклатуре и остаткам, писал в PostgreSQL. Запросы выполнялись синхронно. Замеры: полная выгрузка — 42 секунды, изменения (100–300 позиций) — 12 секунд. В пиковые часы (10:00–12:00) выгрузка занимала 1 минуту 20 секунд, часть запросов падала из-за превышения времени ожидания. Остатки на сайте устаревали до 15 минут. Всё это время 1С была заблокирована для других пользователей.
Почему нельзя было просто «добавить индекс»
Добавили индексы, переписали часть запросов. Выигрыш — 15–20%. Корневая проблема осталась: синхронные запросы блокируют базу. Нужно было менять архитектуру.
Новая архитектура: асинхронный шлюз
Процесс разбит на три независимых этапа. Первый: 1С каждые 30 секунд формирует изменения и отправляет в RabbitMQ. Второй: обработчики на Node.js разбирают очередь и обновляют PostgreSQL. Третий: сайт читает только из PostgreSQL и Redis-кэша и никогда не обращается к 1С напрямую.
Ключевые детали. Изменения строятся по полю _Version в 1С: $filter=_Version gt {lastVersion} возвращает только изменённые записи. Защита от повторной обработки через idempotency_key в сообщении. Упал обработчик — сообщение не удаляется из очереди, а переотправляется.
Что с заказами
Заказы идут в обратную сторону: клиент оформляет заказ → очередь orders.out → обработчик создаёт документ в 1С. Если 1С недоступна — заказ ждёт в очереди, при восстановлении очередь разбирается за 10–15 секунд. Потерь нет.
Метрики после оптимизации
Полная выгрузка: 3,4 сек (было 42). Изменения (300 позиций): 0,7 сек (было 12). Задержка от изменения в 1С до появления на сайте: 1,8 сек (было до 15 минут). Нагрузка на 1С упала в 8 раз — база перестала блокироваться. Доступность за 6 месяцев — 99,97%.
Что пошло не так
При массовом изменении (переоценка всего каталога) 1С генерировала изменения на 50 000 позиций одним пакетом. Очередь забивалась, обработчики не успевали. Решение: пакеты по 500 записей, 8 параллельных обработчиков.
Чек-лист для своей интеграции
- Замерьте начальные показатели: сколько занимает синхронизация сейчас.
- Проверьте наличие поля версии в 1С (
_Version,Version) — без него синхронизация изменений не работает. - Настройте очередь с сохранением сообщений (RabbitMQ с дисковым хранилищем).
- Обеспечьте защиту от повторной обработки на стороне потребителя.
- Мониторинг: задержка очереди, среднее время обработки, количество ошибок.
- Плановая полная переиндексация — раз в месяц.
Выводы
Прямая синхронизация 1С с сайтом — тупиковый путь. Асинхронный шлюз с очередью решает проблему блокировок, даёт масштабируемость и предсказуемость. Цена — плюс один сервис в инфраструктуре и более сложная отладка. Для каталога от 10 000 SKU — оправдано.