CQRS przy użyciu Redis MQ

Question

Pracowałem nad projektem CQRS (mój pierwszy) przez ostatnie 9 miesięcy, który był ciężką krzywą uczenia się. Obecnie używam doskonałego EventStore JOliver w moim modelu zapisu i przy użyciu PostGresSql dla mojego modelu odczytu.

baz Zarówno mój odczytu i zapisu są na tym samym komputerze, co oznacza, że ​​po wprowadzeniu zmiany do bazy danych zapisu, w tym samym synchronicznego wywołania zmiana jest wykonana z modelem odczytu.

Jak uczyłem CQRS poczułem to był najlepszy sposób, aby przejść jak miałem żadnego doświadczenia z kolejki komunikatów/usług ram autobusowych takich jak MassTransit, NServiceBus itp

Jestem teraz w punkcie, z większością moja architektura w celu wprowadzenia struktury kolejki wiadomości.

Dziś natknąłem się na Redis MQ, który jest częścią ServiceStack i ponieważ już korzystamy z ServiceStack dla naszych klientów HTTP opartych na Reszcie, wydaje się, że jest to właściwa droga.

Moje pytanie jest więcej o zrozumienie tego, co muszę wiedzieć (lub jeśli mam żadnych nieporozumień) w celu wdrożenia Redis MQ i czy Redis MQ jest właściwym wyborem?

Teraz z tego co rozumiem, użyłbym Redis MQ jako trwałe kolejki pomiędzy zapisu i odczytu bazy danych. Gdy mój sklep z wydarzeniami zarejestruje, że coś się wydarzyło w mojej domenie, opublikuje go w Redis MQ. Usługi nasłuchujące zdarzeń/komunikatów otrzymałyby zdarzenie/wiadomość od Redis MQ i po jej przetworzeniu (tj. Zaktualizowaniu lub zapisaniu do modelu odczytu), powiadomienie/odpowiedź wraca do magazynu zdarzeń, aby poinformować magazyn zdarzeń, że wiadomość została odebrana i przetworzona przez detektora/subskrybenta.

Czy to brzmi poprawnie?

Również byłoby architektura Redis MQ dać mi wszystko, co oferują NSB, RavenDB, MassTransit itp?

Ponadto będę wdrażać na serwerach Windows 2008 i 2003. Czy system Redis jest stabilny dla tych systemów operacyjnych?

Answer 1

Teraz z tego co rozumiem, użyłbym Redis MQ jako trwałe kolejki między zapisu i odczytu bazy danych.

Tak to prawda.

Raz mój sklep zdarzenie nagrała, że ​​coś działo się w moim domeny to będzie publikować Redis MQ.

Tak i można tego dokonać na kilka sposobów. Może się to zdarzyć w ramach transakcji, która trwa w sklepie zdarzeń lub możesz mieć proces poza pasmem, który stale publikuje zdarzenia ze sklepu zdarzeń.

powiadomienie/odpowiedź wraca do składnicy zdarzeń opowiedzieć wydarzenie sklep, że komunikat został odebrany i przetwarzane przez słuchacza/abonenta.

Odpowiedź z powrotem do wydawcy zdarzenia jest zwykle pomijana. To naprawdę oddziela wydawców od subskrybentów. Przyjmujesz założenie, że po opublikowaniu komunikatu wszyscy zainteresowani subskrybenci go obsłużą.Jeśli coś się stanie, powinien zostać zarejestrowany błąd.

Również byłoby architektura Redis MQ dać mi wszystko, NSB, RavenDB, MassTransit itp zaoferowania?

Nie mam doświadczenie w prowadzeniu Redis MQ, ale wiem, że Redis obsługuje pub/sub, który jest jedną z propozycji wartości BBN i MassTransit (w przeciwieństwie do powiedzenia goły MSMQ). Jakie oferty MT i NSB poza pubem/subem to sagas i nie wygląda na to, że Redis MQ obsługuje co najmniej po wyjęciu z pudełka. Możesz nigdy nie mieć potrzeby sag, więc nie powinno to automatycznie zniechęcać. RavenDB nie jest kolejką wiadomości, więc nie ma tutaj zastosowania.

Ponadto będę wdrażać na serwerach Windows 2008 i 2003. Czy Redis jest stabilny dla tych systemów operacyjnych?

Zabrakło mi Redis na 2008 R2 i było stabilne więc myślę Redis MQ byłby stabilny, jak również.

Answer 2

Wydaje mi się, że implementacja kolejki komunikatów w usłudze Redis jest bardziej odpowiednia dla scenariuszy kolejkowania zadań - przesyła komunikat na końcu listy Redis, a następnie używa subskrypcji pubów Redis, aby powiadomić abonentów od nasłuchujących, że jest komunikat wyciągnąć z kolejki. Każdy konsument będzie konkurował o wiadomości.

Dla zaopatrzenia zdarzeń, może być bardziej zainteresowany typu fanout lub tematu wiadomości topologii opartej jak oferowane przez RabbitMQ, że nie sprzeciwia się od budowy tego rodzaju rzeczy używając Redis struktur dane samodzielnie.

Answer 3

Być może zainteresował Cię mały projekt boczny na GitHub, który jest kolejką i implementacją trwałości dla NServiceBus za pomocą Redis. https://github.com/mackie1001/NServicebus.Redis

Nie nazwałbym tego produkcją gotową i chcę przenieść ją do NSB 4 i wykonać pewne dokładne testy, ale mięso z tego jest zrobione.