Używanie Kafki jako magazynu zdarzeń (CQRS). Dobry pomysł?


219

Chociaż Natknąłem Kafki przed, ja właśnie niedawno zrealizowane Kafka może być stosowany jako (być może w oparciu o) A CQRS , eventstore .

Jeden z głównych punktów obsługiwanych przez Kafkę:

  • Przechwytywanie / przechowywanie zdarzeń, oczywiście wszystkie HA.
  • Architektura pubu / podrzędna
  • Możliwość odtworzenia dziennika zdarzeń, który umożliwia nowym abonentom zarejestrowanie się w systemie po fakcie.

Trzeba przyznać, że nie jestem w 100% zaznajomiony z CQRS / pozyskiwaniem zdarzeń, ale wydaje się to dość bliskie temu, czym powinien być sklep z wydarzeniami. Zabawne jest to, że naprawdę nie mogę znaleźć tak wiele na temat tego, że Kafka jest używany jako sklep z wydarzeniami, więc być może coś mi brakuje.

Czegoś więc brakuje w Kafce, żeby był to dobry sklep z wydarzeniami? Czy to zadziała? Korzystasz z produkcji? Zainteresowany wglądem, linkami itp.

Zasadniczo stan systemu jest zapisywany na podstawie transakcji / zdarzeń, które system kiedykolwiek otrzymał, zamiast po prostu zapisywać bieżący stan / migawkę systemu, co zwykle się dzieje. (Pomyśl o tym jak o księdze głównej w rachunkowości: wszystkie transakcje ostatecznie sumują się do stanu końcowego) Pozwala to na wszelkiego rodzaju fajne rzeczy, ale po prostu przeczytaj o podanych linkach.


Cześć Geert-Jan. Z perspektywy czasu, jak poradziłeś sobie z tym problemem? Mam powiązane pytanie (tutaj: stackoverflow.com/questions/58763727/... ). Większość osób sugerujących adopcję Kafki wydaje się polegać na niezmienności dziennika dołączania, wysokiej przepustowości i gwarancji kolejności partycji. Widzę problemy związane z szybkim wyszukiwaniem w ramach tematów (w przypadku „rekonstrukcji” jednostki), brak atomowości transakcyjnej i brak uporządkowania między partycjami (Gwarancja 100% zamówienia wymaga użycia tylko 1 współbieżności zabijania partycji)
Tony _008 08.1119

Nie udało mi się tego ostatecznie, ponieważ zakończyłem ten projekt boczny. Obawiam się więc, że nie ma jasnej odpowiedzi
Geert-Jan

Odpowiedzi:


119

Kafka ma być systemem przesyłania wiadomości, który ma wiele podobieństw do sklepu z wydarzeniami, ale cytuje swoje wprowadzenie:

Klaster Kafka zachowuje wszystkie opublikowane wiadomości - niezależnie od tego, czy zostały zużyte - przez konfigurowalny okres czasu . Na przykład, jeśli retencja jest ustawiona na dwa dni, to przez dwa dni po opublikowaniu wiadomości jest ona dostępna do konsumpcji, po czym zostanie odrzucona w celu zwolnienia miejsca. Wydajność Kafki jest efektywnie stała w odniesieniu do wielkości danych, więc zatrzymywanie dużej ilości danych nie stanowi problemu.

Chociaż wiadomości mogą być potencjalnie przechowywane w nieskończoność, oczekujemy, że zostaną usunięte. Nie oznacza to, że nie możesz używać tego jako sklepu z wydarzeniami, ale może być lepiej użyć czegoś innego. Spójrz na EventStore na alternatywę.

AKTUALIZACJA

Dokumentacja Kafka :

Pozyskiwanie zdarzeń to styl projektowania aplikacji, w którym zmiany stanu są rejestrowane jako uporządkowana sekwencja rekordów. Obsługa bardzo dużych przechowywanych danych dziennika przez Kafkę sprawia, że ​​jest to doskonały backend dla aplikacji zbudowanej w tym stylu.

