Перейти к содержимому
BXWiki

Push and Pull - настройка сервера очередей и проверка

Включаем сервер очередей рядом с сайтом, проверяем соединение с браузером и разбираемся, почему сообщения перестают приходить.

Решение

Смотрим, включён ли модуль и настроен ли сервер очередей:

use Bitrix\Main\Loader;


Loader::includeModule('pull');
echo COption::GetOptionString('pull', 'nginx', 'N'), "\n";       // включён ли сервер
echo COption::GetOptionString('pull', 'path_to_publish'), "\n";  // адрес публикации

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

Проверяем, что служба очередей запущена:

Окно терминала
systemctl status push-server-multi --no-pager | head -5
grep -rn 'push-server' /etc/nginx/bx/conf/ | head -3   # правила проксирования
ss -lntp | grep -E ':8893|:8894'          # порты сервера очередей
tail -20 /var/log/push-server/push-server-sub.log
# подписная и публикующая половины службы слушают разные порты

Служба ставится и включается веб-окружением, отдельным пунктом его меню. На своей сборке сервера её ставят руками, а проксирование к ней дописывают в конфигурацию веб-сервера самостоятельно.

Отправляем сообщение из кода:

\Bitrix\Pull\Event::add($userId, [
    'module_id' => 'main',
    'command'   => 'testMessage',
    'params'    => ['text' => 'проверка связи'],
]);
\Bitrix\Pull\Event::send();     // без этого вызова сообщение останется в очереди

Отправка проверяет всю цепочку целиком: код на сайте, сервер очередей и соединение с браузером. Сообщение, не дошедшее до открытой вкладки, указывает на обрыв именно в последнем звене этой цепочки.

Смотрим соединение со стороны браузера:

// консоль браузера на странице сайта
BX.PULL.getStatus();              // online означает, что соединение установлено
BX.PULL.getConfig();              // адрес сервера очередей и режим соединения
BX.PULL.subscribe({               // подписка на свои команды из кода страницы
    moduleId: 'main',
    callback: (data) => console.log(data),
});

Состояние offline при работающей службе почти всегда означает, что соединение обрывает посредник: прокси, балансировщик или защита от нагрузки. Веб-сервер самого сайта при этом отвечает на обычные запросы совершенно нормально, и в его журнале ничего подозрительного не видно.

Модуль умеет работать двумя разными способами: постоянным веб-сокетом и долгим запросом к серверу очередей. Первый экономнее и быстрее, второй проходит там, где сеть посетителя веб-сокеты блокирует. Оба режима стоит оставлять включёнными: модуль сам выбирает доступный и переключается на запасной при обрыве.

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

Обновление веб-окружения перегенерирует настройки проксирования к серверу очередей и перезапускает его вместе с остальными службами. Ручные правки в этих файлах теряются, и push перестаёт работать без видимой причины сразу после обновления. Настройку возвращают пунктом меню окружения, а свои директивы держат в подключаемых файлах, которые окружение не трогает.

Типичные проблемы

Модуль включён, сообщения не приходят.

Рядом с сайтом не настроен сервер очередей. Модуль включается и работает без него, но доставлять сообщения браузерам оказывается некому.

После обновления окружения push отвалился.

Обновление перегенерировало конфигурацию проксирования к серверу очередей. Ручные правки в этих файлах при обновлении не сохраняются.

Соединение устанавливается и сразу рвётся.

Долгое соединение обрывает посредник между браузером и сервером сайта. Обычный короткий запрос при этом проходит совершенно нормально.

На сервере всё работает, у части посетителей нет.

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

Сообщение отправлено, но не доставлено.

Не вызвана отправка накопленной очереди сообщений. Добавление события только кладёт его в буфер, а отправляет накопленное отдельный вызов.

Частые вопросы

Нужен ли push обычному сайту?

Магазину без личного кабинета - почти никогда. Он нужен там, где страница должна обновляться сама: чаты, уведомления, совместная работа.

Сколько соединений выдержит сервер очередей?

Он рассчитан на тысячи одновременных соединений и потребляет заметно меньше памяти, чем столько же процессов веб-сервера. Предел определяется настройками системы, а не самим сервером.

Можно ли вынести сервер очередей на отдельную машину?

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

Как отправить сообщение всем сразу?

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

Смежное

Первоисточник