Node.js Многосерверная кластеризация

Я работаю над проектом с Node.js, который включает в себя сервер (для простоты предположим, что этот сервер является чат-сервером, которому приходится пересылать сообщения от определенных клиентов другим клиентам). Мне нужно, чтобы из-за QoS этот сервер всегда был доступен, поэтому я решил использовать кластеризацию для разделения балансовой нагрузки между разными серверами (разными физическими машинами), и чтобы убедиться, что если сервер опустится, другой будет готов обслуживать запросы,

Мой вопрос: возможен ли такой распределенный подход в Node.js?

Я уже читал о модуле "cluster", но, насколько я понял, он, кажется, масштабируется только на многопроцессорных устройствах на одной машине.

Ответ 1

Да, это возможно.

Это не свойство NodeJS, а архитектура, которую вы разрабатываете для своего приложения, которая будет определять, можете ли вы это сделать или нет.

Ваша основная проблема всегда будет заключаться в совместном использовании состояния по вашим экземплярам, поэтому скажите, что у вас есть 4 сервера чата ABCD, и у вас есть LoadBalancer L, который распространяет соединения на 4 серверах, а затем, когда A спускается, и вы снова подключаете все A соединения с остальными экземплярами, как вы гарантируете, что состояние чата одинаково для BC и D?

Один из способов заключается в том, чтобы код приложения был полностью безгосударственным, и все данные передавались в распределенную в базе данных памяти, например, mongoDb или Redis. Вы хотите, чтобы база данных была распределена, если один из экземпляров базы данных опустился.

Теперь у вас последняя проблема - LoadBalancer. Если это снизится, вся ваша система не работает.

Итак, чтобы сделать длинный рассказ коротким; Да, вы можете это сделать, но вам нужно принять какие-то жесткие решения о том, где будут ваши потенциальные проблемы с отказом. Если вам не нужна ни одна точка отказа, вам понадобится сложная и дорогая настройка.

Ответ 2

Мои рекомендации заключаются в том, что вы используете независимые кластеры для совместного использования состояния. Другими словами, у вас есть кластер API, где серверы не разговаривают друг с другом, а вместо этого используют общий экземпляр/кластер Redis и совместно используют общий кластер MongoDB. Это позволяет вам обмениваться сеансами, переменными, и вы можете использовать возможности Red/Sub для Redis, чтобы избежать необходимости сплетен в вашем кластере API.

Для чата в частности, если вы используете Redis с Socket.IO в качестве своего клиента, тогда всякий раз, когда вы транслируете в лобби, он будет использовать redis за кулисами для трансляции этого сообщения в это лобби, несмотря на то, что участники лобби, существующие на нескольких серверах, Кроме того, это создает еще один уровень отказоустойчивости, так как любой сервер может управлять пересоединениями сокетов, а socket.io будет автоматически повторно подключаться к кластеру API, если это соединение сломано, при сохранении состояния через Redis.