Message broker w Pythonie - RabbitMQ, Kafka czy NATS?

Gdy aplikacja ma obsłużyć płatność, wysłać e-mail i zaktualizować magazyn, wykonywanie wszystkiego w jednym żądaniu szybko staje się źródłem opóźnień i awarii. Message broker oddziela nadawcę od odbiorcy, przechowuje komunikaty i pomaga bezpiecznie przekazywać je między usługami. Wyjaśnię, jak działa taki pośrednik, kiedy ma sens, czym różnią się RabbitMQ, Kafka i NATS oraz jak podejść do wdrożenia w projekcie Pythonowym.

Jak działa broker komunikatów w praktyce

Najprostszy przepływ wygląda tak: producent publikuje komunikat, pośrednik przyjmuje go i przekazuje konsumentowi. Producent nie musi znać adresu usługi odbierającej ani wiedzieć, czy ta usługa chwilowo nie działa. To właśnie daje luźne powiązanie między komponentami.

Komunikat może zawierać dane biznesowe, na przykład identyfikator zamówienia i kwotę, albo polecenie wykonania zadania. Broker może go przechować, przekierować do właściwej kolejki, ponowić dostarczenie po błędzie i zarejestrować potwierdzenie odbioru.

Producent, broker i konsument

• Producent tworzy i wysyła komunikat.
• Broker odpowiada za routing, kolejki, trwałość i kontrolę dostarczania.
• Konsument pobiera komunikaty i wykonuje pracę.

W systemie e-commerce producentem może być API przyjmujące zamówienie, a konsumentem usługa generująca fakturę. API zwraca odpowiedź użytkownikowi od razu, natomiast faktura powstaje asynchronicznie. Dla klienta oznacza to krótszy czas odpowiedzi, a dla zespołu mniejsze ryzyko, że awaria jednego modułu zatrzyma cały proces.

Kolejka a publikacja-subskrypcja

W modelu kolejki wielu konsumentów tworzy grupę pracowników. Każdy komunikat trafia zwykle do jednego z nich, więc łatwo rozdzielać obciążenie. To dobry wybór dla wysyłki wiadomości e-mail, przetwarzania obrazów albo generowania raportów.

W modelu publish-subscribe jedno zdarzenie może otrzymać wiele niezależnych usług. Zdarzenie „zamówienie utworzone” może więc jednocześnie uruchomić płatność, aktualizację magazynu i wysłanie powiadomienia. Każdy odbiorca ma własną subskrypcję i może przetwarzać dane w swoim tempie.

Kiedy takie rozwiązanie naprawdę pomaga

Nie dodaję brokera do małej aplikacji tylko dlatego, że mikroserwisy są modne. Dodatkowa infrastruktura ma sens wtedy, gdy potrzebuję asynchroniczności, odporności albo skalowania, a nie wtedy, gdy zwykłe wywołanie HTTP rozwiązuje problem bez komplikacji.

Zadania wykonywane w tle

Przydatnym przykładem jest aplikacja Pythonowa, która po zakupie musi wysłać e-mail, stworzyć miniatury zdjęć i zaktualizować dane analityczne. Zamiast wykonywać te operacje w żądaniu HTTP, zapisuję zadania w kolejce i obsługuję je osobnymi workerami.

Jeżeli generowanie miniatur trwa kilka sekund, użytkownik nie powinien czekać na zakończenie całego procesu. Broker pozwala też uruchomić trzech lub dziesięciu workerów, gdy liczba zadań rośnie, bez zmiany kodu odpowiedzialnego za przyjmowanie żądań.

Komunikacja mikroserwisów

Usługi mogą wymieniać zdarzenia zamiast wywoływać się bezpośrednio. Dzięki temu zmiana adresu, języka programowania albo sposobu wdrożenia jednej usługi nie musi wymuszać zmian we wszystkich pozostałych.