AKTUALIZACJA 2

Jednym z problemów związanych z używaniem Kafki do pozyskiwania wydarzeń jest liczba wymaganych tematów. Zazwyczaj w przypadku pozyskiwania zdarzeń istnieje strumień (temat) zdarzeń na jednostkę (taki jak użytkownik, produkt itp.). W ten sposób bieżący stan encji można odtworzyć przez ponowne zastosowanie wszystkich zdarzeń w strumieniu. Każdy temat Kafka składa się z jednej lub więcej partycji, a każda partycja jest przechowywana jako katalog w systemie plików. Pojawi się również presja ze strony ZooKeepera, gdy liczba znodów rośnie.


16
Patrzyłem na Kafkę i miałem jeszcze jeden problem: nie zauważyłem nic z optymistycznej zbieżności. Idealnie mógłbym powiedzieć: „Dodaj to zdarzenie jako element N + 1 tylko wtedy, gdy najnowszym zdarzeniem obiektu jest nadal N.”
Darien

2
@Darien: Prawdopodobnie wybieram konfigurację, w której Redis karmi Kafkę (używając powiadomień Redis ). Ponieważ Redis pozwala na optymistyczną współbieżność (przy użyciu Watch / multi-exec), powinno to działać
Geert-Jan

2
@Darien Nie jestem ekspertem od pozyskiwania zdarzeń, ale rozumiem, że ogólnie rzecz biorąc, nie potrzebujesz optymistycznej współbieżności, ponieważ zdarzenia są z definicji zapisem rzeczy, które zdarzyły się już historycznie.
Jan

4
@John Myślę, że jeśli masz już autorytatywne zamawianie niepowodujących konfliktu wydarzeń, oznacza to, że gdziekolwiek one mieszkają, twoja rzeczywista technologia przechowywania wydarzeń, a Kafka jest właśnie używany jako dodatkowy system do ich dystrybucji.
Darien

1
Znajdziesz tu także cenne informacje: groups.google.com/forum/#!topic/dddcqrs/rm02iCfffUY
manuc66

283

Jestem jednym z oryginalnych autorów Kafki. Kafka będzie działał bardzo dobrze jako dziennik pozyskiwania zdarzeń. Jest odporny na uszkodzenia, skaluje się do ogromnych rozmiarów danych i ma wbudowany model partycjonowania.

Używamy go do kilku przypadków użycia tego formularza na LinkedIn. Na przykład nasz system przetwarzania strumienia open source, Apache Samza, ma wbudowaną obsługę pozyskiwania zdarzeń.

Myślę, że nie słyszysz wiele o używaniu Kafki do pozyskiwania wydarzeń, ponieważ terminologia dotycząca pozyskiwania zdarzeń nie wydaje się być zbyt rozpowszechniona w przestrzeni konsumenckiej, w której Kafka jest najbardziej popularna.

Tutaj pisałem trochę o tym stylu używania Kafki .


2
Zamierzałem opublikować ten link :) Awesome post na blogu. Byłoby dobrze móc to skomentować, ponieważ mam wiele pytań. @ Geert-Jan przyjrzyj się również „architekturze Lambda”, jest to dość podobne i nazwa pochodzi od autora Storma, głównie za pomocą pewnego rodzaju dziennika zdarzeń opartego na hadoopie w wielu przykładach
Sebastien Lorber

6
@Jay: Ponieważ ponownie zainteresowałem się tym tematem, czy mógłbyś nieco rozwinąć fakt, że Kafka wydaje się być zaprojektowany tak, aby publikowane wiadomości wygasały po określonym czasie? Jeśli używasz Kafki jako źródła zdarzeń, wiadomości powinny być przechowywane przez czas nieokreślony. Prawdopodobnie jest konfigurowalny, ale czy stanowiłoby to problem?
Geert-Jan

2
Czy są jakieś porównania między Kafka i sklepem z wydarzeniami? Szczególnie podoba mi się skupianie się na FRP w sklepie o nazwie Projections. Czy jest coś takiego w Kafka / Samza?
CMCDragonkai

