Do czego służy ActiveMQ - czy możemy zastosować koncepcję przesyłania wiadomości za pomocą bazy danych?
116
Sprawdziłem to i wysyłał wiadomości między dwoma systemami.
Ale dlaczego? Dlaczego nie miałbyś po prostu użyć Database?
Musi być jakaś funkcja, która to ActiveMQmaDatabases nie ma?
Służy do niezawodnej komunikacji między dwoma rozproszonymi procesami.
Tak, możesz przechowywać wiadomości w bazie danych, aby komunikować się między dwoma procesami, ale gdy tylko wiadomość zostanie odebrana, będziesz musiał do DELETEwiadomości, Oznacza to wiersz INSERTi DELETEdla każdej wiadomości.
Kiedy próbujesz skalować to w górę, przesyłając tysiące wiadomości na sekundę, bazy danych zwykle się przewracają .
Zorientowane na wiadomości oprogramowanie pośrednie [MOM], podobnie jak ActiveMQz drugiej strony, jest zbudowane do obsługi takich przypadków użycia.
Zakładają, że wiadomości w sprawnym systemie zostaną bardzo szybko usunięte i mogą przeprowadzić optymalizacje, aby uniknąć kosztów ogólnych .
Może również wysyłać wiadomości do konsumentów zamiast konieczności odpytywania konsumenta o nową wiadomość, wykonując zapytanie SQL.
To dodatkowo zmniejsza opóźnienie związane z przetwarzaniem nowych wiadomości wysyłanych do systemu.
Niezłe wyjaśnienie! Czy dwa rozproszone procesy muszą być tym samym procesem? Mam na myśli dwie instancje tej samej aplikacji?
Maverick,
Nie, dowolne aplikacje mogą komunikować się ze sobą przez ActiveMQ. Na przykład aplikacje A i B mogą tworzyć kolejki AB i BA (czytaj: komunikaty dla A z B i na odwrót) i wysyłać komunikaty dla siebie do pasującej kolejki.
ActiveMQlub ogólnie wszystkie implementacje oprogramowania pośredniczącego zorientowanego na komunikaty (MOM) są przeznaczone do wysyłania komunikatów między dwiema aplikacjami lub dwoma składnikami wewnątrz jednej aplikacji.
Zasadniczo MOM i bazy danych mają wspólną podstawę, ponieważ zapewniają transakcyjne i trwałe przechowywanie danych do odczytu i zapisu.
Największą różnicą jest wzorzec użycia - tam, gdzie bazy danych są bardzo ogólne i zoptymalizowane pod kątem złożonego wyszukiwania w wielu tabelach, MOM jest zoptymalizowany do czytania wiadomości pojedynczo w sposób podobny do FIFO [kolejka].
JMS, który jest implementacją API ActiveMQ, jest ważnym kamieniem węgielnym aplikacji Java Enterprise. To sprawia, że wiadomości mają dość wspólny format i semantykę, co ułatwia integrację między różnymi aplikacjami.
Oczywiście, istnieje wiele bardziej szczegółowych cech, które są tylko w ActiveMQ, protokołów z drutu takich jak OpenWire, STOMPi MQTT, JMS, EIPwraz z Apache Camel, wzory komunikatów typu „żądanie / odpowiedź” i „publikowania / subskrypcji”, JMS Bridging, grupowanie (” sieć brokerów ”), które pozwalają na skalowanie i dystrybucję itp.
Jeśli jesteś zainteresowany , powinieneś trochę poczytać na te tematy, ponieważ są one dość duże.
ActiveMQma świetne wsparcie dla harmonogramów , co oznacza, że możesz zaplanować wysłanie wiadomości w określonym czasie .
Użyliśmy tej funkcji do wysyłania przypomnień o lekach pacjentom, którzy przesyłali szczegółowe informacje o swoich lekach w scenariuszu opieki zdrowotnej.
To fajnie. Do podobnych celów wykorzystaliśmy bibliotekę planowania Quartz.
Siddhartha
Użyliśmy bazy danych Oracle Scheduled Jobsdo tych samych celów.
ahmednabil88
15
W systemie RDBMS podczas przetwarzania wiersza danych zazwyczaj aktualizuje się flagę wskazującą, że wiersz został przetworzony, aby przetwarzanie nie było powtarzane.
Jednak w przypadku kolejki wiadomości wystarczy potwierdzić wiadomość, a następny odbiorca przetworzy następną.
Różnica polega na tym, że UPDATEinstrukcja w RDBMS jest naprawdę powolną operacją w porównaniu z instrukcją acknowledgein activmeq.
Decoupled : systemy mogą komunikować się bez połączenia. Kolejka leży między systemami, jedna awaria systemu nigdy nie wpłynie na inne, ponieważ komunikacja odbywa się za pośrednictwem kolejki. Systemy nadal działają, gdy są włączone.
Obsługa odzyskiwania : wiadomości w kolejkach same się utrwalały. Wiadomości można przywrócić później, jeśli kolejka się nie powiedzie.
Niezawodna komunikacja : rozważ system przetwarzający żądania klientów. W normalnych przypadkach system otrzymuje 100 żądań na minutę. Ten system jest zawodny, gdy liczba żądań przekracza średnią. W takim przypadku Queue może zarządzać żądaniami i może okresowo przesyłać wiadomości w oparciu o przepustowość systemu, nie przerywając jej.
Asynchroniczna : komunikacja klienta z serwerem jest nieblokująca. Gdy klient wyśle żądanie do serwera, może wykonywać inne operacje bez czekania na odpowiedź. Po otrzymaniu odpowiedzi klient może sobie z tym poradzić w każdej chwili.
Apache ActiveMQ to broker komunikatów typu open source napisany w języku Java wraz z pełnym klientem Java Message Service (JMS). Zapewnia „funkcje korporacyjne”, co w tym przypadku oznacza wspieranie komunikacji z więcej niż jednym klientem lub serwerem
Odnośnie twoich zapytań:
Dlaczego nie miałbyś używać bazy danych?
Bazy danych należy używać do danych trwałych, a nie do danych tymczasowych. Załóżmy, że musisz wysłać wiadomość od nadawcy do odbiorcy. Po odebraniu wiadomości Odbiorca wykonuje jedną operację (odbieranie, przetwarzanie i zapomnienie). Po przetworzeniu tej wiadomości w ogóle nie potrzebujesz tej wiadomości. W takim przypadku przechowywanie wiadomości w trwałej bazie danych nie jest właściwym rozwiązaniem.
W pełni zgadzam się z odpowiedzią @Hiram Chirino dotyczącą wstawiania i usuwania wiadomości w bazie danych, jeśli używasz bazy danych zamiast systemu wiadomości.
Integracja korporacyjna : Umożliwienie integracji aplikacji zbudowanych w różnych językach i w różnych systemach operacyjnych
Przejrzystość lokalizacji : aplikacje klienckie nie muszą wiedzieć, gdzie znajdują się aplikacje usługowe
Niezawodna komunikacja - producenci / odbiorcy wiadomości nie muszą być jednocześnie dostępni
Skalowanie - można skalować w poziomie, dodając więcej usług
Komunikacja asynchroniczna - klient może odpalić wiadomość i kontynuować inne przetwarzanie zamiast blokowania, dopóki usługa nie wyśle odpowiedzi;
Zmniejszone sprzężenie - założenia przyjęte przez klientów i usługi są znacznie ograniczone w wyniku poprzednich 5 korzyści. Usługa może zmieniać szczegółowe informacje o sobie, w tym lokalizację, protokół i dostępność, bez wpływu na klienta lub zakłócania jego pracy.
Musi istnieć funkcja ActiveMQ, której bazy danych nie mają?
Załóżmy, że masz aplikację, która jest używana w wielu lokalizacjach w tym samym czasie. Przypuśćmy również, że Twoja aplikacja musi obsługiwać tysiące żądań na minutę lub coś podobnego, więc normalne operacje bazy danych nie mogą obsłużyć takich operacji, Activemq działa jako przetwarzanie wiadomości, przenosi wszystkie wiadomości do kolejki, więc nawet jeśli jedna z aplikacji ulegnie awarii w jednym miejscu nie wpłynie to na inną lokalizację.
Odpowiedzi:
Służy do niezawodnej komunikacji między dwoma rozproszonymi procesami.
Tak, możesz przechowywać wiadomości w bazie danych, aby komunikować się między dwoma procesami, ale gdy tylko wiadomość zostanie odebrana, będziesz musiał do
DELETEwiadomości, Oznacza to wierszINSERTiDELETEdla każdej wiadomości.Kiedy próbujesz skalować to w górę, przesyłając tysiące wiadomości na sekundę, bazy danych zwykle się przewracają .
Zorientowane na wiadomości oprogramowanie pośrednie [MOM], podobnie jak
ActiveMQz drugiej strony, jest zbudowane do obsługi takich przypadków użycia.Zakładają, że wiadomości w sprawnym systemie zostaną bardzo szybko usunięte i mogą przeprowadzić optymalizacje, aby uniknąć kosztów ogólnych .
Może również wysyłać wiadomości do konsumentów zamiast konieczności odpytywania konsumenta o nową wiadomość, wykonując zapytanie SQL.
To dodatkowo zmniejsza opóźnienie związane z przetwarzaniem nowych wiadomości wysyłanych do systemu.
źródło
ActiveMQlub ogólnie wszystkie implementacje oprogramowania pośredniczącego zorientowanego na komunikaty (MOM) są przeznaczone do wysyłania komunikatów między dwiema aplikacjami lub dwoma składnikami wewnątrz jednej aplikacji.Zasadniczo MOM i bazy danych mają wspólną podstawę, ponieważ zapewniają transakcyjne i trwałe przechowywanie danych do odczytu i zapisu.
Największą różnicą jest wzorzec użycia - tam, gdzie bazy danych są bardzo ogólne i zoptymalizowane pod kątem złożonego wyszukiwania w wielu tabelach, MOM jest zoptymalizowany do czytania wiadomości pojedynczo w sposób podobny do FIFO [kolejka].
JMS, który jest implementacją API ActiveMQ, jest ważnym kamieniem węgielnym aplikacji Java Enterprise. To sprawia, że wiadomości mają dość wspólny format i semantykę, co ułatwia integrację między różnymi aplikacjami.Oczywiście, istnieje wiele bardziej szczegółowych cech, które są tylko w ActiveMQ, protokołów z drutu takich jak
OpenWire,STOMPiMQTT,JMS,EIPwraz z Apache Camel, wzory komunikatów typu „żądanie / odpowiedź” i „publikowania / subskrypcji”, JMS Bridging, grupowanie (” sieć brokerów ”), które pozwalają na skalowanie i dystrybucję itp.Jeśli jesteś zainteresowany , powinieneś trochę poczytać na te tematy, ponieważ są one dość duże.
źródło
ActiveMQma świetne wsparcie dla harmonogramów , co oznacza, że możesz zaplanować wysłanie wiadomości w określonym czasie .Użyliśmy tej funkcji do wysyłania przypomnień o lekach pacjentom, którzy przesyłali szczegółowe informacje o swoich lekach w scenariuszu opieki zdrowotnej.
źródło
Scheduled Jobsdo tych samych celów.W systemie RDBMS podczas przetwarzania wiersza danych zazwyczaj aktualizuje się flagę wskazującą, że wiersz został przetworzony, aby przetwarzanie nie było powtarzane.
Jednak w przypadku kolejki wiadomości wystarczy potwierdzić wiadomość, a następny odbiorca przetworzy następną.
Różnica polega na tym, że
UPDATEinstrukcja w RDBMS jest naprawdę powolną operacją w porównaniu z instrukcjąacknowledgein activmeq.źródło
chciałbym podkreślić, co następuje:
Decoupled : systemy mogą komunikować się bez połączenia. Kolejka leży między systemami, jedna awaria systemu nigdy nie wpłynie na inne, ponieważ komunikacja odbywa się za pośrednictwem kolejki. Systemy nadal działają, gdy są włączone.
Obsługa odzyskiwania : wiadomości w kolejkach same się utrwalały. Wiadomości można przywrócić później, jeśli kolejka się nie powiedzie.
Niezawodna komunikacja : rozważ system przetwarzający żądania klientów. W normalnych przypadkach system otrzymuje 100 żądań na minutę. Ten system jest zawodny, gdy liczba żądań przekracza średnią. W takim przypadku Queue może zarządzać żądaniami i może okresowo przesyłać wiadomości w oparciu o przepustowość systemu, nie przerywając jej.
Asynchroniczna : komunikacja klienta z serwerem jest nieblokująca. Gdy klient wyśle żądanie do serwera, może wykonywać inne operacje bez czekania na odpowiedź. Po otrzymaniu odpowiedzi klient może sobie z tym poradzić w każdej chwili.
źródło
Z Wikipedii
Odnośnie twoich zapytań:
Bazy danych należy używać do danych trwałych, a nie do danych tymczasowych. Załóżmy, że musisz wysłać wiadomość od nadawcy do odbiorcy. Po odebraniu wiadomości Odbiorca wykonuje jedną operację (odbieranie, przetwarzanie i zapomnienie). Po przetworzeniu tej wiadomości w ogóle nie potrzebujesz tej wiadomości. W takim przypadku przechowywanie wiadomości w trwałej bazie danych nie jest właściwym rozwiązaniem.
W pełni zgadzam się z odpowiedzią @Hiram Chirino dotyczącą wstawiania i usuwania wiadomości w bazie danych, jeśli używasz bazy danych zamiast systemu wiadomości.
Korzyści z tego artykułu i tego artykułu
Jest wiele. Zajrzyj na stronę dokumentacji, aby uzyskać więcej informacji. Spójrz też na przypadki użycia .
Spójrz na tę prezentację, aby zrozumieć wewnętrzne cechy ActiveMQ.
źródło
Załóżmy, że masz aplikację, która jest używana w wielu lokalizacjach w tym samym czasie. Przypuśćmy również, że Twoja aplikacja musi obsługiwać tysiące żądań na minutę lub coś podobnego, więc normalne operacje bazy danych nie mogą obsłużyć takich operacji, Activemq działa jako przetwarzanie wiadomości, przenosi wszystkie wiadomości do kolejki, więc nawet jeśli jedna z aplikacji ulegnie awarii w jednym miejscu nie wpłynie to na inną lokalizację.
źródło