Beim Ausführen mehrerer Meteor-Serverprozesse sind zwei Hauptprobleme zu berücksichtigen.
-
Clientsitzungsaffinität. Clients verwenden die SockJS-Bibliothek, um sich wieder mit dem Meteor-Server zu verbinden, normalerweise unter Verwendung einer langen Abfragestrategie, die von Zeit zu Zeit eine erneute Verbindung zum Server herstellt. Der Serverprozess hält den Zustand, der jedem Client zugeordnet ist. Daher ist es wichtig, dass die Verbindung eines bestimmten Clients nicht zwischen den Servern hin und her springt, da der Server sonst denkt, dass er mit einem neuen Client kommuniziert, und den gesamten Abonnementstatus erneut sendet.
-
Koordinieren von Datenbankinvalidierungen. Jedes Mal, wenn ein Client einen Datenbankschreibvorgang ausgibt, führt der Serverprozess eine Neuberechnung durch und überträgt Aktualisierungen an alle anderen betroffenen Clients. Clients, die mit einem anderen Server verbunden sind, sehen die Änderung jedoch erst, wenn dieser Serverprozess die 10-Sekunden-Polling-Schleife von Mongo ausführt. Für einige Anwendungen ist es in Ordnung, wenn die meisten Clients 10 Sekunden hinterherhinken. Wenn Ihre Anwendung mehr Echtzeit erfordert, müssen Sie Ihre eigene Interprozesskommunikation zwischen Meteor-Serverprozessen implementieren.
