Kolejki wiadomości: Kafka i RabbitMQ

Kolejki wiadomości: Kafka, RabbitMQ

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

• Apache Kafka to rozproszony dziennik zdarzeń (log) skupiony na strumieniowaniu, replikacji i skalowaniu poziomym przez strony.
• RabbitMQ jest brokerem kolejki AMQP z elastycznym routingiem (wymiana/wiązania), priorytetami, TTL, potwierdzeniami i klasycznymi zadaniami kolejki.

Oba narzędzia są dojrzałe, ale rozwiązują różne problemy: Kafka - dla skalowalnych strumieni i analityki, RabbitMQ - dla orkiestry zadań operacyjnych, RPC i różnorodnego routingu.

Gdzie jest to właściwe w iGaming

• Potrzebujemy dużych imprez TPS (zakłady, wydarzenia gry, telemetria) i skali poziomej przez strony.
• Ważne jest ponowne zużycie na zimno/na gorąco (dane z taśmy do ponownego odczytu), zatrzymywanie i zagęszczanie agregatów (równowaga, stan gracza).
• Potrzebujemy procesów strumieniowych (Kafka Streams/ksqlDB/Flink) dla agregatów w czasie rzeczywistym: liderów turniejów, limitów odpowiedzialnej gry, sygnałów przeciwdziałania oszustwom.

• Potrzebujemy klasycznych kolejek zadań: sprawdzenie KYC, odroczone/powtarzające się płatności, wysyłanie wiadomości e-mail/SMS/push, haki internetowe do PSP.
• Elastyczne routing (temat/bezpośredni/fanout), priorytety, TTL, opóźnienie, martwe litery i wzory RPC.
• Wymagane są ścisłe ograniczenia na jednego konsumenta (prefetch/QoS), proste zarządzanie obciążeniem i szybkie przekaźniki.

Częsty wynik: Kafka na imprezy i analizy + RabbitMQ na orkiestrę i integracje.

Model danych i routing

Kafka

Tematy są → podzielone na strony, każdy jest uporządkowany dziennik.
Klucz wiadomości określa partię → zamawianie w ramach klucza.
Konsumenci czytają offset, grupy konsumentów przetwarzania skali.
Retencja według czasu/objętości; zagęszczenie dziennika przechowuje najnowszą wersję klucza.

RabbitMQ

Wymiana (direct/fanout/topic/headers) + bindings → wiadomości dostać się do kolejek.
Potwierdzenia (ack/nack/request), potwierdza wydawca, priorytety, TTL, dead-letter (DLX/DLQ).
Kolejki kworum (tratwa) dla wysokiej dostępności; leniwe kolejki do zapisania pamięci RAM.

Gwarancje dostawy i idempotencja

Najwyżej raz: brak przekaźników; ryzyko utraty, minimalne opóźnienie.
Co najmniej raz: domyślny standard → duplikaty → idempotent handlers (request/transaction key, upsert, dedup table, outbox) są możliwe.
Dokładnie raz: w Kafce, idempotent producent + tematy transakcji + uzgodniona konsumpcja jest osiągnięta w połączeniu, ale częściej jest to droższe i trudniejsze; w RabbitMQ - ograniczone i z kościami. W rzeczywistych przepływach płatności/zakładów stosuje się co najmniej raz + ścisłą idempotencję.

• Unikalne klucze idempotencji (UUID/ULID) na zdarzenie/polecenie.
• Wzorzec skrzynki zewnętrznej w bazie danych usługi + Zmiana przechwytywania danych (Debezium) → zapobieganie podwójnemu zapisowi.
• Dedup przez (klucz, created_at) w oddzielnym wierszu z TTL.

Zamówienie/Zamówienie wiadomości

