Hochverfügbarkeit mit ThingWorx > Letztendliche Konsistenz in ThingWorx HA
Letztendliche Konsistenz in ThingWorx HA
Wird ThingWorx im Cluster-Modus ausgeführt, so werden Modelländerungen im Laufe der Zeit über den Cluster hinweg konsistent gemacht. Es dauert eine Weile, Änderungen auf Server A für die Server B, C usw. zu synchronisieren. Ein Änderungs-Watcher wird mit einer konfigurierbaren Frequenz ausgeführt (mit einem Standardwert von 100 ms) und prüft auf Entitätsänderungen. Es werden Entitäten, die sich auf diesem Server ändern, entladen und neu geladen, wobei davon ausgegangen wird, dass die Datenbank die Source of Truth ist. Diese letztendliche Konsistenz gilt nur für Modell- und Konfigurationsänderungen, während der Status sofort konsistent ist.
HTTP – HTTP verwendet Sticky Sessions, sodass ein individueller Benutzer an einen einzelnen Rechner gebunden ist. Dadurch wird sichergestellt, dass ein Benutzer alle Änderungen sofort sieht. Änderungen von anderen Benutzern auf anderen Servern sind letztendlich konsistent.
WebSocket – Wenn eine Modelländerung über einen WebSocket vorgenommen wird, wird die aktuelle Modellversion in der WebSocket-Sitzung gespeichert. WebSocket-Anforderungen sind immer Round-Robin, um Lastverteilung zu unterstützen. Die nächste Anforderung an diese WebSocket-Sitzung wird angehalten, bis der Server, mit dem sie verbunden ist, mindestens die in der Sitzung gespeicherte Version aufweist. Wenn der Server nicht innerhalb einer Sekunde synchronisiert werden kann, erfolgt ein Timeout.
Eine begrenzte Auswirkung auf Benutzer wird in den folgenden Szenarien beschrieben:
Situation 1: HTTP
Gerät > HAProxy > Plattform1..N
In diesem Szenario stellen Sie eine Verbindung zu Plattform 1 her und nehmen Modelländerungen vor.Wenn Sie dann einen anderen Benutzer mit Plattform 2 verbinden und auf Änderungen prüfen, werden diese irgendwann angezeigt.Der Cluster ist dank eines Synchronisierungsprozesses in Bezug auf Modelländerungen nun konsistent.Wenn dies Ihr Anwendungsfall ist, sollten Sie eine Wiederholung integrieren, damit darauf gewartet wird, dass die Änderungen verfügbar sind.
Szenario 2: WebSocket
Gerät > HAProxy > CXServer1..N => Platform1..N
In diesem Szenario ist das Gerät von Punkt zu Punkt mit einem Verbindungsserver verbunden.Für Plattformanforderungen erfolgt Round-Robin.Wenn das Gerät eine Modelländerung vornimmt und dann eine weitere Anforderung an einen anderen Server stellt, sind die ersten Änderungen vor der Verarbeitung vorhanden.Die Anforderung wird verzögert, bis die Modellversion mindestens auf die Version synchronisiert wird, auf der die Änderung vorgenommen wurde.Wenn sie in einem bestimmten Zeitraum nicht synchronisiert werden kann, gibt es ein Timeout für die Anforderung. Daher kann dieses Gerät mit jedem Server kommunizieren und erhält eine angemessene Antwort.
Wenn Sie ein zweites Gerät verbinden, um die vom ersten Gerät vorgenommenen Änderungen zu überprüfen, gilt die letzendliche Konsistenz auch für das zweite Gerät. Das System wartet nur auf Änderungen für eine einzelne Verbindung.
Szenario 3: HTTP-Anforderung zum Ändern des Modells löst eine Benachrichtigung an ein verbundenes Gerät aus
Gerät > HAProxy > CXServer1..N => Platform1..N
Ein Benutzer nimmt eine Modelländerung vor, und das Gerät wird über die Änderung benachrichtigt, sodass es die Definitionen neu abrufen kann.Das Gerät hatte die Möglichkeit, die Daten von einem Server abzurufen, der die Änderung noch nicht anzeigt. Jetzt wird die Modellversion in die WebSocket-Sitzung eingefügt. Bei Anforderungen auf einem Server mit einer niedrigeren Modellversion wartet es, dass mindestens auf diese Modellversion synchronisiert wird.Wenn nicht rechtzeitig synchronisiert werden kann, erfolgt ein Timeout der Anforderung.
Daher wurde eine neue postCommitEventQueue hinzugefügt. Alle hinzugefügten Ereignisse, wie z.B. Eigenschaftsänderungen, werden ausgelöst, nachdem ein Commit für die vollständige Transaktion ausgeführt wurde und die neue Modellversion bekannt ist. Wenn das Gerät benachrichtigt wird, wird die Modellversion in die WebSocket-Sitzung eingefügt, um sicherzustellen, dass zukünftige Anforderungen von diesem Gerät warten, bis der Server mit den ursprünglichen Änderungen konsistent ist.
War dies hilfreich?