Trzeba jednak uważać na spójność danych. Komunikacja asynchroniczna oznacza, że przez pewien czas jedna usługa może widzieć zamówienie, a druga jeszcze nie. To model spójności ostatecznej, który wymaga poprawnej obsługi stanów pośrednich.

Integracja z systemami zewnętrznymi

Broker dobrze izoluje system od zawodnych API dostawców. Jeśli zewnętrzna usługa odpowiada błędem lub ma przerwę techniczną, komunikat może poczekać na ponowienie zamiast zniknąć razem z żądaniem użytkownika.

Nie rozwiązuje to jednak wszystkich problemów. Dla każdego komunikatu trzeba ustalić limit prób, czas między próbami oraz sposób obsługi błędu trwałego, na przykład niepoprawnego numeru faktury.

RabbitMQ, Kafka czy NATS

Najczęstszy błąd przy wyborze polega na porównywaniu samych nazw. Najpierw określam, czy system ma obsługiwać zadania, czy raczej długotrwały strumień zdarzeń, który będzie odczytywany ponownie przez wiele zespołów.

RabbitMQ wybieram wtedy, gdy komunikat jest przede wszystkim zadaniem do wykonania. W jego modelu wymiana kieruje wiadomości do kolejek, a potwierdzenie konsumenta pozwala kontrolować, czy praca została zakończona.

Kafka przypomina rozproszony dziennik zdarzeń. Temat dzieli się na partycje, a kolejność jest gwarantowana w obrębie pojedynczej partycji. Grupa konsumentów może wspólnie przetwarzać dane, a inna grupa niezależnie odczytać tę samą historię.

NATS jest atrakcyjny tam, gdzie liczy się prostota i szybkość komunikacji. Wariant podstawowy jest ulotny, natomiast JetStream dodaje przechowywanie, ponowne dostarczanie oraz trwałych konsumentów. To ważne rozróżnienie, bo sama obecność NATS nie oznacza jeszcze bezpiecznej archiwizacji komunikatów.

Jak nie zgubić komunikatu

Sam fakt, że broker przyjął wiadomość, nie oznacza, że biznesowa operacja zakończyła się sukcesem. Projektuję osobno potwierdzenie publikacji, potwierdzenie przetworzenia i reakcję na błąd konsumenta.

Semantyka dostarczania

Tryb at most once oznacza najwyżej jedno dostarczenie. Jest szybki, ale awaria może spowodować utratę wiadomości. At least once zwiększa bezpieczeństwo, lecz ten sam komunikat może pojawić się więcej niż raz.

W praktycznych systemach najczęściej wybieram at least once oraz idempotencję. Idempotentny konsument potrafi bezpiecznie wykonać tę samą operację ponownie, na przykład dzięki unikalnemu identyfikatorowi zdarzenia zapisanemu w bazie.

Retry i kolejka błędów

Nie każdy błąd powinien uruchamiać natychmiastowe ponowienie. Chwilowy timeout uzasadnia retry, ale błędny format danych będzie tylko obciążał system. Stosuję zwykle rosnące odstępy między próbami, na przykład 10 sekund, 1 minutę i 5 minut.

Po 3-5 nieudanych próbach komunikat powinien trafić do dead-letter queue, czyli kolejki błędów. Operator może go tam przeanalizować, poprawić przyczynę i wznowić przetwarzanie bez ręcznego odtwarzania całego procesu.

Przeczytaj również: Architektura Multi Tenant - Jak uniknąć błędów i skalować SaaS?

Kolejność i duplikaty

Jeśli kolejność zdarzeń ma znaczenie, trzeba wskazać klucz partycjonowania albo ograniczyć równoległość konsumentów. W systemie płatności zdarzenie „zwrot wykonany” nie może zostać logicznie obsłużone przed zdarzeniem „płatność zaksięgowana”.

Nie zakładam też, że broker zagwarantuje pełne exactly once w całym procesie biznesowym. Nawet gdy transport obsługuje deduplikację, zapis do bazy i wysłanie kolejnego komunikatu mogą wymagać wzorca outbox lub transakcji lokalnej.

