Highload чат на node.js, clustering, redis. Как происходит broadcasting сообщений?

Question

[Evsign]

Нашёл пример чата на ноде под хайлоад(код, описание). Сделан с использованием воркеров через встроенную библиотеку cluster + redis hashring. Бродкастинг сообщений, судя по описанию сделан через redis pub/sub, но я не могу понять как он работает. Воркеры с мастером никак не общаются.

Изначально соединение начинается с handshake, генерируется случайный id, который служит ключом для каждого коннекта. Само connection, насколько я понял в стиле node, является readable stream. Когда приходит сообщение, то из него извлекается команда и в соответствии с ней вызывается соответствующая функция. Handshake вызывает initSession из chatManager.js, которому в кач-ве аргументов передаётся сообщение и connection stream. В initSession происходит создание и инициализация полей в connection stream и создаётся подписка на канал группы.

Вот собственно главные вопросы, у меня, по ф-циям: subscribe(connection) из файла initSession и listenChannel(channelId, onMessageCallback, context, callback) из messageManager.js.

Зачем везде хранить коннекты в массивах и объектах, ведь они между воркерами никак не синхронизируются, да и зачем это делать, если всё происходит через pub/sub? Соответственно почему рассылка сообщений (функция onMessage, которая передаётся в кач-ве колбэка) происходит через перебор этих сохранённых коннектов, а не просто через callback по сообщению из редиса c переданным потоком в кач-ве замыкания?

Мне кажется, что тут есть какой-то момент который я упускаю из виду(

Answer 1

[Тимур Шемсединов]

Передача хендлов сокетов в дочерние процессы тут находится во встроенной библиотеке cluster и скрыта от разработчика. Так же все процессы пишут и читают из редиса (см в коде вызовы incr/decr, zrem/zadd). Процессы подписываются на редисовские каналы (см в коде conn.on('message'...) и conn.on('subscribe'...) ). Код в этом репозитории уже три года не изменялся, масштабирование только на несколько процессов на одной машине, ничего уникального не написано, весь этот функционал сидит в редисе, будет тратиться много ресурсов, чтобы обеспечить межпроцессовое взаимодействие ноды с ним, даже не интересно смотреть эту реализацию. Это устаревший хлам, за три года нода уже изменилась, а как изменилась инфраструктура и возможности дополнительных пакетов...

Comments

[Evsign]

Спасибо за ответ.
Подскажите пожалуйста, каким образом лучше всего выстроить архитектуру c возможностью масштабирования для чата c комнатками?
После гугла у меня только вот такие идеи:
1. Держать в мастер процессе объект с комнатами и соответствующими коннектами. Воркеры принимают коннекты и передают в мастер, который складывает их в объект с нужной комнатой. Когда надо бродкастить сообщение на какую-то группу, то эмитятся эвенты с мессагой во все мастер процессы, на всех машинах, для рассылки сообщения. Если группа в объекте-хранилище есть, то происходит рассылка по соответствующим коннектам из мастера.
2. Тоже самое, что в первом варианте, но для рассылки сообщений использовать воркеры. Т.е. когда эмитится эвент на рассылку в мастере, то передавать незанятому воркеру эвент со всеми коннектами для рассылки. Но так наверное, получается как-то хаотично.
3. Тоже самое, что в верхних вариантах, но держать отдельный специальный воркер для рассылки сообщений.
4. Redis pub/sub. Каждый коннект подписывать на канал соответствующий комнате.

В голове каша(

[Evsign]

Или ещё для бродкаста каждый раз форкать новый процесс, который убивать по окончанию?

[Тимур Шемсединов]

Сколько будет максимум одновременных подключений? Сколько максимум комнат? Какая общая максимальная интенсивность сообщений? Не точные числа, а только порядок. Если 500тыс-2млн одневременных соединений, то это вообще все может быть на 1 машине, так проще масштабировать через cluster и делать обмен сообщениями между процессами через встроенный в child_process и стандартный для юникс систем IPC. Он в любом случае используется для передачи хендлов сокетов в cluster. Работает просто через process.send / process.on, см. https://nodejs.org/api/child_process.html Иначе нужно придумывать транспорт между серверами, это может любой способ передачи с установлением соединения и двухсторонним обменом, например, TCP сокеты, ZeroMQ, RabbitMQ, Redis, MongoDB. Все варианты бредовые, то что в голове каша, это правда. Уточните порядки цифр, если не нужно выходить за пределы одной машины, то не усложняйте, а если это проект класса ЗВИ (захавать все интернеты), то я посоветую другие решения.

[Evsign]

Тимур Шемсединов: ЗВИ проект + образовательные цели))
Да и я зелёный ещё, что бы даже представлять какие-то потенциальные цифры.
Просто хочется въехать в принципы масштабирования и балансирования нагрузки. Ну и положить в гитхаб, что-то более-менее интересное, что бы потом прицепить к резюме и сказать: "Вот. Умею разрабатывать под хайлоад.")
И ещё важный момент: нужно, что бы сообщения приходили клиентам одновременно. С этим моментом вообще не ясно что делать. Через таймаут исполнять команды на клиентах, что ли...
А можно подоставать Вас в скайпе?)

