Модуль Push & Pull обеспечивает мгновенную доставку сообщений в браузер без перезагрузки страницы: уведомления, чат, обновление счётчиков. Под нагрузкой ключевую роль играет отдельный NodeJS-сервер и правильное проксирование WebSocket — разберём, как это настроить.
Как устроен Push & Pull
Модуль pull реализует канал доставки сообщений от сервера к клиенту. Работает он в двух режимах:
- Pull (long polling) — браузер держит открытый запрос и ждёт сообщения; проще, но нагружает веб-ноды;
- Push (WebSocket) — постоянное двустороннее соединение через отдельный NodeJS-сервер; эффективно под нагрузкой.
Схема такая: PHP-код публикует сообщение в канал через \Bitrix\Pull\Event::add(), сообщение попадает в очередь (Redis/queue), а NodeJS-демон раздаёт его подключённым клиентам по WebSocket. Клиент подписан на каналы и получает данные мгновенно.
Компоненты серверной части
Полноценный Push & Pull складывается из нескольких сервисов:
| Компонент | Роль |
|---|---|
| NodeJS push-server | Держит WebSocket-соединения, раздаёт сообщения |
| Redis / очередь | Хранит и передаёт сообщения между PHP и NodeJS |
| nginx | Проксирует WebSocket и обычные запросы |
| Модуль pull (PHP) | Публикует события, управляет каналами |
В BitrixVM push-сервер устанавливается из меню управления как отдельная роль. При ручной настройке разворачивают NodeJS-демон Bitrix Push Server и подключают его к Redis, куда PHP кладёт сообщения.
Проксирование WebSocket в nginx
WebSocket требует специальной конфигурации nginx — обычного proxy_pass недостаточно, нужно пробросить заголовки апгрейда протокола:
location /bitrix/subws/ { proxy_pass http://push-server; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; }
Ключевые моменты:
proxy_http_version 1.1обязательна — WebSocket не работает по HTTP/1.0;- заголовки
UpgradeиConnectionпереключают протокол; - увеличенные таймауты (
proxy_read_timeout), иначе долгие соединения будут рваться; - отдельные
locationдля путей/bitrix/sub/(long polling) и/bitrix/subws/(WebSocket).
wss://. Смешанный контент (wss на https-странице обязателен) блокируется браузером — проверьте, что push-сервер доступен по SSL.Каналы и сценарии применения
Сообщения ходят по каналам: приватным (для конкретного пользователя) и общим (для группы). Публикация из PHP выглядит так:
\Bitrix\Pull\Event::add($userId, ['module_id' => 'mymodule', 'command' => 'update', 'params' => [...]]);
На стороне клиента JS подписывается на команду модуля и реагирует на неё. Типовые сценарии в highload-проектах:
- живые уведомления о заказах и статусах в личном кабинете;
- обновление остатков и цен на странице без перезагрузки;
- онлайн-чат и консультант;
- индикация «товар просматривают N человек» на распродажах.
Важно: Push & Pull доставляет сообщения, но не заменяет кэш. Публикуйте только события изменений, а не полные данные — клиент подтягивает детали отдельным запросом при необходимости.
Push-сервер под нагрузкой
Под тысячи одновременных соединений push-сервер сам становится нагруженным сервисом. На что смотреть:
- Лимиты файловых дескрипторов — каждое WebSocket-соединение это открытый сокет; поднимайте
ulimit -nиworker_connectionsв nginx; - Память NodeJS — тысячи соединений требуют мониторинга heap;
- Redis как общая шина — следите за его нагрузкой и латентностью;
- при очень большой аудитории — несколько push-нод за балансировщиком с общей очередью.
В кластере push-сервер выносят на отдельную машину, чтобы WebSocket-соединения не конкурировали за ресурсы с PHP-нодами. Балансировка WebSocket требует sticky-привязки или общей шины сообщений между push-нодами.
Диагностика проблем
Push & Pull часто «не работает» из-за инфраструктуры, а не кода. Порядок проверки:
| Симптом | Проверить |
|---|---|
| Соединение не устанавливается | Конфиг nginx для /bitrix/subws/, заголовки Upgrade |
| Работает по HTTP, но не по HTTPS | Доступность push-сервера по wss и SSL |
| Сообщения не доходят | Живость NodeJS-демона и связь с Redis |
| Рвётся через время | Таймауты proxy_read_timeout, промежуточные прокси |
Начинайте с проверки статуса модуля в Настройки → Push and Pull — там видно, доступен ли сервер и в каком режиме работает канал. Консоль браузера покажет, устанавливается ли WebSocket или идёт откат на long polling.
Итог
Push & Pull даёт realtime-доставку в Битрикс, но под нагрузкой это полноценная инфраструктура: NodeJS-демон, Redis как шина, корректное проксирование WebSocket в nginx с заголовками апгрейда и wss на HTTPS. При росте аудитории push-сервер выносят на отдельную ноду и масштабируют, а публиковать стоит события, а не полные данные.
Мы в B2Bsite настраиваем Push & Pull на highload-проектах: разворачиваем и тюним push-сервер, настраиваем WebSocket-проксирование и очередь, обеспечиваем работу под нагрузкой и через SSL. Если нужен надёжный realtime — поможем построить его так, чтобы он держал реальную аудиторию.
Частые вопросы
Чем режим Push отличается от Pull?
Pull — это long polling через основной веб-сервер: браузер держит открытый запрос и ждёт. Push — постоянное WebSocket-соединение через отдельный NodeJS-сервер. Под нагрузкой нужен именно Push, long polling съедает воркеры PHP-FPM.
Обязателен ли отдельный NodeJS-сервер?
Для WebSocket — да. Без него модуль работает в режиме long polling через веб-сервер, что допустимо только для небольшой аудитории. Под highload разворачивают NodeJS push-server, в BitrixVM он ставится как отдельная роль.
Почему WebSocket не работает, хотя long polling работает?
Чаще всего дело в nginx: для /bitrix/subws/ нужны proxy_http_version 1.1 и заголовки Upgrade и Connection. Без проброса апгрейда протокола соединение WebSocket не устанавливается и происходит откат на polling.
Что с Push & Pull на HTTPS?
WebSocket должен идти по защищённому wss://, иначе браузер заблокирует смешанный контент на HTTPS-странице. Убедитесь, что push-сервер доступен по SSL и nginx корректно проксирует защищённое соединение.
Как масштабировать push-сервер под большую аудиторию?
Выносят на отдельную машину, поднимают лимиты файловых дескрипторов и worker_connections, следят за памятью NodeJS и нагрузкой Redis. При очень большой аудитории ставят несколько push-нод за балансировщиком с общей шиной.
Что публиковать в канал — данные или события?
События изменений, а не полные данные. Push & Pull доставляет сигнал, а детали клиент подтягивает отдельным запросом при необходимости. Так канал остаётся лёгким и не дублирует работу кэша.
С чего начать диагностику, если сообщения не доходят?
Со статуса модуля в разделе Push and Pull — там видно, доступен ли сервер и в каком режиме канал. Затем проверьте живость NodeJS-демона, его связь с Redis и консоль браузера на предмет установки WebSocket.
Поможем с настройкой и поддержкой Для разработчиков
Поможем с настройкой, доработкой и поддержкой Для разработчиков.