Prosty model wdrożenia w Pythonie

W aplikacji Pythonowej rozdzielam kod producenta od workera. Producent publikuje mały komunikat z identyfikatorem zadania, a worker pobiera dane potrzebne do wykonania pracy. Nie przesyłam przez kolejkę dużych plików ani całych rekordów, jeśli wystarczy identyfikator i wersja obiektu.

import json
import pika

connection = pika.BlockingConnection(
    pika.ConnectionParameters("localhost")
)
channel = connection.channel()

channel.queue_declare(queue="emails", durable=True)

event = {
    "event_id": "order-123-email",
    "order_id": 123,
    "template": "order-confirmed"
}

channel.basic_publish(
    exchange="",
    routing_key="emails",
    body=json.dumps(event),
    properties=pika.BasicProperties(
        delivery_mode=2,
        content_type="application/json"
    )
)

connection.close()

Parametr delivery_mode=2 oznacza komunikat trwały, ale to jeszcze nie daje pełnej gwarancji. Trwała musi być również kolejka, a środowisko produkcyjne powinno korzystać z odpowiednio skonfigurowanego klastra i kopii zapasowych.

Worker powinien potwierdzić komunikat dopiero po zakończeniu operacji. Jeśli potwierdzi go przed zapisem w bazie, awaria procesu może sprawić, że zadanie zniknie bez efektu. Z drugiej strony brak potwierdzenia po sukcesie może wywołać duplikat, dlatego operacja musi być odporna na powtórzenie.

Co monitorować w środowisku DevOps

Broker nie powinien być czarną skrzynką. Najbardziej użyteczne metryki to liczba oczekujących komunikatów, wiek najstarszego komunikatu, czas przetwarzania, liczba ponowień i liczba wiadomości w kolejce błędów.

Sama długość kolejki bywa myląca. Sto tysięcy krótkich zadań może być mniej groźne niż dziesięć komunikatów, które czekają już godzinę. Dlatego alarm ustawiam przede wszystkim względem SLA i wieku wiadomości, a nie jednej uniwersalnej liczby.

W logach zapisuję identyfikator komunikatu, identyfikator korelacji i nazwę wersji kontraktu. Do śledzenia przepływu między usługami przydaje się tracing rozproszony, natomiast dane w komunikatach powinny być pozbawione haseł, tokenów i zbędnych informacji osobowych.

Wdrożenie produkcyjne wymaga również kontroli dostępu, szyfrowania połączeń, limitów rozmiaru wiadomości oraz planu awaryjnego. Testuję nie tylko scenariusz sukcesu, ale też restart brokera, utratę workera, opóźnienie konsumenta i ponowne przetworzenie tego samego zdarzenia.

Najlepszy wybór zaczyna się od rodzaju komunikatu

Dla zadań typu „wyślij e-mail”, „wygeneruj raport” albo „przelicz miniaturę” zacząłbym od rozwiązania kolejkowego, najczęściej RabbitMQ lub usługi zarządzanej przez dostawcę chmury. Dla dużego strumienia zdarzeń z potrzebą odczytu historii lepiej pasuje Kafka, a dla szybkiej komunikacji między lekkimi usługami warto rozważyć NATS z JetStream.

Przed wyborem spisałbym pięć rzeczy: oczekiwaną liczbę komunikatów na sekundę, dopuszczalne opóźnienie, wymagany czas przechowywania, potrzebę ponownego odczytu oraz sposób obsługi duplikatów. Dobry broker nie naprawi źle zaprojektowanego kontraktu zdarzenia, dlatego równie ważne są idempotencja, monitoring i procedura obsługi błędów.

W małym projekcie zacząłbym od jednego konkretnego przypadku i prostego workera, a dopiero później dodawał kolejne kolejki, routing i replikację. Taka ewolucja zwykle daje więcej niż przedwczesne budowanie rozbudowanej platformy komunikacyjnej.