2013-03-19 15 views
19

Ich arbeite an einem Projekt mit Node.js, das einen Server beinhaltet (der Einfachheit halber stellen wir uns diesen Server als einen Chat-Server vor, der Nachrichten von bestimmten Clients an andere Clients weiterleiten muss) . Ich brauche aus QoS-Gründen, dass dieser Server immer erreichbar ist, also dachte ich mir, Clustering zu verwenden, um die Last zwischen verschiedenen Servern (verschiedene physische Maschinen) zu teilen und sicher zu sein, dass ein Server bereit ist, die Anfragen zu bedienen .Node.js Multi Server Clustering

Meine Frage ist: ist diese Art von verteilten Ansatz in Node.js möglich?

Ich habe bereits über das "Cluster" -Modul gelesen, aber von dem, was ich verstanden habe, scheint es nur auf Multiprozessoren auf der gleichen Maschine zu skalieren.

+0

Bitte genauer markieren. Dies war [Tag: Cluster-Analyse] (aka: Clustering; eine Data-Mining-Technik). –

+0

Sehen Sie sich Sharding in MongoDB an - https://docs.mongodb.com/manual/sharding/ Sie können nach Ort oder nach anderen Eigenschaften, Zeitzonen, sozialen Gruppen oder Chatrooms shard. –

Antwort

29

Ja, es ist möglich.

Es ist keine Eigenschaft von NodeJS, sondern die Architektur, die Sie für Ihre Anwendung entwerfen, die bestimmt, ob Sie es tun können oder nicht.

Ihr Hauptproblem wird immer sein, Staat über Ihre Instanzen zu teilen, also sagen Sie haben 4 Chat-Server ABCD, und Sie haben einen LoadBalancer L, der Verbindungen über die 4 Server verbreitet, dann wenn A ausfällt und Sie alle wieder verbinden A's Verbindungen zu den verbleibenden Instanzen, wie stellen Sie sicher, dass der Zustand des Chatrooms auf BC und D gleich ist?

Eine Möglichkeit besteht darin, den Anwendungscode vollständig zustandslos zu machen und alle Daten in eine Datenbank mit verteiltem Speicher, wie mongoDb oder Redis, zu übertragen. Sie möchten, dass die Datenbank verteilt wird, falls eine der Datenbankinstanzen ausfällt.

Jetzt ist das letzte Problem der LoadBalancer. Wenn das ausfällt, ist Ihr gesamtes System ausgefallen.

Also um eine lange Geschichte kurz zu machen; Ja, Sie können es tun, aber Sie müssen einige harte Entscheidungen darüber treffen, wo Ihre potenziellen Fehlerquellen liegen. Wenn Sie keinen Single Point of Failure haben wollen, benötigen Sie ein komplexes und teures Setup.

+0

Was ist eine andere Möglichkeit, den Status unter mehreren Servern zu teilen, was passiert, wenn Redis zum Engpass wird? –

+0

Sehen Sie sich Sharding in MongoDB an - https://docs.mongodb.com/manual/sharding/ Sie können nach Ort oder nach anderen Eigenschaften, Zeitzonen, sozialen Gruppen oder Chatrooms shard. –

5

Meine Empfehlungen sind, dass Sie unabhängige Cluster nutzen, um den Status zu teilen. Mit anderen Worten: Haben Sie einen API-Cluster, in dem Server nicht miteinander kommunizieren, sondern eine gemeinsame Redis-Instanz/einen gemeinsamen Cluster teilen und einen gemeinsamen MongoDB-Cluster teilen. Auf diese Weise können Sie Sitzungen und Variablen teilen, und Sie können die Pub/Sub-Funktionen von Redis nutzen, um zu vermeiden, dass Sie innerhalb Ihres API-Clusters klatschen müssen. Wenn Sie Redis mit Socket.IO als Client verwenden, wird es immer dann, wenn Sie in eine Lobby senden, Redis hinter den Kulissen verwenden, um diese Nachricht an diese Lobby zu senden, obwohl die Mitglieder der Lobby bereits mehrfach vorhanden sind Server. Darüber hinaus wird dadurch eine weitere Fehlertoleranzstufe geschaffen, da jeder Server Socket-Reconnections verwalten kann, und socket.io stellt automatisch eine Verbindung mit dem API-Cluster her, wenn die Verbindung unterbrochen ist, während der Status über Redis beibehalten wird.