Kafka gwarantuje zamówienie w ramach strony. Wybierz klucz, aby całe „życie” jednostki (na przykład 'player _ id' dla równowagi) znajdowało się w jednym kluczu.
Zamówienie RabbitMQ nie jest ściśle gwarantowane z wielokrotnych dostaw/wielu konsumentów; rurociągi o kluczowym znaczeniu dla porządku - lepiej w Kafce lub poprzez jednorazową aktywną serializację konsumentów i strumieni.

Projektowanie tematów i kolejek

• Ziarnistość: 'domena. zdarzenie „(na przykład,” płatności. depozyt. stworzony ").
• Klucze: 'player _ id',' account _ id', 'bet _ id' do zamawiania.
• Partie = N według docelowego TPS (reguła: 1 partia zapasy dla wzrostu.
• Zatrzymanie: zdarzenia - godziny/dni; zagęszczenie - dla „stanów”.

• Wymiana według domeny: 'płatności. bezpośrednie „,” ryzyko. temat ".
• Kolejki dla konsumentów: "kyc. checker. q ',' psp. webhooks. ponowna próba. q '.
• DLQ na kolejkę roboczą opóźnienie dla backoff.
• Prefetch określa równoległość, kolejki kworum dla HA.

Błędy, Przekłady i DLQ

Klasyfikuj błędy: tymczasowe (sieć/PSP 5xx) → przekładki; śmiertelne (walidacja, schemat) → natychmiast DLQ.
Wykładniczy backoff + jitter, limit retray, wykrywanie tabletek trujących.
Oddzielne kolejki powrotne krok po kroku (5s, 1m, 5m, 1h).
Obsługa DLQ: alert, ślad, ręczne parsowanie, ponowne wstrzyknięcie za pomocą plastra.

Kontrakt na dane i schematy

Użyj Avro/Protobuf + Schema Registry (dla Kafka - de facto standard).
Wersioning: zmiany kompatybilne z wstecznym (dodawanie pól opcjonalnych), zakaz łamania migracji.
Pola PII - szyfrowanie/tokenizacja; są zgodne z RODO i przepisami lokalnymi.

Monitorowanie, obserwowalność i SLO

Wskaźniki producentów/konsumentów: opóźnienie, przepustowość, błędy, retrai, czas przetwarzania.
Logs + odwzorowanie (identyfikator korelacji: 'trace _ id',' message _ id').
SLO: p99-latency of publication/delivery, permissible consumer lag, recovery time after files.
Alerty dla wzrostu DLQ, opóźnienie nadmiaru, spadek partii/kworum.

Bezpieczeństwo i zgodność

TLS w tranzycie, tajne szyfrowanie (SOPS/Vault), ograniczony ACL/RBAC.
Oddzielne tematy/kolejki dla wrażliwych domen (płatności, KYC).
Dziennik audytu publikacji/subskrypcji, przechowywanie kluczy poza kodem.
Wymagania regionalne (UE/Turcja/LatAm): zatrzymywanie, lokalizacja magazynu, maskowanie.

Wysoka dostępność, tolerancja błędów i DR

• Klaster co najmniej 3-5 maklerów; replikacja. czynnik ≥ 3.
• min. insync. repliki i acki = wszystkie dla trwałych rekordów.
• Replikacja krzyżowa (MirrorMaker-2) dla DR.

• Kolejki kworum dla HA, równomierna/nieparzysta liczba węzłów z kworum.
• Federacja/łopata do replikacji między centrami danych, skrypty DR.
• Zimne/ciepłe stanowisko, testy przełączania.

Wydajność i dostrajanie

• 'linger. Partia ms 'ва'. rozmiar „do masła;” kompresja. typ "(lz4/zstd).
• „ack = wszystkie”, ale uważaj na opóźnienia; tune 'max. w. lot. wniosków. per. połączenie "z idempotencją.

• Wystarczająco dużo imprez; NVMe napędza sieć 10/25G; Ustawienia JVM GC.

• Prawidłowe zarządzanie grupą ", max. sondaż. odstęp czasu. ", zatrzymać strony na backoff.

• Wydawca potwierdza w masle; kanały ponownego wykorzystania.

• „prefetch” (np. 50-300) według czasu leczenia; leniwe kolejki do dużych zaległości.
• Post gorące kolejki do węzłów; Deskryptory TCP.

Typowe wzory dla iGaming

Outbox + Kafka do rzetelnej publikacji zdarzeń domenowych (zakład, depozyt).
RabbitMQ RPC dla synchronicznych żądań integracji (kontrola dokumentów KYC, obliczanie rabatów).
Wzór sagi: orkiestra poprzez wydarzenia (Kafka) i zespoły (RabbitMQ) z wyrównawczym krokiem.
Powiadomienia fan-out: z jednego zdarzenia → CRM, anti-fraud, analytics.
Inteligentne haki PSP z progresywnymi opóźnieniami i DLQ.

Architektury migracyjne i hybrydowe

Zacznij od RabbitMQ dla „systemu operacyjnego”, dodaj Kafka dla wydarzeń i analityki.
Duplikat publikacji: usługa → outbox → złącze w obu kierunkach (Kafka + RabbitMQ) aż do całkowitej stabilizacji.
Stopniowo migruj abonentów analityki/agregacji strumieni do strumieni Kafka/ksqlDB.

Lista kontrolna Mini Selection

1. Ładowanie/TPS> dziesiątki tysięcy/sek? → Kafka.
2. Potrzebujesz retencji i ponownego czytania jak z magazynu? → Kafka.
3. Elastyczny routing, priorytety, opóźniona dostawa, RPC? → RabbitMQ.
4. Ścisły porządek klucza i skali poziomej → Kafka (klucz/strony).
5. Proste zadania/work-kew z kontrolą współzależności → RabbitMQ.
6. Idealnie, kombinacja: Kafka (wydarzenia) + RabbitMQ (orkiestra).

Przykłady minimalnych konfiguracji

Przykład: opóźniony retrai i DLQ w RabbitMQ (poprzez politykę)

Kolejka robocza: 'psp. webhooks. q "

Kolejka retras: 'psp. webhooks. ponowna próba. 1m. q '(TTL = 60s, punkty DLX powrót do działania)

DLQ: 'psp. webhooks. dlq "

• 'psp. webhooks. q '→' x-dead-letter-exchange = psp. ponowna próba. wymiana "
• 'psp. webhooks. ponowna próba. 1m. q '→' x-message-ttl = 60000 ',' x-dead-letter-exchange = psp. praca. wymiana "
• 'psp. webhooks. dlq '→ monitorowanie i ręczne debugowanie.

Przykład: Temat zakładów Kafka

Temat: zakłady. umieszczone. v1 ', strony: 24, RF = 3, zatrzymanie 7 dni.
Klucz wiadomości to 'player _ id' lub' bet _ id' (wybierz, który jest ważniejszy dla zamówienia).
Сбема: Protobuf/Avro, 'bet _ id',' player _ id', 'stake', 'odds', 'ts',' idempotency _ key '.

Testowanie i jakość

Producent testów kontraktowych/konsument + Rejestr Schematu.
Testy chaosu: krople do węzłów, opóźnienia w sieci, podział mózgu.
Obciążenie działa z docelowym TPS, p99 sprawdzić, opóźnić wzrost i odzysku.

Podsumowanie

Kafka - autostrada imprezowa i streaming: zamawianie kluczy, retencja/kompresja, wysoki TPS, analityka w czasie rzeczywistym.
RabbitMQ - kolejka zadań operacyjnych: elastyczne routing, potwierdzenia, priorytety, retray/DLQ, RPC.
W iGaming najlepszą praktyką jest stosowanie komplementarne: wydarzenia i analityka w Kafce, zadania integracyjne/orkiestrowe w RabbitMQ, z jednolitymi standardami schematu, idempotencja, monitorowanie i ścisłe SLO.