Synchronisation mit Offline-System

Ich entwerfe ein System, von dem aus ich Geschäftsdaten vom mobilen Gerät (mit einer eingebetteten Anwendung) synchronisiere, das Daten generiert und an den Server zurücksendet. Jede synchronisierte Zeile generiert ein bestimmtes Geschäftsprotokoll in der Datenbank.

Wenn das, was ich synchronisiere, Daten mit einem Datum (innerhalb der Synchronisierungsdaten) generiert, das unter dem Datum der letzten Änderung meiner Geschäftsdaten liegt, muss ich es ignorieren und einfach die Anmeldedatenbank hinzufügen. Sobald die hochgeladenen Daten verarbeitet sind, werden Daten aus der Datenbank abgerufen und auf das Gerät heruntergeladen.

Aufgrund dieses Downloads direkt nach dem Schreiben muss die Synchronisation synchron sein. Es ist immer noch möglich, ein Lese- / Schreibmuster zu haben, wenn so etwas genug wert ist, um meine bestehende Lösung zu ersetzen. Wichtiger ist es, aktuelle Daten herunterladen zu können. Da diese Daten als Ganzes abgerufen werden, ist derzeit kein Diff implementiert (es kann später kommen, aber das ist kein Problem).

Möglicherweise werden mehrere Synchronisierungen für dasselbe Geschäftsobjekt ausgeführt. Dies ist unwahrscheinlich, kann jedoch auftreten, und ich bevorzuge es, damit umgehen zu können. Die Synchronisierung wird voraussichtlich einige Sekunden, jedoch nicht einige Minuten dauern, es sei denn, Sie verwenden die eingebettete mobile Anwendung einige Tage lang ohne erneute Synchronisierung.

Es wird nicht erwartet, dass das synchronisierte Datenvolumen groß ist, ebenso wenig wie der Synchronisierungsprozess.

Daher verwende ich einen gegenseitigen Ausschluss für meine Synchronisationsmethode, genauer gesagt, ich verwende Java und setze eine synchronisierte Schreibmethode ein, nicht den gesamten Synchronisationsprozess, um die schreibgeschützte Synchronisation nicht zu blockieren.

Ich würde gerne wissen :

Ob dieser Weg Sinn macht? Solange das Volumen und die Zeit des Synchronisationsprozesses noch akzeptabel sind.
Welche Konzepte sollte ich allgemein betrachten? Bonus: Wenn diese Konzepte in einem Spring-Modul implementiert sind.

— Walfrat
quelle

Was verursacht das Offline? Ich meine, wenn das Gerät offline ist, bedeutet dies, dass es keinen Zugriff nur auf den Server hat oder auch nicht auf das Internet?

— Laiv

Es hat keinen Zugang zum Internet. Oder nicht oft.

— Walfrat

Wenn mehrere Clients / Server synchronisiert werden, müssen Sie sich zunächst für die Datenbeherrschung entscheiden, falls sich etwas unterscheidet. Wenn Sie nur intermittierende Verbindungen und mehrere Clients berücksichtigen, gibt es definitiv keine Möglichkeit, dies schrittweise zu tun.

— Tofro

@tofro Datenmeisterschaft ist in meinem Fall leicht zu bestimmen, daher ist es kein Problem. Warum wäre es jedoch nicht möglich, dies mit intermittierenden Verbindungen schrittweise zu tun? Sollte ich nicht in der Lage sein, nur ein letztes Synchronisierungsdatum zu verwenden? Das einzige Problem in meinem Fall bei Verwendung eines solchen Datums wäre, zu wissen, dass Daten, die sich derzeit auf meinem Gerät befinden, verschoben wurden und auf dem Gerät gelöscht werden sollten.

— Walfrat

Aus Ihrer Beschreibung geht hervor, dass dasselbe Datenelement auf dem Server oder auf einem oder mehreren Clients geändert werden kann. Wie würden Sie ein Datenelement in drei Richtungen synchronisieren, das auf Handy Nr. 1 ging, dann auf dem Server geändert wurde, dann auf Handy Nr. 2 ging und dort geändert wurde und dann auf Handy Nr. 1 eine Verbindung herstellte (mit einem nicht verbundenen Handy Nr. 2)?

— Tofro

Antworten:

Ein Ansatz , dass ich für eine Weile jetzt untersucht (mit einigem Erfolg) Kundendaten mit Server - Daten synchronisieren bis haben, ohne zu Terminen zu verlassen (die möglicherweise unzuverlässig sein) oder synchrone Anforderungen, ist eine Kombination aus JSON Patches (vielleicht POJO s in Ihrem Fall) und Event-Sourcing .

