0

Wenn Sie Event-Sourcing mit Aggregaten als Transaktionsbereich verwenden, sollten Sie dieses Aggregat natürlich lieber auf einem einzelnen Computer haben. Wenn Sie jedoch auch ein hochverfügbares und horizontal skalierbares System erstellen möchten, sollten Sie diesen Status auch auf vielen Computern in verschiedenen Datenbanken replizieren.Mehrere Schreibseiten mit Event Sourcing?

Wenn nur zu einem bestimmten Zeitpunkt eine Schreibseite auf einer Maschine in diesem Netzwerk erlaubt wird, können die anderen Maschinen schließlich konsistente Leseseiten sein. Aber um Schreibleistung zu maximieren, denke ich, es wäre besser, mehrere Schreibseiten gleichzeitig zuzulassen. Aber wie werden Konsistenz und Konsens in einem solchen System gehandhabt?

Wenn zwei oder mehr Maschinen gleichzeitig den gemeinsamen aber replizierten Zustand aktualisieren möchten, wie stelle ich sicher, dass die Befehle von allen Schreibseiten und in der gleichen Reihenfolge behandelt werden, so dass die resultierenden Ereignisse identisch sind und auch die die selbe Reihenfolge? Ist eine Lamport-Uhr Teil der Lösung?

Antwort

0

Aber um Schreibleistung zu maximieren, denke ich, es wäre besser, mehrere Schreibseiten gleichzeitig zu ermöglichen. Aber wie wird Konsistenz und Konsens in einem System wie diesem behandelt?

In ereignisbasierten Systemen ist die Konsistenz auf der Schreibseite immer stark. Dies wird durch die Aggregate und die Event store durch Verwendung der optimistischen Sperrung erzwungen: im Falle eines gleichzeitigen Schreibvorgangs (tatsächlich sind die Ereignisse nur an den Speicher angehängt) wird der Befehl hole wiederholt. Dies ist möglich, weil Aggregatbefehlsmethoden reine (nebenwirkungsfreie) Methoden sind. Solange die Ereignisse nicht beibehalten werden, kann der Befehl wiederholt werden.

Wenn zwei oder mehr Maschinen, die den Zustand in der gleichen Zeit aktualisiert (die zu wählen und anhalten?)

Beides. Der erste (immer gibt es einen ersten) Befehl erzeugt Ereignisse, die im Speicher gespeichert werden. Der secons-Befehl schlägt aufgrund einer concurent-Ausnahme auf niedriger Ebene fehl. Dann wird es wiederholt, indem alle vorherigen Ereignisse geladen und angewendet werden, einschließlich derjenigen, die durch den ersten Befehl erzeugt wurden. Dann erzeugt der zweite Befehl zusätzliche Ereignisse, die ebenfalls beibehalten werden, oder löst eine Ausnahme aus, wenn der neue Zustand es nicht erlaubt, den zweiten Befehl zu behandeln.

Sie müssen feststellen, dass der zweite Befehl mindestens zweimal ausgeführt wird, aber jedes Mal die vorherigen Ereignisse (also der Zustand) unterschiedlich sind.

Die Infrastruktur behält eine Aggregatversion bei, die an jeden Aggregatstrom angehängt ist. Jedes anhängende Ereignis erhöht diese Version. Es gibt eine eindeutige Einschränkung für die Aggregat-ID und -Version. Dies ist wahrscheinlich, wie alle Ereignisspeicher implementiert werden.

Wenn eine Maschine misbehaves (unwissentlich oder wissentlich) und fehlerhafte Ereignisse an den Rest des Netzwerks ausbreitet (wie dies zu erkennen?)

Ich sehe nicht, wie das passieren konnte, aber wenn es passiert, dann hängt es wirklich von Ihrem Verständnis eines fehlerhaften Ereignisses. Sie könnten einige Sagas/Prozessmanager haben, die die Ereignisse analysieren und einige E-Mails auslösen, die an einen Supervisor gesendet werden.

+0

Danke für Ihre Antwort. Ich sehe, wie optimistisches Sperren verwendet werden kann, wenn man eine einzige Schreibseite hat. Aber wenn mehrere Schreibseiten auf verschiedenen Maschinen (ohne eine gemeinsame Datenbank) vorhanden sind, müssten sie sich irgendwie einigen, welche Befehle zu verarbeiten sind. Eine optimistische Sperre würde auf einer Maschine mit gleichzeitigen Schreibvorgängen funktionieren, aber wie handhabe ich gleichzeitige Schreibvorgänge in einem skalierten System? –

+0

@AndreasZita Ohne eine gemeinsame Datenbank glaube ich nicht, dass das möglich ist. Wenn Sie jedoch eine gemeinsame Datenbank verwenden, können Sie Sharding mit 'Aggregate ID' verwenden. Auf diese Weise * minimieren * Sie die Wahrscheinlichkeit von concurent writes. –

0

Die Art, wie ich das in meinem Shuttle behandelt habe.Die ES-Implementierung Recall (schamloser Plug) dient zum Erstellen eines eindeutigen Clustered-Index für die Aggregat-ID und der Version im Ereignisspeicher. Auf diese Weise können sich mehrere Schreibvorgänge auf demselben AR niemals überschneiden und einer der beiden wird "verlieren". Zugegeben, dies funktioniert nur mit einem zentralen Datenspeicher, aber vielleicht verfügt Ihre Implementierung über einen ähnlichen Mechanismus.

Es gibt keine Einschränkung dafür, wie viele Clients gleichzeitig in den Ereignisspeicher schreiben können. Die Projektionsverarbeitung hat jedoch als einen einzelnen Thread pro benannter Projektion auf einer einzelnen Maschine, da die Ereignisreihenfolge so empfindlich ist. Nun, verschiedene Projektionen können auf verschiedenen Maschinen verarbeitet werden, denke ich.

Verwandte Themen