Obsługa współbieżności ES / CQRS

Niedawno zacząłem nurkować w CQRS / ES, ponieważ może być konieczne zastosowanie go w pracy. W naszym przypadku wydaje się to bardzo obiecujące, ponieważ rozwiązałoby wiele problemów.

Naszkicowałem swoje przybliżone zrozumienie tego, jak aplikacja ES / CQRS powinna wyglądać w kontekście w uproszczonej bankowości (wypłata pieniędzy).

Podsumowując, jeśli osoba A wypłaci trochę pieniędzy:

• wydano polecenie
• polecenie zostaje przekazane do weryfikacji / weryfikacji
• zdarzenie jest wypychane do magazynu zdarzeń, jeśli sprawdzanie poprawności się powiedzie
• agregator anuluje zdarzenie, aby zastosować modyfikacje agregatu

Z tego, co zrozumiałem, dziennik zdarzeń jest źródłem prawdy, ponieważ jest to dziennik FAKTÓW, możemy zatem z niego wyprowadzić każdą projekcję.

Teraz, czego nie rozumiem, w tym wielkim schemacie rzeczy, dzieje się w tym przypadku:

• reguła: saldo nie może być ujemne
• osoba A ma saldo 100e
• osoba A wydaje Wycofanie Komendy o wartości 100e
• sprawdzanie poprawności mija i następuje wydarzenie MoneyWithdrewEvent of 100e
• w międzyczasie osoba A wydaje kolejną komendę Wycofania o wartości 100e
• pierwszy MoneyWithdrewEvent nie został jeszcze zagregowany, dlatego też sprawdzanie poprawności przebiega pomyślnie, ponieważ sprawdzanie poprawności względem zagregowanego (które nie zostało jeszcze zaktualizowane)
• MoneyWithdrewEvent of 100e jest emitowany innym razem

==> Jesteśmy w niespójnym stanie równowagi na poziomie -100e, a dziennik zawiera 2 MoneyWithdrewEvent

Jak rozumiem, istnieje kilka strategii radzenia sobie z tym problemem:

• a) umieść identyfikator wersji zagregowanej wraz ze zdarzeniem w magazynie zdarzeń, więc jeśli podczas modyfikacji wystąpi niezgodność wersji, nic się nie stanie
• b) zastosować pewne strategie blokowania, co oznacza, że ​​warstwa weryfikacyjna musi jakoś je utworzyć

Pytania dotyczące strategii:

• a) W takim przypadku dziennik zdarzeń nie jest już źródłem prawdy, jak sobie z tym poradzić? Wróciliśmy również do klienta OK, chociaż zezwolenie na wypłatę było całkowicie błędne, czy w takim przypadku lepiej jest użyć zamków?
• b) Zamki == impasy, czy masz wgląd w najlepsze praktyki?

Ogólnie, czy rozumiem, jak radzić sobie z współbieżnością?

Uwaga: Rozumiem, że ta sama osoba wypłacająca dwa razy pieniądze w tak krótkim czasie jest niemożliwa, ale wziąłem prosty przykład, aby nie zagubić się w szczegółach

Naszkicowałem swoje przybliżone zrozumienie tego, jak aplikacja ES / CQRS powinna wyglądać w kontekście w uproszczonej bankowości (wypłata pieniędzy).

Jest to idealny przykład aplikacji opartej na zdarzeniach. Zaczynajmy.

Za każdym razem, gdy polecenie jest przetwarzane lub ponawiane (zrozumiesz, bądź cierpliwy), wykonywane są następujące kroki:

1. polecenie dociera do modułu obsługi poleceń, tj. usługi w Application layer.
2. moduł obsługi komend identyfikuje Aggregatei ładuje go z repozytorium (w tym przypadku ładowanie odbywa się przez new- Aggregatewystąpienie, pobranie wszystkich wcześniej emitowanych zdarzeń tego agregatu i ponowne zastosowanie ich do samego agregatu; wersja agregacji jest przechowywana dla później użyć; po zastosowaniu zdarzeń agregat jest w stanie końcowym - tzn. saldo rachunku bieżącego jest obliczane jako liczba)
3. handler komenda wywołuje odpowiednią metodę na Aggregate, jak Account::withdrawMoney(100)i zbiera uzyskane wydarzenia, tj MoneyWithdrewEvent(AccountId, 100); jeśli na koncie nie ma wystarczającej ilości pieniędzy (saldo <100), zgłaszany jest wyjątek i wszystko zostaje przerwane; w przeciwnym razie wykonywany jest następny krok.
4. program obsługi poleceń próbuje utrwalić plik w Aggregaterepozytorium (w tym przypadku repozytorium to Event Store); to zrobić poprzez dodanie nowych zdarzeń do Event streamwtedy i tylko wtedy, gdy versionz Aggregatejest jeszcze jeden, który był, gdy Aggregatezostał załadowany. Jeśli wersja nie jest taka sama, polecenie jest ponawiane - przejdź do kroku 1 . Jeśli versionjest to to samo, zdarzenia są dołączane do, Event streama klient otrzymuje Successstatus.

Ta kontrola wersji nazywa się blokowaniem optymistycznym i jest ogólnym mechanizmem blokującym. Innym mechanizmem jest pesymistyczne blokowanie, gdy inne zapisy są blokowane (jak nie zostały uruchomione), dopóki bieżący się nie zakończy.

Termin Event streamjest abstrakcją wokół wszystkich zdarzeń, które zostały wyemitowane przez to samo Agregat.

Powinieneś zrozumieć, że Event storejest to po prostu inny rodzaj trwałości, w którym przechowywane są wszystkie zmiany w agregacie, a nie tylko stan końcowy.

a) W takim przypadku dziennik zdarzeń nie jest już źródłem prawdy, jak sobie z tym poradzić? Wróciliśmy również do klienta OK, chociaż zezwolenie na wypłatę było całkowicie błędne, czy w takim przypadku lepiej jest użyć zamków?

Sklep zdarzeń jest zawsze źródłem prawdy.

b) Zamki == impasy, czy masz wgląd w najlepsze praktyki?

Korzystając z optymistycznego blokowania, nie masz blokad, wystarczy powtórzyć polecenie.

W każdym razie, Zamki! = Zakleszczenia

Naszkicowałem swoje przybliżone zrozumienie tego, jak aplikacja ES / CQRS powinna wyglądać w kontekście w uproszczonej bankowości (wypłata pieniędzy).

Blisko. Problem polega na tym, że logika aktualizowania „agregatu” znajduje się w dziwnym miejscu.

Bardziej typową implementacją jest to, że model danych przechowywany przez moduł obsługi poleceń w pamięci oraz strumień zdarzeń w magazynie zdarzeń są synchronizowane.

Łatwy do opisania przykład to przypadek, w którym moduł obsługi poleceń zapisuje synchronicznie w magazynie zdarzeń i aktualizuje swoją lokalną kopię modelu, jeśli połączenie ze sklepem zdarzeń wskazuje, że zapis się powiódł.

Jeśli moduł obsługi poleceń musi ponownie zsynchronizować się ze składnicą zdarzeń (ponieważ jego model wewnętrzny nie odpowiada modelowi ze sklepu), robi to, ładując historię ze sklepu i odbudowując własny stan wewnętrzny.

Innymi słowy, strzałki 2 i 3 (jeśli są obecne) normalnie byłyby połączone ze sklepem zdarzeń, a nie ze sklepem zbiorczym.

umieść identyfikator wersji zagregowanej wraz ze zdarzeniem w magazynie zdarzeń, więc jeśli podczas modyfikacji występuje niezgodność wersji, nic się nie dzieje

Odmiany tego są zwykłym przypadkiem - zamiast dołączać do strumienia w strumieniu zdarzeń, zwykle PUT umieszczamy w określonej lokalizacji w strumieniu; jeśli operacja ta jest niezgodna ze stanem sklepu, zapis nie powiedzie się, a usługa może wybrać odpowiedni tryb awarii (nie można klienta, ponowić próby, scalić ....). Korzystanie z zapisu idempotentnego rozwiązuje wiele problemów związanych z rozproszonym przesyłaniem wiadomości, ale oczywiście wymaga posiadania sklepu obsługującego zapis idempotentny.