4
Interesuje mnie również pytanie @ Geert-Jan do Jaya. Kafka nie nadaje się do faktycznego pozyskiwania zdarzeń po stronie transakcyjnej, ponieważ potrzebuje strumienia zdarzeń (tematów) na agregację domen (pomyśl miliony). Jednak idealnie nadaje się do wprowadzania do niego zdarzeń z np. GetEventStore. Ale to będzie działać tylko z nieskończenie zachowanymi zdarzeniami (w naszym przypadku), a poza kilkoma krótkimi komentarzami, nie wydaje się to być obsługiwanym przypadkiem użycia Kafki? Czy się tu mylę? Na przykład Samza zakłada, że ​​istnieją tylko dwa scenariusze: przechowywanie na podstawie czasu lub przechowywanie na podstawie klucza. Są inni ..
Stephen Drew,

3
@eulerfx Zakładając, że chcielibyśmy użyć Kafki jako pamięci dla systemu pozyskiwanego ze zdarzeń, jak należy wdrożyć optymistyczne blokowanie / współbieżność?
Krzysztof Branicki

51

Wracam do tej kontroli jakości. I nie znalazłem wystarczających niuansów w istniejących odpowiedziach, więc dodaję tę.

TL; DR. Tak lub Nie, w zależności od wykorzystania źródła zdarzeń.

Są dwa podstawowe rodzaje systemów pochodzących ze zdarzeń, o których jestem świadomy.

Procesory zdarzeń podrzędnych = Tak

W tego rodzaju systemie wydarzenia zdarzają się w prawdziwym świecie i są rejestrowane jako fakty. Na przykład system magazynowy do śledzenia palet produktów. Zasadniczo nie ma konfliktów. Wszystko już się wydarzyło, nawet jeśli było źle. (Tj. Paleta 123456 umieszczona na ciężarówce A, ale została zaplanowana na ciężarówkę B.) Następnie fakty są sprawdzane pod kątem wyjątków za pośrednictwem mechanizmów sprawozdawczych. Wydaje się, że Kafka nadaje się do tego rodzaju aplikacji przetwarzających zdarzenia.

W tym kontekście zrozumiałe jest, dlaczego ludzie Kafki opowiadają się za rozwiązaniem Sourcing zdarzeń. Ponieważ jest bardzo podobny do tego, jak jest już używany, na przykład w strumieniach kliknięć. Jednak osoby używające terminu Sourcing zdarzeń (w przeciwieństwie do przetwarzania strumieniowego) prawdopodobnie odnoszą się do drugiego użycia ...

Kontrolowane przez aplikację źródło prawdy = nie

Ten rodzaj aplikacji deklaruje własne zdarzenia w wyniku wniosków użytkowników przesyłanych przez logikę biznesową. Kafka nie działa dobrze w tym przypadku z dwóch głównych powodów.

Brak izolacji bytu

Ten scenariusz wymaga możliwości załadowania strumienia zdarzeń dla określonego obiektu. Częstym tego powodem jest zbudowanie modelu zapisu przejściowego dla logiki biznesowej w celu przetworzenia żądania. W Kafce jest to niepraktyczne. Użycie tematu na jednostkę może na to pozwolić, z wyjątkiem tego, że nie jest to starter, gdy mogą istnieć tysiące lub miliony podmiotów. Wynika to z ograniczeń technicznych w Kafka / Zookeeper.

Jednym z głównych powodów stosowania przejściowego modelu zapisu w ten sposób jest tanie i łatwe do wdrożenia zmiany logiki biznesowej.

Użycie Kafka jest zalecane zamiast tematu dla typu, ale wymagałoby to załadowania zdarzeń dla każdej jednostki tego typu, aby uzyskać zdarzenia dla pojedynczej jednostki. Ponieważ nie można stwierdzić na podstawie pozycji dziennika, które zdarzenia należą do której jednostki. Nawet przy użyciu migawek, aby rozpocząć od znanej pozycji dziennika, może to oznaczać znaczną liczbę zdarzeń.

