Właśnie przeczytałem ten artykuł i jestem zdezorientowany.
Wyobraźmy sobie 1 aplikację internetową i 1 odrębną aplikację działającą jako „pracownik”, obie współużytkujące tę samą bazę danych .
Och, powiedziałem „dzielenie się” .. ale o czym ostrzega ten artykuł? :
Po czwarte, współdzielenie bazy danych między aplikacjami (lub usługami) jest złą rzeczą. To zbyt kuszące, aby umieścić tam amorficzny stan wspólny i zanim się zorientujesz, będziesz miał ogromnie sprzężonego potwora.
=> nie zgadzam się. W niektórych przypadkach odrębne aplikacje nadal stanowią część tego samego urządzenia, dlatego też pojęcie „problemu z połączeniem” nie ma w tym przypadku sensu.
Kontynuujmy: aplikacja internetowa obsługuje żądania HTTP klientów i może aktualizować w dowolnym momencie niektóre agregacje (termin DDD), generując odpowiednie zdarzenia domeny.
Celem pracownika będzie obsługa tych zdarzeń domeny poprzez przetwarzanie potrzebnych zadań.
Chodzi o to:
Jak dane dotyczące zdarzeń powinny być przekazywane do pracownika?
Pierwszym rozwiązaniem, jak promuje czytany artykuł, byłoby użycie RabbitMQ, będącego doskonałym oprogramowaniem pośredniczącym zorientowanym na wiadomości.
Przepływ pracy byłby prosty:
Za każdym razem, gdy dyno sieciowe generuje zdarzenie, publikuje je za pośrednictwem RabbitMQ, który karmi pracownika.
Wadą byłoby to, że nic nie gwarantuje natychmiastowej spójności między zatwierdzeniem aktualizacji zbiorczej a opublikowaniem zdarzenia, bez radzenia sobie z potencjalnymi błędami wysyłania ... lub problemami sprzętowymi; to kolejny główny problem.
Przykład: Możliwe jest, że zdarzenie zostało opublikowane bez powodzenia aktualizacji zbiorczej ... w wyniku czego zdarzenie reprezentuje fałszywą reprezentację modelu domeny.
Można argumentować, że istnieje globalne XA (zatwierdzanie dwufazowe), ale nie jest to rozwiązanie, które pasuje do wszystkich baz danych lub oprogramowania pośredniego.
Co może być dobrym rozwiązaniem dla zapewnienia tej natychmiastowej spójności? :
IMO, przechowując zdarzenie w bazie danych, w tej samej transakcji lokalnej, co aktualizacja zbiorcza.
Zostanie utworzony prosty asynchroniczny program planujący, który będzie odpowiadał na zapytania dotyczące bieżących niepublikowanych zdarzeń z bazy danych i wysyłał je do RabbitMQ, który z kolei zapełnia pracownika.
Ale po co potrzebować dodatkowego harmonogramu po stronie aplikacji i przy okazji: po co w tym przypadku RabbitMQ?
Dzięki temu rozwiązaniu logiczne wydaje się, że RabbitMQ może być niepotrzebny, szczególnie dlatego, że baza danych jest współdzielona.
Rzeczywiście, bez względu na przypadek, widzieliśmy, że natychmiastowa spójność obejmuje odpytywanie z bazy danych.
Dlaczego więc pracownik nie byłby bezpośrednio odpowiedzialny za tę ankietę?
Zastanawiam się zatem, dlaczego tak wiele artykułów w Internecie z trudem krytykuje kolejkowanie baz danych, jednocześnie promując oprogramowanie pośrednie zorientowane na wiadomości.
Fragment artykułu:
Proste, użyj odpowiedniego narzędzia do pracy: ten scenariusz wymaga systemu przesyłania wiadomości. Rozwiązuje wszystkie problemy opisane powyżej; koniec z odpytywaniem, wydajne dostarczanie wiadomości, nie trzeba usuwać ukończonych wiadomości z kolejek ani żadnego stanu współdzielonego.
I natychmiastowa konsekwencja, zignorowana?
Podsumowując, naprawdę wydaje się, że niezależnie od przypadku, co oznacza, że baza danych jest współdzielona czy nie, potrzebujemy sondowania bazy danych .
Czy przeoczyłem niektóre krytyczne pojęcia?
Dzięki