[Тимур Шемсединов]

Если ЗВИ, то берите Impress Application Server habrahabr.ru/post/247543 Если зеленый, то рекомендую пройти nodeschool.io и без этого не начинать делать ЗВИ. Так же хорошо поучаствовать в проектах с открытым кодом, в которых можно насмотреться чужого качественного кода и самому потренироваться писать, это и добавить в резюме. По архитектуре см мою лекцию https://youtu.be/Try7lmWikao с слайды к оной www.slideshare.net/tshemsedinov/nodejs-architecture а так же по ноде вот эту презу https://youtu.be/0oIiPJtfUpw
Скайп нельзя, это только для голосовых звонков по работе, я отвечаю на вопросы по ноде на тостере, а по серверу приложений Impress или на тостере https://toster.ru/tag/impress/questions или в гитхабе https://github.com/tshemsedinov/impress Если есть какой личный вопрос - почтой.

[Evsign]

Тимур Шемсединов: nodeschool выборочно уже по-проходил воркшопы после скринкастов Ильи Кантора по ноде и прочтения его же учебника. Вашу лекцию посмотрел сегодня уже 2 раза) В принципе, как реализовать весь функционал в один процесс без всякого потенциала для масштабирования я представляю, но хочется что бы и все ядра работали, и при необходимости второй сервер в работу включить. Главные запары по правильному межпроцессорному и межсерверному взаимодействию(
По описанию, IAS имеет из коробки всё то, что мне нужно) Но я пока не представляю как это будет выглядеть для моей задачи. Будет создаваться "глобальная" структура данных, которая невидимым для меня способом будет синхронизироваться между всеми процессами и серверами? Надеюсь найду ответы после прочтения статей про IAS) Если можно, далее буду писать Вам на почту, всё-таки ЗВИ проект, ну вы понимаете))

[Тимур Шемсединов]

В IAS есть встроенный механизм, который ретранслирует события между несколькими процессами на одной машине в режиме cluster и даже между процессами на разных серверах в режиме cloud. При чем, работа с событиями остается в привычном формате, тот же класс EventEmitter и методы emit и on, для отправки и подписки на события. Например, для бекенда: application.backend.emit('test', { data: 'data' }); и application.backend.on('test', function(eventName, data) { ... }); а для фронтенда application.frontend.emit('chat', { ip: client.req.connection.remoteAddress, name: client.fields.name, message: client.fields.message }); и все эти события автоматом пойдут в SSE пртокол на клиента.
Раньше для трансляции между процессами я использовал смешанный метод: IPC для одной машины и ZeroMQ для взаимодействия между серверами. Но недавно все переписал, абстрагировал транспортный слой и сделал три одинаковых по интерфейсу реализации транспорта: ZMQ, IPC и TCP. Теперь стало возможным сравнить их по скорости, оказалось, что TCP обгоняет всех в разы. Можете посмотреть как это все реализовано, там достаточно просто: impress.cloud.js и impress.cloud.tcp.js Там же есть и пример чата, который работает без комнат, но на многих серверах, тестируется в этом режиме вместе со всем сервером при каждом релизе.