Brak wykrywania konfliktu

Po drugie, użytkownicy mogą tworzyć warunki wyścigu z powodu równoczesnych żądań skierowanych do tego samego podmiotu. Zapisywanie sprzecznych zdarzeń i rozwiązywanie ich po fakcie może być całkiem niepożądane. Dlatego ważne jest, aby móc zapobiegać konfliktom. Aby skalować ładowanie żądań, często używa się usług bezstanowych, jednocześnie zapobiegając konfliktom zapisu przy użyciu zapisów warunkowych (zapis tylko, jeśli ostatnim zdarzeniem encji było #x). Aka Optimistic Concurrency. Kafka nie obsługuje optymistycznej współbieżności. Nawet jeśli wspierałoby to na poziomie tematu, musiałoby być aż do poziomu encji, aby było skuteczne. Aby używać Kafki i zapobiegać konfliktom zdarzeń, musisz użyć stanowego, zserializowanego programu piszącego na poziomie aplikacji. Jest to znaczące wymaganie / ograniczenie architektoniczne.

Dalsza informacja


Zaktualizuj według komentarza

Komentarz został usunięty, ale pytanie brzmiało: co ludzie wykorzystują do przechowywania zdarzeń?

Wygląda na to, że większość ludzi umieszcza własną implementację pamięci zdarzeń na istniejącej bazie danych. W przypadku scenariuszy nie dystrybuowanych, takich jak wewnętrzne zaplecze lub produkty autonomiczne, dobrze udokumentowano sposób tworzenia magazynu zdarzeń opartego na języku SQL. Istnieją biblioteki dostępne na różnych bazach danych. Istnieje również EventStore , który został zbudowany w tym celu.

W scenariuszach rozproszonych widziałem kilka różnych implementacji. Projekt Panther Jet używa platformy Azure CosmosDB z funkcją Zmień kanał informacyjny, aby powiadomić słuchaczy. Inną podobną implementacją, o której słyszałem w AWS, jest użycie DynamoDB z funkcją strumieni do powiadamiania słuchaczy. Klucz partycji prawdopodobnie powinien być identyfikatorem strumienia dla najlepszej dystrybucji danych (aby zmniejszyć ilość nadmiernej obsługi administracyjnej). Jednak pełne odtworzenie w różnych strumieniach w Dynamo jest drogie (odczyt i koszt). Więc ten impl został również skonfigurowany dla strumieni dynamo do zrzucania zdarzeń do S3. Kiedy nowy słuchacz wchodzi w tryb online lub istniejący słuchacz chce pełnej powtórki, najpierw przeczytałby S3, aby go nadrobić.

Mój obecny projekt jest scenariuszem obejmującym wiele dzierżawców, a swój własny projekt wprowadziłem na Postgres. Coś takiego jak Citus wydaje się odpowiednie dla skalowalności, partycjonowanie według tentant + stream.

Kafka jest nadal bardzo przydatny w scenariuszach rozproszonych. Nie jest trywialnym problemem udostępnianie zdarzeń każdej usługi innym usługom. Sklep z wydarzeniami zwykle nie jest do tego budowany, ale właśnie to robi Kafka. Każda usługa ma własne wewnętrzne źródło prawdy (może być przechowywaniem zdarzeń lub w inny sposób), ale słucha Kafki, aby wiedzieć, co dzieje się „na zewnątrz”. Serwis może także publikować wydarzenia w Kafce, aby informować „poza” o interesujących rzeczach, które zrobiła usługa.


1
@Dominik Wspomniałem o EventStore w sekcji Aktualizacja (drugi akapit). Wrócę i połączę to. Próbowałem tego i ma imponującą perf. Dla naszego małego zespołu, jak dotąd nie wprowadzono innej bazy danych, uznano ją za ważniejszą, dlatego Postgres (który jest również używany do widoków). Możliwe, że w przyszłości przejdziemy do EventStore lub w przyszłych produktach.
Kasey Speakman

2
@KaseySpeakman Tematy to nie to samo, co partycje. Temat ma jedną lub więcej partycji. Gwarantujemy, że partycje mają tylko jednego konsumenta na grupę w danym momencie. Podziel swoje byty na partycje w taki sposób, aby z tego skorzystać. Nie potrzebujesz tematu na jednostkę ani nawet partycji na jednostkę. Musisz po prostu podzielić je na partycje w taki sposób, aby zagwarantować, że wszystkie polecenia skierowane do tego samego bytu trafią do tej samej partycji.
Andrew Larsson,

1
@KaseySpeakman Wiele podmiotów może współdzielić jedną partycję. Kto powiedział, że zawsze musisz ładować stan bytu bezpośrednio ze sklepu zdarzeń, odtwarzając zdarzenia? Istnieją inne sposoby na osiągnięcie tej samej koncepcji bez ścisłego przestrzegania implementacji Grega Younga.
Andrew Larsson,

1
@AndrewLarsson Jeśli nie partycjonujesz według encji, to jak zapobiegniesz konfliktom zdarzeń na poziomie encji? Ponieważ wróciliśmy z powrotem do konfliktów współbieżności, być może powinieneś opublikować swój własny artykuł na nośniku lub w jaki sposób wykorzystałeś Kafkę do pozyskiwania zdarzeń (nie przetwarzania strumieniowego) w produkcji. Jak to zrobić z partycją według typu i bez kontroli współbieżności na poziomie jednostki. Przeczytałbym to i nawet nie trollowałbym was komentarzami, gdybym się nie zgodził.
Kasey Speakman

2
@KaseySpeakman Korzystanie z Kafki w ten sposób w żaden sposób nie jest łatwe. Ale jeśli jesteś na skalę, na której poważnie zastanawiałeś się nad CQRS i zaopatrzeniem w zdarzenia, to jesteś na skalę, na której nie możesz sobie pozwolić na robienie rzeczy w prosty sposób. Twój model współbieżności ma bezpośredni wpływ na twoją skalę - nie wybieraj go arbitralnie. Ponadto HTTP nie jest niezawodnym transportem i ponownie, jeśli jesteś na taką skalę, nie możesz sobie pozwolić na poświęcenie czasu na rozwiązywanie zagubionych i / lub powielających się problemów z wiadomościami. Można to wszystko rozwiązać za pomocą Kafki między klientem a procesorem poleceń, ale tak, kosztem złożoności.
Andrew Larsson,

20

Możesz używać Kafki jako sklepu z wydarzeniami, ale nie polecam tego, chociaż może to wyglądać na dobry wybór:

  • Kafka gwarantuje co najmniej raz dostawę, aw sklepie z wydarzeniami są duplikaty, których nie można usunąć. Aktualizacja: tutaj możesz przeczytać, dlaczego jest tak trudno z Kafką i kilka najnowszych wiadomości o tym, jak w końcu osiągnąć to zachowanie: https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how -apache-kafka-does-it /
  • Ze względu na niezmienność nie ma możliwości manipulowania pamięcią zdarzeń, gdy aplikacja ewoluuje i zdarzenia wymagają transformacji (istnieją oczywiście metody takie jak upcasting, ale ...). Kiedyś można powiedzieć, że nigdy nie trzeba przekształcać zdarzeń, ale nie jest to prawidłowe założenie, może wystąpić sytuacja, w której wykonujesz kopię zapasową oryginału, ale uaktualniasz je do najnowszych wersji. Jest to poprawny wymóg w architekturach sterowanych zdarzeniami.
  • Żadne miejsce do utrwalania migawek bytów / agregatów i odtwarzania będzie coraz wolniejsze. Tworzenie migawek musi być cechą magazynu zdarzeń z długoterminowej perspektywy.
  • Biorąc pod uwagę, że partycje Kafka są rozproszone i trudno nimi zarządzać, a kopie zapasowe są porównywane z bazami danych. Bazy danych są po prostu prostsze :-)

