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.