Die Grundidee besteht darin, dass Client und Server nicht den aktuellen Status auf dem Client und dem Server speichern, sondern eine Liste der Änderungen speichern und sich gegenseitig über Ereignisse oder Patch-Anforderungen benachrichtigen.

Anstatt dass der Client alle Daten plus ein Datum an den Server sendet, sendet der Client ein Ereignis zusammen mit einer Revisionsnummer, die dem letzten Zeitpunkt entspricht, an dem der Client glaubt, dass die Daten aktualisiert wurden. Etwas wie das:

Server.send("MODIFY FOO", 3);

Sobald der Server dieses Ereignis (asynchron) erhält, stimmt er es mit anderen Ereignissen ab, die er möglicherweise bereits empfangen hat. Beispielsweise ist es möglich, dass ein anderer Client, der mit denselben Daten arbeitet, bereits einige Änderungen vorgenommen hat und die Versionsnummer auf dem Server jetzt bei 5 liegt. Daher muss diese Überarbeitung angewendet werden, bevor die letzten beiden angewendet wurden, und alle Kunden müssen über diese Änderung informiert werden.

Sobald der Server fertig ist, benachrichtigt er alle interessierten Clients über die vorgenommenen Änderungen und die neue aktuelle Versionsnummer. Der Client wendet diese Änderungen dann an und aktualisiert seine interne Revisionsnummer.

Ihr Kilometerstand kann variieren, aber ich hoffe, das hilft.

Bearbeiten: Ein anderer Name für diesen Ansatz oder eine Variation davon wird als Nachrichtenwarteschlange bezeichnet , wie in dieser verwandten Frage erwähnt .

— Jeffrey Sweeney
quelle

Das System kann einige Tage offline sein (kein Zugriff auf den Server) und muss das Datum registrieren, an dem das Ereignis aufgetreten ist, nicht das Datum, an dem das Ereignis mit dem Server synchronisiert wurde. Deshalb muss ich Daten verwenden. Ich habe auch eine Revisionsnummer für optimisticLocking, aber aus dem gleichen Grund könnten 2 Geräte die Version X eines POJO herunterladen und bei späterer Synchronisierung jedes Sendeereignis, das eine Version X + 1 und X + 2 generieren muss. Und die Geräte können nicht miteinander kommunizieren.

— Walfrat

Die Revisionsnummer in dieser Antwort wird immer auf dem Server generiert. Der Client sendet alte Revisionsnummern. Er muss keine Informationen über andere Clients haben, da das Revisionsinkrement nicht in seiner Verantwortung liegt. In dieser Antwort wird die Konfliktlösung nicht erwähnt, die der wichtigste Teil der vorgeschlagenen Lösung ist.

— Basilevs

Das erste Problem ist die Verwendung von Datumsangaben zum Synchronisieren von Daten. Ich bin mir wirklich sicher, dass ich nicht alle Details Ihrer Lösung erhalten habe, aber ich würde sagen:

Werden die Daten auf den Handys generiert? Sind Sie in diesem Fall sicher, dass die auf den Handys ausgeführte App immer die richtigen Daten verwendet? Was ist mit einem böswilligen Benutzer, der das Systemdatum auf seinem Mobilgerät etwas ändern kann? Was ist mit Benutzern in verschiedenen Zeitzonen? Wie @jeffrey Ihnen sagte, ist es möglicherweise nicht der beste Ansatz, sich auf Daten zu verlassen, die auf den Geräten generiert wurden.
Wenn ich es richtig verstanden habe, verwenden Sie Optimistic Concurrency Control . Ich sehe nichts, was in Ihrem Ansatz an sich falsch ist.
In dieser Frage geht es um die Implementierung von Optimistic Locking im Frühjahr . Vielleicht können Sie sich darin inspirieren lassen.

— danidemi
quelle

Ich muss das Datum aufzeichnen, an dem die Aktion ausgeführt wurde, daher bleibe ich beim Datum des Mobiltelefons. Das mobile Datum wird häufig erneut mit dem System synchronisiert. Nur registrierte Geräte können mit dem Server synchronisiert werden. Was die Sicherheit betrifft, ist es ein weiteres Problem, das vorerst noch besteht (X509-Geräteauthentifizierung, ...)

— Walfrat,

Das Datum könnte als ein weiteres Datenfeld aufgezeichnet werden, ohne dass es als Synchronisationstoken behandelt werden muss.

— Basilevs