Zanim więc dokonasz wyboru, zastanów się dwa razy. Magazyn zdarzeń jako połączenie interfejsów warstwy aplikacji (monitorowanie i zarządzanie), sklep SQL / NoSQL i Kafka jako broker to lepszy wybór niż pozostawienie Kafce obsługi obu ról w celu stworzenia kompletnego rozwiązania pełnego funkcji.

Sklep z wydarzeniami jest złożoną usługą, która wymaga więcej niż to, co może zaoferować Kafka, jeśli poważnie myślisz o zastosowaniu Sourcingu zdarzeń, CQRS, Sagas i innych wzorców w architekturze opartej na zdarzeniach i pozostaje wysoka wydajność.

Zachęcam do zakwestionowania mojej odpowiedzi! Może ci się nie podobać to, co mówię o twoim ulubionym brokerze z wieloma nakładającymi się na siebie możliwościami, ale Kafka nie została zaprojektowana jako sklep z wydarzeniami, ale bardziej jako wysokowydajny broker i bufor w tym samym czasie do obsługi szybkich producentów w porównaniu ze scenariuszami powolnych klientów na przykład.

Zajrzyj do struktury open source eventuate.io microservices, aby dowiedzieć się więcej o potencjalnych problemach: http://eventuate.io/

Aktualizacja od 8 lutego 2018 r

