Kolejki wiadomości: RabbitMQ, Kafka

Kolejki wiadomości: RabbitMQ, Kafka

1) Kiedy wybrać

RabbitMQ (AMQP 0-9-1/1. 0, klasyczne kolejki, kolejki kworum, strumienie)

Nadaje się do: RPC/commands, workflow, krótkie zadania, fanout/topic routing, elastyczne potwierdzenia, kontrola priorytetów.
Plusy: bogate routing semantyki (wymiany), 'podstawowe. qos '(prefetch), per-message TTL/delay, wygodne wzory RPC (reply-to), łatwy start.
Minusy: Historia przechowywana w kolejce, skalowana poziomo w kolejkach/odłamkach; Wysoka przepustowość-koszt z bardzo dużymi przepływami.

Apache Kafka (dziennik wydarzeń, partie, grupy konsumentów)

Nadaje się do: strumieni wydarzeń, audytu, pozyskiwania zdarzeń, ETL/integracji (Connect), wysokiego RPS/MBp, powtórnego/ponownego przetwarzania, przetwarzania strumieniowego (Streams/ksqlDB).
Plusy: czasopismo długoterminowe, skalowanie przez strony, stabilna powtórka, zagęszczenie klucza.
Minusy: model pull + party - nie dla małych RPC; zarządzenie wyłącznie w ramach strony; Za zarządzanie schematem/interoperacyjność odpowiada zespół.

2) Semantyka dostawy i niezmienne

Najwyżej raz: brak przekaźników; szybko, ryzyko utraty.
Przynajmniej raz: z rekolekcjami; wymaga idempotencji konsumentów.
Dokładnie raz: osiągalne w ograniczonych warunkach (Kafka TX + producent idempotent + spójny zlewozmywak; RabbitMQ - poprzez tabelę deduplikacji/klucze idempotentne).
Zamówienie: RabbitMQ - kolejka kolejki (może być naruszona z retras/wielu konsumentów); Kafka - kolejność w partii, klucz ustawia partycjonowanie.

Niezmienne domeny: pieniądze/salda - poprzez czasopisma/sagi i zespoły idempotentne; nie polegaj na LWW.

3) Wzorce integracji

Outbox/InBox: atomowe nagrywanie zdarzenia w bazie danych → publikowanie do kolejki (outbox) i zużycie idempotent z dziennika przetwarzania (skrzynka odbiorcza).
DLQ (martwe litery): po N próby/błędy - w DLQ + alert.
Retry/Delay: RabbitMQ - TTL + wymiana martwych liter; Kafka - retry tematy z backoff.
Zapytanie/odpowiedź: RabbitMQ - 'reply _ to' + 'correlation _ id'; Kafka - rzadko, tylko ze specjalnymi wzorami.
Rekompensaty: sagi za wydarzenia; każda operacja ma odwrotność.

4) Projekt klucza i topologii

RabbitMQ

Wymiana: 'bezpośredni', 'temat', 'fanout', 'nagłówki'.
Klucz routingu: Określa trafienie kolejki. Do ustalania priorytetów - oddzielne kolejki.
QoS: „prefetch” (np. 50-300) stopa salda/opóźnienie.
Kolejki kworum: replikowane kolejki na tratwie; wymiana lustrzane klasyczne.
Strumienie: strumień z offsetami (Kafka-like) dla wysokiej przepustowości/powtórki.

Kafka

Temat → partycje: plan '# partycje' o przepustowości docelowej i równoległości (wsteczny kompatybilny wzrost jest łatwiejszy niż spadek).
Klucz: wszystkie zapisy jednego klucza - w jednej części (gwarancja zamówienia według klucza).
Współczynnik replikacji: 3 dla tematów produkcyjnych ", min. insync. repliki = 2 '+' acks = all 'dla niezawodności.
Zatrzymanie: według czasu/rozmiaru; zagęszczenie - przechowuje ostatnie wartości przez klucz + nagrobki do usunięcia.

