2013-03-19 13 views
19

Sto lavorando a un progetto con Node.js che coinvolge un server (per semplicità immaginiamo questo server come un server di chat che deve inoltrare messaggi da determinati client ad altri client) . Ho bisogno di QoS per capire che questo server è sempre raggiungibile, quindi ho pensato di utilizzare il clustering per dividere il carico di bilanciamento tra diversi server (diverse macchine fisiche) e per essere sicuro che se un server si arresta, un altro sarà pronto a servire le richieste .Node.js Multi Server Clustering

La mia domanda è: questo tipo di approccio distribuito è possibile in Node.js?

Ho già letto sul modulo "cluster", ma, da quello che ho capito, sembra scalare solo su multiprocessori sulla stessa macchina.

+0

Si prega di taggare più attentamente. Questo non era [tag: cluster-analysis] (aka: clustering, una tecnica di data mining). –

+0

Guardare a sharding in MongoDB - https://docs.mongodb.com/manual/sharding/ puoi dividere per posizione o con altre proprietà, fusi orari, gruppi sociali o chat room. –

risposta

29

Sì, è possibile.

Non è una proprietà di NodeJS ma piuttosto l'architettura che si progetta per l'applicazione che determinerà se è possibile farlo o meno.

Il tuo problema principale sarà sempre per condividere lo stato tra le istanze, in modo da dire che avete 4 server di chat ABCD, e si dispone di un LoadBalancer L che si estende le connessioni tra i 4 server, poi quando A va giù, e si ricollegare tutti Le connessioni di A alle istanze rimanenti, come si fa a garantire che lo stato della chat sia lo stesso su BC e D?

Un modo è avere il codice dell'applicazione completamente stateless e trasferire tutti i dati in un database distribuito in memoria, come mongoDb o Redis. Si desidera che il database sia distribuito nel caso in cui una delle istanze del database scenda.

L'ultimo problema è il LoadBalancer. Se questo va giù, l'intero sistema non funziona.

Quindi per farla breve; Sì, puoi farlo, ma devi prendere alcune decisioni difficili su dove saranno i tuoi potenziali punti di errore. Se non si desidera un singolo punto di errore, è necessario un setup complesso e costoso.

+0

qual è l'altro modo per condividere lo stato tra più server, cosa succede se Redis diventa il collo di bottiglia? –

+0

Guardare a sharding in MongoDB - https://docs.mongodb.com/manual/sharding/ è possibile frammentare per posizione o per altre proprietà, fusi orari, gruppi sociali o chat room. –

5

I miei consigli sono di sfruttare i cluster indipendenti per condividere lo stato. In altre parole, avere un cluster API in cui i server non comunicano tra loro, ma condividono invece un'istanza/cluster Redis comune e condividono un cluster MongoDB comune. Ciò consente di condividere sessioni, variabili e sfruttare le funzionalità pub/sub di Redis per evitare di avere bisogno di pettegolezzi all'interno del proprio cluster API.

Per Chat particolare, se si utilizza Redis con Socket.IO come client, quindi ogni volta che si broadcast a una lobby, si userà Redis dietro le quinte per trasmettere quel messaggio a quella lobby, nonostante i membri della lobby esistenti su più server. Inoltre, questo crea un altro livello di tolleranza agli errori, in quanto ogni server può gestire le riconnessioni dei socket e socket.io si ricollegherà automaticamente al cluster API se la connessione è interrotta, il tutto mantenendo lo stato tramite Redis.