В процессе разработки в экосистеме 1С Предприятие часто возникает задача оперативного обмена информацией между различными потоками выполнения. Типичный сценарий: фоновое задание с определенным интервалом (например, раз в минуту или чаще) выполняет ресурсоемкую операцию, опрашивает внешнее оборудование или сторонний сервис, формирует короткую текстовую строку состояния, а активные пользовательские сеансы должны мгновенно считывать эту строку и отображать актуальный статус на экранах мониторов.
На первый взгляд задача кажется тривиальной, но при попытке реализации разработчики сталкиваются с жесткими архитектурными ограничениями платформы 1С. Глобальные переменные в общих модулях на сервере использовать невозможно из-за изоляции контекстов выполнения. В этой статье мы подробно разберем, как устроены механизмы обмена данными в оперативной памяти и на диске, проанализируем ограничения популярных подходов и рассмотрим современные высокопроизводительные решения этой задачи.
У начинающих разработчиков часто возникает идея использовать встроенный механизм платформы — Временное хранилище. Кажется удобным поместить туда строковую переменную по определенному адресу и считывать ее из других мест. Однако этот подход абсолютно неработоспособен для межсеансового обмена по двум ключевым причинам: физическому устройству кэша и жесткой изоляции сеансов.
Рассмотрим подробнее, как физически устроено Временное хранилище на сервере 1С:
srvinfo (в подпапки вида snccntx..., где хранятся сеансовые данные) в виде двоичных файлов с расширением .dat. Таким образом, работа с временным хранилищем генерирует реальные физические операции записи на жесткий диск или SSD.Таким образом, использовать временное хранилище для сквозного оперативного обмена данными "на лету" между независимыми сеансами невозможно.
Самым простым, надежным и стандартным решением в рамках платформы 1С является использование объекта метаданных Константа или непериодического Регистра сведений.
Давайте разберем по шагам, как настроить этот процесс:
Строка (длина зависит от ваших потребностей) или простой регистр сведений, где в качестве измерения будет, например, имя параметра, а в качестве ресурса — строковое значение.
// Запись значения из фонового задания
Процедура ЗаписатьТекущийСтатус(НовоеЗначение) Экспорт
Константы.ТекущийСтатусСистемы.Установить(НовоеЗначение);
КонецПроцедуры
// Чтение значения в пользовательском сеансе
&НаСервереБезКонтекста
Функция ПолучитьТекущийСтатус()
Возврат Константы.ТекущийСтатусСистемы.Получить();
КонецФункции
Часто у разработчиков возникает опасение: если производить запись в базу данных (в константу или регистр) слишком часто (например, раз в минуту или каждые несколько секунд), то постоянные перезаписи в одно и то же место диска быстро выведут серверный накопитель из строя.
Проанализируем эту ситуацию с точки зрения системного администрирования и физики работы современных серверов:
Во-первых, современные твердотельные накопители серверного класса (Enterprise SSD) обладают колоссальным ресурсом перезаписи (параметр DWPD — Drive Writes Per Day). Они рассчитаны на непрерывную запись сотен терабайт данных ежедневно в течение гарантийного срока (3–5 лет).
Во-вторых, в любой операционной системе (Windows или Linux), а также в самой СУБД (MS SQL Server, PostgreSQL) ежесекундно происходят тысячи системных операций записи на диск: запись логов транзакций, служебных файлов метаданных, системных журналов регистрации 1С. На этом фоне запись одной короткой строки объемом в несколько байт раз в минуту — это абсолютно неощутимая микроскопическая "капля в море", которая никак не повлияет на износ дисковой подсистемы.
Если сервер приложений 1С и сервер СУБД (например, MS SQL Server) установлены на одном физическом компьютере, мы можем значительно ускорить операции чтения и записи констант за счет оптимизации сетевого обмена.
По умолчанию взаимодействие между сервером 1С и базой данных происходит по сетевому протоколу TCP/IP, даже если они работают на одной машине. Это создает избыточные накладные расходы на сетевом стеке операционной системы.
Мы можем переключить взаимодействие на протокол Shared Memory (Общая память). В этом случае процессы сервера 1С и СУБД общаются напрямую через выделенную область оперативной памяти сервера, минуя сетевые протоколы. Это снижает общую нагрузку на центральный процессор и ускоряет частые мелкие запросы к базе данных (включая чтение констант) на 10–15%.
Для активации Shared Memory в строке подключения к серверу баз данных на стороне 1С вместо сетевого имени сервера или IP-адреса следует явно указать префикс:
lpc:ИмяСервера или использовать локальную точку (local). Также данный протокол должен быть включен в консоли настройки SQL Server (SQL Server Network Configuration -> Client Protocols).
Если перед вами стоит задача построения высоконагруженной системы (Highload), где критически важно полностью исключить любые дисковые транзакции при обмене данными и выполнять все операции строго в оперативной памяти с минимальными задержками (менее миллисекунды), классические механизмы 1С могут стать "узким горлышком".
В таких проектах архитектурно правильно использовать внешние In-Memory хранилища данных класса Key-Value, лидером среди которых является Redis.
Схема организации обмена выглядит следующим образом:
CurrentStatus).Начиная с версии платформы 1С:Предприятие 8.3.27, в платформу добавлена полноценная нативная поддержка протокола WebSocket. Это открывает перед разработчиками принципиально новые возможности, позволяя отказаться от постоянного "опроса" базы данных по таймеру (который создает паразитную циклическую нагрузку на сервер).
Используя WebSockets, мы можем реализовать событийно-ориентированную модель получения данных:
Для большинства рядовых задач автоматизации в 1С запись короткой строки раз в минуту в обычную Константу или Регистр сведений является оптимальным, надежным и самым простым в реализации решением. Опасения по поводу износа серверных SSD при такой частоте записи беспочвенны.
Если же ваша система работает под сверхвысокими нагрузками или требует обновления интерфейса пользователей в режиме реального времени (миллисекундный отклик), рассмотрите интеграцию с быстрыми In-Memory базами данных (Redis) или задействуйте современный встроенный механизм WebSockets, доступный в новых релизах платформы 1С.