Wie generieren Deltas für gelöschte Daten in Client-Server-Architektur?

Question

Meine Kollegen und ich haben einige Client-Server-Architektur-Programme erstellt, die Deltas verwenden, um einen Client mit einem Server zu synchronisieren. Ein Problem beim Löschen von Datensätzen scheint sich in mehreren Projekten zu zeigen. Wie kann ein Server Datensätze lokal löschen und dennoch genügend Informationen haben, um Delta-Delta-Informationen für zukünftige Clients zu generieren?

Beispiel 1:

Ein Echtzeit-Spiel verwendet UDP-Client-Server-Einheiten zwischen den Spielen zu synchronisieren. Nur Deltas, die den modifizierten Spielzustand und zuvor fallen gelassene Paketdaten enthalten, werden übertragen. Wenn der Server eine Entität löscht, kann er ein Löschdelta senden, das jedem Client mitteilt, dieses Objekt zu löschen. Dies funktioniert, bis ein Paket gelöscht wird. Dies ist in Ordnung für normale Zustandsdaten, da der Server identifizieren kann, welche Daten gelöscht wurden und Deltas erneut übertragen, dies würde jedoch bedeuten, dass der Server die Serverentität nicht lokal löschen könnte (ohne eine vollständige Bestätigung von jedem Client zu machen), wie nein Daten würden existieren, um das Löschdelta von zu erzeugen.

Beispiel 2:

Ein Kunde will mit einer Datenbank auf einem Server gespeichert synchronisieren. Der Server speichert ein Änderungsdatum für jeden Datensatz auf dem Server. Wenn der Client eine Synchronisierung anfordert, sendet er das letzte aktualisierte Datum. Der Server sammelt alle Datensätze, die seit diesem Datum geändert wurden, und sendet sie an den Client. Dies funktioniert nur dann mit Löschungen, wenn der Server alle Datensätze löscht und ein Flag zum Löschen verwendet. Der Server kann einen lokal gespeicherten Datensatz nicht sicherheitsrelevant löschen. In beiden Beispielen ist die einzige Lösung, die ich mir vorstellen kann, eine Aufzeichnung zu behalten, die alles enthält, was jemals gelöscht wurde, oder eine vollständige Synchronisierung nach einem bestimmten Datum/einer bestimmten Zeit zu erzwingen. Diese scheinen keine nachhaltigen oder anmutigen Modelle zu sein. Was sind einige nachhaltige Methoden zur Lösung dieser Art von Problem?

Answer 1

Warum würde das nicht nachhaltig erscheinen? Viele Sync-Frameworks verwenden dies und es heißt Tombstoning, afaik. Der Datensatz wird gelöscht oder als gelöscht markiert, und in einer anderen Tabelle (wenn es sich um Datenbanken handelt) wird ein Verweis auf den gelöschten Eintrag gehalten. Auf diese Weise können Systeme Datensätze synchronisieren, die gelöscht werden. In der Tat geht es nicht nur um das Löschen von Daten. Einige könnten sagen, dass jede Aktualisierung eines Datensatzes auch eine Löschung ist. Weil die alte Version des Datensatzes nie wieder gefunden werden kann. Anstatt also Aktualisierungen an den Datenspeicher zu senden, senden Sie nur Einsätze, wenn "alte" Daten wichtig sind.

Im Falle von UDP und Paketverlust müssen Sie Ihre Software darauf aufbauen. Wenn ein Spiel Daten für eine Entität übermittelt, die bereits gelöscht wurde, ignoriere es einfach oder antworte darauf richtig. So viele Möglichkeiten hier.

Eventuell suchen Sie auch nach Event Sourcing. Es ist nicht das heilige Grale oder so, aber es funktioniert anders als normales CRUD. Stattdessen verwendet es CQRS, um die Befehls- und Abfrageseite zu trennen, und Ereignisquellen werden verwendet, um einen Strom von Ereignissen zu erzeugen. Sie speichern nur die Ereignisse. Wann immer Sie eine Entität angeben möchten, lesen Sie alle Ereignisse zurück. Es beginnt wahrscheinlich immer mit einer Einfügung, null oder mehreren Aktualisierungen und dann einigen Löschanweisungen. Sie werden alles da drin haben, was Sie wissen müssen. Diese Ereignisse werden auch an andere Komponenten gesendet, die Lesemodelle des letzten Status erstellen. Auf diese Weise kann eine Benutzerschnittstelle aus dem Lesemodell lesen und blitzschnell sein, aber jede Statusänderung kommt durch den Ereignisstrom und behandelt die Geschäftslogik für jedes Ereignis.

Wenn Sie daran interessiert sind, lesen Sie auf CQRS und Event Sourcing von Greg Young und viele andere Leute.