Node.js Clustering multi-serveurs

Question

Je travaille sur un projet avec Node.js qui implique un serveur (par souci de simplicité, imaginons ce serveur comme un serveur de chat qui doit transférer des messages de certains clients à d'autres clients) . J'ai besoin pour des raisons de QoS que ce serveur est toujours joignable, donc j'ai pensé utiliser le clustering pour répartir la charge d'équilibre entre différents serveurs (différentes machines physiques) et être sûr que si un serveur tombe en panne, un autre sera prêt à servir les requêtes .

Ma question est: est ce type d'approche distribuée possible dans Node.js?

J'ai déjà lu sur le module "cluster", mais, d'après ce que j'ai compris, il semble s'agrandir uniquement sur les multiprocesseurs sur la même machine.

Answer 1

Oui, c'est possible.

Ce n'est pas une propriété de NodeJS mais plutôt l'architecture que vous concevez pour votre application qui déterminera si vous pouvez le faire ou non. Votre principal problème sera toujours de partager l'état à travers vos instances, disons que vous avez 4 serveurs de discussion ABCD, et vous avez un LoadBalancer L qui répartit les connexions sur les 4 serveurs, puis quand A tombe en panne, et vous reconnectez tous Les connexions de A aux instances restantes, comment vous assurez-vous que l'état de la salle de chat est le même sur BC et D? Une manière consiste à avoir le code d'application complètement sans état, et de pousser toutes les données vers une base de données répartie dans la mémoire, comme mongoDb ou Redis. Vous voulez que la base de données soit distribuée dans le cas où l'une des instances de base de données tombe en panne.

Le dernier problème est le LoadBalancer. Si cela tombe, tout votre système est en panne.

Donc pour faire une longue histoire courte; Oui, vous pouvez le faire, mais vous devez prendre des décisions difficiles sur les points d'échec potentiels. Si vous ne voulez pas un seul point de défaillance, vous aurez besoin d'une installation complexe et coûteuse.

Answer 2

Mes recommandations sont que vous utilisez des clusters indépendants pour partager l'état. En d'autres termes, disposez d'un cluster API dans lequel les serveurs ne communiquent pas entre eux, mais partagent une instance/cluster Redis commune et partagent un cluster MongoDB commun. Cela vous permet de partager des sessions, des variables, et vous pouvez tirer parti des capacités pub/sub de Redis pour éviter d'avoir besoin de commérages au sein de votre cluster API. Pour Chat en particulier, si vous utilisez Redis avec Socket.IO comme client, chaque fois que vous diffusez dans un lobby, il utilise Redis en arrière-plan pour diffuser ce message dans ce lobby, même si les membres du lobby existant sur plusieurs les serveurs. En outre, cela crée un autre niveau de tolérance aux pannes car n'importe quel serveur peut gérer les reconnexions de socket, et socket.io se reconnectera automatiquement au cluster API si sa connexion est interrompue, tout en maintenant l'état via Redis.