Nie uwzględniam nowych informacji z komentarzy, ale zgadzam się z niektórymi z tych aspektów. Ta aktualizacja zawiera więcej informacji na temat niektórych rekomendacji dla platformy opartej na zdarzeniach w mikrousługach. Jeśli poważnie podchodzisz do solidnej konstrukcji mikrousług i ogólnie najwyższej możliwej wydajności, dam ci kilka wskazówek, które mogą Cię zainteresować.

  1. Nie używaj wiosny - jest świetna (często jej używam), ale jednocześnie jest ciężka i powolna. I wcale nie jest to platforma mikrousług. To „tylko” framework, który pomoże ci go wdrożyć (dużo pracy za tym…). Inne frameworki to „tylko” lekkie REST lub JPA lub frameworki o różnej koncentracji. Polecam prawdopodobnie najlepszą w swojej klasie kompletną platformę mikrousługową typu open source, która wraca do czystych korzeni Java: https://github.com/networknt

Jeśli zastanawiasz się nad wydajnością, możesz porównać się z istniejącym pakietem testów. https://github.com/networknt/microservices-framework-benchmark

  1. W ogóle nie używaj Kafki :-)) To pół żart. Mam na myśli to, że chociaż Kafka jest świetny, jest to kolejny system zorientowany na brokera. Myślę, że przyszłość jest w systemach przesyłania wiadomości bez pośredników. Możesz być zaskoczony, ale są szybsze niż systemy Kafka :-), oczywiście musisz zejść na niższy poziom. Spójrz na Kronikę.

  2. Do sklepu z wydarzeniami polecam lepsze rozszerzenie Postgresql o nazwie TimescaleDB, które koncentruje się na przetwarzaniu danych o wysokiej wydajności w seriach czasowych (zdarzeniami są serie czasowe) w dużych ilościach. Oczywiście CQRS, funkcje pozyskiwania zdarzeń (powtórki itp.) Są wbudowane w ramy light4j, które wykorzystują Postgres jako małą pamięć.

  3. Dla wiadomości spróbuj spojrzeć na Chronicle Queue, Map, Engine, Network. Mam na myśli pozbywanie się tych staromodnych rozwiązań zorientowanych na brokera i skorzystanie z systemu mikro-wiadomości (wbudowanego). Kolejka Kroniki jest nawet szybsza niż Kafka. Ale zgadzam się, że to nie wszystko w jednym rozwiązaniu i trzeba trochę popracować, inaczej kupisz wersję Enterprise (płatną). Na koniec wysiłek budowy własnej kroniki z Chronicle zostanie opłacony poprzez usunięcie ciężaru związanego z utrzymywaniem klastra Kafka.


