Do tej pory wszystkie operacje wykonywaliśmy na jednej instancji RabbitMQ. Ma to kilka wady. Pierwsza i najważniejsza, to brak bezpieczeństwa. Co się stanie, gdy serwer RabbitMQ ulegnie awarii ?? Czy jesteś w stanie odzyskać dane z serwera, jak szybko jesteś w stanie uruchomić kolejną instancję ?? Wiele niewiadomych, a można sypiać spokojniej dzięki klastrowi.
W poprzednim wpisie z serii o RabbitMQ dowiedzieliśmy się jak poprawnie obsłużyć sytuację w której konsument z jakiegoś powodu nie poradził sobie z obsłużeniem wiadomości. Powodów może być wiele, ale nie to jest najważniejsze. Najważniejsze jest to, że wiadomość bezpiecznie wróciła do kolejki i może być obsłużona ponownie.
W ostatnim wpisie stworzyliśmy prostego producenta oraz konsumenta wiadomości. Wszystko działało prawidłowo, jednak nasze aplikacje były bardzo proste oraz ich działanie nie było uzależnione od żadnych aplikacji zewnętrznych, co nie zawsze będzie prawdą.
W tym wpisie zajmę się dokładniejszym omówieniem poszczególnych elementów systemu kolejkowania, a na pierwszy ogień idą centrale wiadomości (ang. exchange). Otóż niezależnie od języka programowania w jakim piszemy powinniśmy wiedzieć jak wygląda przetwarzanie danych przez Rabbit-a.
Prędzej czy później większość programistów spotyka się z potrzebą kolejkowania zadań. Czy to w przypadku rozsyłania newsletter-ów do klientów, czy też generowania czasochłonnych raportów, plików PDF oraz innych operacji wymagających dłuższego czasu oczekiwania użytkownika.
Ta witryna korzysta z plików cookie, aby polepszyć doświadczenie przeglądania i zapewnić dodatkową funkcjonalność. Żadne z podanych danych nie będzie mogło zostać użyte do identyfikacji lub kontaktu z Tobą.
Ta strona korzysta z plików cookie osób trzecich, szczegółowe informacje w polityce prywatności. Ta strona korzysta z śledzenia plików cookie, zobacz szczegółowe informacje na temat polityki prywatności.
Jeśli wolisz, możesz wybrać, jakie rodzaje plików cookie uważasz za akceptowalne:
Aby dowiedzieć się więcej o tym, jak ta witryna korzysta z plików cookie, przeczytaj POLITYKĘ PRYWATNOŚCI.
Klikając Zezwalaj wyrażasz zgodę, aby ta witryna przechowywała małe fragmenty danych w urządzeniu, z którego korzystasz.
Klikając Nie zezwalaj, lub przewijając stronę, nie wyrażasz zgody na przechowywanie jakichkolwiek plików cookie i danych lokacyjnych dla tej witryny, ostatecznie usuwając już zapisane pliki cookie (niektóre elementy witryny mogą przestać działać poprawnie).
Aby dowiedzieć się więcej na temat przechowywania plików cookie, odwiedź UODO.
Aby wyłączyć wszystkie pliki cookie za pośrednictwem przeglądarki, kliknij odpowiednią ikonę i postępuj zgodnie z instrukcjami.
Ta witryna korzysta z plików cookie, aby polepszyć doświadczenie przeglądania i zapewnić dodatkową funkcjonalność.
Więcej informacjiPolityka prywatności
Do tej pory wszystkie operacje wykonywaliśmy na jednej instancji RabbitMQ. Ma to kilka wady. Pierwsza i najważniejsza, to brak bezpieczeństwa. Co się stanie, gdy serwer RabbitMQ ulegnie awarii ?? Czy jesteś w stanie odzyskać dane z serwera, jak szybko jesteś w stanie uruchomić kolejną instancję ?? Wiele niewiadomych, a można sypiać spokojniej dzięki klastrowi.
W poprzednim wpisie z serii o RabbitMQ dowiedzieliśmy się jak poprawnie obsłużyć sytuację w której konsument z jakiegoś powodu nie poradził sobie z obsłużeniem wiadomości. Powodów może być wiele, ale nie to jest najważniejsze. Najważniejsze jest to, że wiadomość bezpiecznie wróciła do kolejki i może być obsłużona ponownie.
W ostatnim wpisie stworzyliśmy prostego producenta oraz konsumenta wiadomości. Wszystko działało prawidłowo, jednak nasze aplikacje były bardzo proste oraz ich działanie nie było uzależnione od żadnych aplikacji zewnętrznych, co nie zawsze będzie prawdą.
W tym wpisie zajmę się dokładniejszym omówieniem poszczególnych elementów systemu kolejkowania, a na pierwszy ogień idą centrale wiadomości (ang. exchange). Otóż niezależnie od języka programowania w jakim piszemy powinniśmy wiedzieć jak wygląda przetwarzanie danych przez Rabbit-a.
Prędzej czy później większość programistów spotyka się z potrzebą kolejkowania zadań. Czy to w przypadku rozsyłania newsletter-ów do klientów, czy też generowania czasochłonnych raportów, plików PDF oraz innych operacji wymagających dłuższego czasu oczekiwania użytkownika.