Масштабирование приложения nodejs с помощью pm2

У меня есть приложение, которое получает данные из нескольких источников в режиме реального времени, используя логины и пароли. После того, как данные получены, они сохраняются в хранилище памяти и заменяются после появления новых данных. Также я использую сеансы с mongo-db для аутентификации запросов пользователей. Проблема в том, что я не могу масштабировать это приложение с помощью pm2, так как я могу использовать только одно подключение к моему источнику данных для одной пары логин/пароль.

Есть ли способ использовать разные логин/пароль для каждого кластера или получить идентификатор кластера внутри приложения?

Являются ли значения/сессии памяти общими для кластеров или они разделены? Спасибо.


person BadVolt    schedule 08.09.2015    source источник
comment
Что вы подразумеваете под «только одно соединение для пары логин/пароль»? Какая связь?   -  person Yuri Zarubin    schedule 09.09.2015
comment
Простите за это. Подключение к источникам, которые я использую для получения данных в реальном времени.   -  person BadVolt    schedule 09.09.2015
comment
Я встретил точно такую ​​же проблему. Поскольку MongoDB не разрешает несколько подключений с одной и той же парой логин/пароль, можете ли вы найти какой-либо документ? Я искал на mongodb.com, но ничего не нашел.   -  person shaochuancs    schedule 14.11.2018


Ответы (2)


Итак, если я понял этот вопрос, у вас есть приложение node.js, которое подключается к третьей стороне с использованием HTTP или другого протокола, и, поскольку у вас есть только одни учетные данные, вы не можете подключиться к указанной третьей стороне, используя более одного экземпляра. Чтобы ответить на ваш вопрос, да, возможно, настроить ваши кластеры на использование уникальной комбинации use/pw, сложная часть будет заключаться в том, как назначить эти учетные данные каждому кластеру (при условии, что вы не хотите жестко кодировать его). Вам придется выполнить это назначение при запуске серверов и, возможно, использовать хранилище данных для хранения этих учетных данных и ввести какой-либо механизм блокировки для каждого учетного данных (чтобы каждое учетное данные было уникальным для конкретного экземпляра).

Однако, если бы я был на вашем месте, я бы создал новый сервер, единственной задачей которого было бы получать эти «данные в реальном времени» и хранить их где-нибудь, доступном для кластера, например, в Redis или в каком-либо постоянном хранилище. Тогда сервер будет автономным сервером, просто получающим эти данные. Вы также можете подключить к нему RESTful API, чтобы, если другим вашим серверам нужно было взаимодействовать с ним, они могли делать это через HTTP или очередь сообщений (опять же, Redis и там будет работать нормально.

person Yuri Zarubin    schedule 09.09.2015
comment
Боюсь пушить в БД и опрашивать из нее займет много времени. Нам нужно считать каждую мс. Но спасибо за совет. Думаю, что все-таки буду использовать обычные кластеры, а не PM2. Основной поток будет обслуживать запросы, а рабочие будут получать данные и передавать их мастеру. И я могу легко получить учетные данные из конфигураций для каждого работника, используя идентификатор в качестве индекса массива. - person BadVolt; 09.09.2015
comment
Я никогда не говорил о опросе из БД, я только упомянул БД, когда упомянул часть о перераспределении учетных данных между кластерами. Эта часть будет выполняться только при запуске серверов, по сути, вам просто нужно каким-то образом распределить пул учетных данных, где каждый сервер должен иметь уникальные учетные данные. Что касается выделенного сервера, опять же, это не обязательно должна быть постоянная база данных, это может быть просто экземпляр Redis в памяти, который публикует данные в кластерах через pub/sub. Одно событие redis 'emit' происходит очень быстро, я очень сомневаюсь, что это приведет к проблемам с производительностью. - person Yuri Zarubin; 09.09.2015

«Реальное время» расплывчато; вы используете веб-сокеты? Если HTTP-запросы выполняются достаточно часто, их также можно считать «в реальном времени».

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

Вам нужно будет использовать только процесс fork mode 1 и решение для закрепления сеансов, например:

https://www.npmjs.com/package/sticky-session

У меня есть пример кода, но мне нужно его найти (более года с момента его развертывания)

По сути, вы просто используете pm2 для функции «всегда включен»; Модуль sticky-session отвечает за кластеризацию узлов.
Я могу опубликовать пример позже.

person Wylie Kulik    schedule 09.09.2015
comment
Я хотел бы использовать WS, но я ограничен использованием опросов и потоков. Стримы не так уж и плохи :) - person BadVolt; 09.09.2015
comment
sticky-session в целом и этот модуль в частности все еще могут быть выданы/использованы; если сеансы поддерживаются для каждого процесса/ядра. - person Wylie Kulik; 09.09.2015