Ciekawy widok. Czy chciałbyś rozwinąć kilka punktów? > Kafka gwarantuje tylko raz dostawę, aw sklepie z wydarzeniami są duplikaty, których nie można usunąć. Wydaje się, że sugerujesz, że istnieje coś takiego jak dokładnie raz dostawa. afaik (i jestem tego pewien) nie ma czegoś takiego w systemie rozproszonym. 2) Co do twojego punktu 2: klasyczna szkoła (zaopatrzenie w wydarzenia / dddd) uważa, że ​​zdarzenia są z natury niezmienne. Tj .: zdarzają się, nie ma sposobu na zmianę przeszłości. Jaki jest faktyczny przypadek zmiany ich z perspektywy czasu? Dzięki!
Geert-Jan

1.) Hazelcast, aby upewnić się, że każda wiadomość zostanie przetworzona raz i tylko raz. 2.) Nie podoba mi się coś takiego jak _V2 w kodzie usługi, więc albo wykonasz kopię zapasową, aby zarchiwizować i odtworzyć stare zdarzenia do ich nowych wersji (nadal masz oryginalną prawdę), lub możesz ukryć / wbudować tę funkcjonalność bezpośrednio w zdarzenie Przechowuj funkcję migawki, więc jest jeden punkt upcastingu -> sklep zdarzeń. Jakie są na to twoje rozwiązania?
kensai,

1) przynajmniej raz + idempotencja wobec konsumenta. Tj .: sprawdź, czy zdarzenie już było widoczne. Jeśli tak, pomiń. Lub jeszcze lepiej, miej idempotentne działania. Oczywiście nie zawsze jest to możliwe. 2) Nigdy nie spotkałem się z koniecznością aktualizacji wydarzeń. Zawsze traktuję same wydarzenia jako źródło prawdy i zamieszczam wszystkie informacje, których kiedykolwiek potrzebowałem. Robiąc to, nigdy nie spotkałem się z sytuacją, w której potrzebowałem innej struktury zdarzenia i / lub danych o zdarzeniu. Ale może ymmv. Zainteresowany słyszeniem, w jakich sytuacjach rzeczywiście potrzebujesz aktualnych wydarzeń.
Geert-Jan,

1.) może być dobrym wyborem. 2.) Twoje struktury danych były idealne od samego początku :-) na szczęście, haha. Może nie potrzebuję go w moim obecnym projekcie, ale buduję całą platformę na forkach eventuate.io połączonych z niektórymi wysokowydajnymi podejściami JEE zaczerpniętymi z lekkiego eventuate 4j ... cała ta dyskusja nie jest miejscem na komentarze na temat przepełnienia stosu , ale jeśli jesteś zainteresowany nurkowaniem głębiej, polecam ten artykuł: leanpub.com/esversioning/read
kensai

1
Nawiasem mówiąc, Kafka obsługuje teraz dokładnie jedną dostawę. Zaktualizuj
punkt

8

Tak, możesz używać Kafki jako sklepu z wydarzeniami. Działa całkiem dobrze, zwłaszcza po wprowadzeniu strumieni Kafka , które zapewniają natywny sposób przetwarzania zdarzeń w akumulowany stan, w którym można zapytać .

Jeżeli chodzi o:

Możliwość odtworzenia dziennika zdarzeń, który umożliwia nowym abonentom zarejestrowanie się w systemie po fakcie.

To może być trudne. Omówiłem to szczegółowo tutaj: https://stackoverflow.com/a/48482974/741970


0

Tak, Kafka działa dobrze w modelu pozyskiwania zdarzeń, szczególnie CQRS, jednak należy zachować ostrożność przy ustalaniu TTL dla tematów i zawsze pamiętać, że Kafka nie został zaprojektowany dla tego modelu, jednak możemy go bardzo dobrze wykorzystać.


0

Myślę, że powinieneś przyjrzeć się szkieletowi aksonów wraz z ich wsparciem dla Kafki

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.