Wie wird mit Situationen umgegangen, wenn das Lesemodell nicht mehr mit den Ereignisprotokollen synchron ist?

Wenn Snapshots von Aggregaten nicht mehr mit dem Ereignisprotokoll synchronisiert wurden, kann ich meine Ereignisse einfach aus früheren Snapshots (die synchron sein sollten) wiedergeben. Dasselbe kann ich tun, wenn ich neue Felder hinzufüge/entferne oder wenn ich Logik von vorhandenen Handlern ändere.Wie wird mit Situationen umgegangen, wenn das Lesemodell nicht mehr mit den Ereignisprotokollen synchron ist?

Für den Fall, dass ich ein neues Lesemodell hinzufügen muss (d. H. Eine neue Berichtsansicht), kann ich dasselbe wiederholen - ich werde meine Ereignisse erneut abspielen.

Aber wie soll ich mit der Situation umgehen, wenn das Lesemodell nicht mehr mit dem Ereignisprotokoll übereinstimmt? Das Speichern von Ereignissen und das Veröffentlichen erfolgen in einer Transaktion, das Aktualisieren des Lesemodells erfolgt jedoch in einer anderen Transaktion, die fehlschlagen kann. Wiederholte Ereignisse von Anfang an können helfen, aber es kann ewig dauern. Brauche ich ein Snapshot-Konzept für das gesamte Lesemodell?

Wie lösen Sie dieses Problem? Danke.

Quelle

2010-11-21 Dmitry Schetnikovich

Was wäre der Grund für einen Fehler im Event-Handler? Wie lange ist "Ewigkeit"?

Lesen Modellupdates selten fehlschlagen (im Gegensatz zu Befehlshandlern), da die Logik darin sehr einfach ist. Fehler werden wahrscheinlich durch vorübergehende Probleme (IO/Netzwerkausfall) verursacht und würden automatisch vom Nachrichtenbus behandelt.

Wenn jedoch das Lesemodell aus irgendeinem Grund beschädigt wurde, dann ist es der einfachste Weg, es zurückzusetzen und Ereignisse zu streamen. Selbst Millionen von Ereignissen würden relativ wenig Zeit benötigen. Außerdem können Sie den Map-Reduce-Ansatz verwenden.

Ich würde empfehlen, Schnappschüsse einzuführen, um Modelle zu lesen. Ich denke, das verkompliziert die Architektur nur ohne nennenswerte Gewinne.

Quelle

2010-11-23 13:59:10

Danke Rinat! Wenn Sie von Anfang an Ereignisse wiederholen, verwenden Sie einen Thread von Event-Handlern? Wenn ich mehrere Worker-Threads verwende, kann ich nicht korrekte Ergebnisse erhalten (während es in der Produktion aufgrund der Domain-Natur funktioniert - Race-Bedingung von mehreren Ereignissen ist nicht möglich, wenn von echten Benutzern veröffentlicht, aber möglich bei der Veröffentlichung eins nach dem anderen für mehrere Worker-Threads). Ist es global anerkannt, dass wir nur einen Worker-Thread für die Verarbeitung von Ereignissen von Anfang an verwenden sollten? Danke für Ihre wertvollen Antworten. –

Guter Anruf. Ich ziehe es vor, solche Nebenläufigkeitsprobleme zu vermeiden, indem ich immer nicht mehr als 1 Thread pro Entitätsinstanz (entweder Befehle oder Ereignisse) ausführe. Wir können also mehrere Threads für Event-Handler haben, jedoch wird jede einzelne * Instanz * (die durch eine Identität identifiziert wird) immer nur von einem einzelnen Thread behandelt. Natürlich kann ein Thread mehrere View-Instanzen oder -Typen gleichzeitig verarbeiten. Hilft das? –

Danke! Nach einigen Tagen der Analyse Ihrer Antwort denke ich, dass ich die Mechanik der Ereignisbehandlung mit mehreren Worker-Threads verstehe. Ich schätze deine Antworten. –

Wie wird mit Situationen umgegangen, wenn das Lesemodell nicht mehr mit den Ereignisprotokollen synchron ist?

Antwort

Verwandte Themen