5) Retrai, DLQ, idempotencja

RabbitMQ

Powtarza: per-message TTL + DLX (wymiana martwych liter) z backoff (na przykład, 1m → 5m → 15m).
Idempotence: 'correlation _ id'/' message-id' + processed message table (TTL) lub deterministic commands.
Potwierdzenia: ręczne 'basic. ack „po udanej transakcji;” podstawowe. nack (requeue = false) 'верка КА.

Kafka

Powtórzenia: indywidualne tematy retry; konsument dokonuje offsetu po udanym skutku ubocznym.
Dokładnie raz przetwarzania (EOS): Producent 'enable. idempotencja = true ', producent/konsument transakcji, „read _ committed” na konsumenta; sink (na przykład, Kafka → Kafka lub Kafka → DB poprzez transakcję) - starannie synchronizować.
Dedup: kluczem/kluczem idempotentnym po stronie podstawy lub poprzez skompresowany temat.

6) Wydajność i wymiar

Prawo małego: 'L = α × W'

W przypadku vorkera: wymagane nakładanie się na siebie 'N' arrival_rate × avg_processing_time × stado (1. 2–1. 5)`.
Prefetch RabbitMQ: Rozpocząć od 'prefetch = 100' i zmierzyć czas lotu p99/.
Partycje Kafka: obliczenia z pożądanego równoległości konsumenta i celu przepustowości (na przykład, 1 partia jest stabilna 5-20 MB/s na SSD/10GbE).

7) Obserwowalność i wpisy

• Lag/Backlog (wiadomości/bajty), wiek wiadomości (p95/p99), wskaźnik błędów przetwarzania, wskaźnik DLQ.
• Czas „publikatsiya → obrabotka” (end-to-end).
• Mapa zależności: producent → broker → konsument.

• Połączenia, kanały, wiadomości niepakowane, 'memory _ alarm',' disk _ free _ limit ',' queue length 'p95.
• Raporty na Quorum (lider, dziennik tratwy, brakuje 'kworum za mało').

• Słabo replikowane partycje, ISR shrink/expand, zmiany kontrolera.
• Błędy producenta (timeouts, „request latency”), opóźnienie konsumenckie na grupę/partycję.
• Broker I/O, cache hit strony, GC, ZooKeeper/KRaft zdrowia.

8) Bezpieczeństwo i wielopoziomowość

Szyfrowanie tranzytowe TLS (SASL/PLAIN/SCRAM/OAuth, mTLS).
Autoryzacja: vhost/uprawnienia (RabbitMQ), ACL do tematów/grup (Kafka).
Kwoty: dla połączeń, kanałów, rozmiaru kolejki/tematu, prędkości publikacji/czytania.
Izolacja według środowisk (dev/stage/prod) i przestrzeni nazw/vhost.

9) Eksploatacja i dostrajanie

RabbitMQ

Giełdy/kolejki pocztowe do węzłów (kapitał CPU/IO).
Leniwe kolejki (wiadomości na dysk) do dużych buforów; unikać „gorących” kolejek bez strzyżenia.
Kolejki kworum dla HA; Planuj rozmiar dziennika tratwy i dysk.
Polityka TTL/limit długości, kolejki priorytetowe tylko dla rzeczywistej potrzeby (drogie).

bash rabbitmqctl set_policy DLX "^task\." \
'{"dead-letter-exchange":"dlx","message-ttl":60000,"max-length":100000}' --apply-to queues

Kafka

SSD/NVMe, szybkie sieci; Dostrajanie systemu operacyjnego (wymiana niska, granice plików).
'acks = all', 'linger. ms '(butching), "compression. typ = zstd'/lz4 dla szerokości pasma.
Opcje dla konsumentów: "max. sondaż. odstęp czasu. ms ',' max. sondaż. rekordy „,” pobierz. min. bajty ".
Retencja i zagęszczenie - bilans przechowywania/powtórka.

java props. put("acks","all");
props. put("enable. idempotence", "true");
props. put("max. in. flight. requests. per. connection","1");
props. put("retries","10");

10) Integracja i ekosystem

Kafka Connect (Sinks/Sources), Schema Registry (Avro/JSON/Protobuf) i interoperacyjności („BACKWARD/FORWARD/FULL”).
Kafka Streams/ksqlDB: stacjonarne operacje, okna, agregaty.
RabbitMQ łopata/Federacja: transfer między klastrami/centrami.
operatorzy K8s: Strimzi (Kafka), RabbitMQ Cluster Operator; Manifesty GitOps.

11) Lista kontrolna wdrażania (0-45 dni)

0-10 dni

Zdefiniuj przypadki użycia: polecenia/zadania (RabbitMQ), zdarzenia/audyty (Kafka).
Wybierz klucze ('routing key '/' partition key'), ustaw SLO 'publatsiya → obrabotka'.
Podstawowe zasady bezpieczeństwa (TLS, ACL), kwoty, DLQ/TTL.

11-25 dni

Wdrożenie skrzynki odbiorczej/skrzynki odbiorczej, idempotencji i deadup.
Skonfiguruj retreas z backoff (Królik: TTL + DLX; Kafka: retry tematy).
Deski rozdzielcze: opóźnienie, wiek, prędkość DLQ, opóźnienie końcowe; wpisy.

26-45 dni

Szerokość pasma strojenia: prefetch/acks (Królik); przegrody/akry/partia (Kafka).
Procedury DR (lusterko/replikacja), testy awarii węzła.
Dokumenty dotyczące umów o zdarzenia (schematy) i polityki interoperacyjności.

12) Anty-wzory

Jedno „uniwersalne” narzędzie do wszystkich zadań.
Brak DLQ/TTL: wieczne trucizny (trucizny).
Nieograniczony „prefetch” → głód konsumentów, wzrost p99.
Kafka bez kluczy → utrata zamówienia/gorące strony domyślnie.
„Dokładnie raz”, bez prawdziwej potrzeby/dyscypliny, to fałszywe poczucie bezpieczeństwa.
Sekrety/loginy w kodzie, bez TLS/ACL.
Hardcode schematów/wersji wiadomości bez rejestru i migracji.

13) Wskaźniki zapadalności

Lag/wiek SLO jest wykonywany ≥ 99% czasu; Wskaźnik DLQ pod kontrolą.
Idempotencja obejmuje 100% ścieżek krytycznych; zaimplementowana skrzynka odbiorcza/skrzynka odbiorcza.
Zatrzymanie/zagęszczenie są udokumentowane, powtórka nie łamie konsumentów.
Ustawione są wpisy dotyczące limitów ISR/URP (Kafka) i tratwy/dysku (Królik).
Kontrakty na zdarzenia są wersjonowane (Schema Registry), zgodność jest testowana w CI.
Regularne dni gry: węzeł/broker/awaria AZ, kontrola odzyskiwania.

14) Przykłady konfiguracji (streszczenie)

python channel. basic_qos(prefetch_count=200)
for msg in consume("tasks"):
try:
handle(msg)
channel. basic_ack(msg. delivery_tag)
except Transient:
channel. basic_nack(msg. delivery_tag, request = False) # will go to DLQ

java props. put("enable. auto. commit","false");
props. put("isolation. level","read_committed"); // при EOS
//...
poll -> process(idempotent) -> commitSync()

15) Wniosek

RabbitMQ i Kafka rozwiązują różne klasy problemów: polecenia/zadania i bogate routing na podstawie długofalowego dziennika zdarzeń i skalowalnego przesyłania strumieniowego. Sukces - we właściwej semantyce dostawy, dyscyplinie idempotencji, przemyślanego klucza, retras/DLQ, obserwowalności i ścisłego bezpieczeństwa. Budowanie praktyk inżynieryjnych wokół kolejek - outbox/skrzynka odbiorcza, schematy i polityki GitOps - a Twoja integracja staje się przewidywalna, skalowalna i zrównoważona.