Broker wiadomości i Routing wydarzeń

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

Message Broker to podstawowa warstwa integracji i autobusu eventowego w iGaming. Realizuje dostarczanie, buforowanie i routing wiadomości między mikroservice stawek, płatności, przeciwdziałanie oszustwom, KYC, CRM i analityki. Dobrze zaprojektowane giełdy (giełdy), kolejki, klucze routingowe i zasady ponownego dostarczania zapewniają niskie opóźnienia, odporność na wybuchy ruchu i przewidywalne SLO.

Rola brokera w platformie iGaming

Usługi oddzielenia od produkcji: publikowanie wydarzeń zamiast twardych połączeń synchronicznych.
Elastyczne routing: jedno wydarzenie → wielu konsumentów (CRM, ryzyko, analityka).
Zarządzanie obciążeniem: kolejki, prefetch/QoS, backprescher.
Niezawodność i odzyskiwanie: potwierdzenia, przekłady, DLQ, replikacja.
Audyt i zgodność: śledzenie zdarzeń, maskowanie PII, polityka zatrzymywania.

Modele wiadomości

Punkt-punkt (kolejka zadań): jeden konsument przetwarza zadanie (KYC, e-mail, PSP webhook).
Pub/Sub (wydarzenia domeny): publikacja do wymiennika z wentylatorem na kilka kolejek.
RPC za pośrednictwem brokera: żądanie/odpowiedź z korelacją (rzadko na gorących ścieżkach, ale przydatne do integracji).

Routing Concepts (AMQP Classics)

1. direct - dokładne dopasowanie 'routing _ key'.

2. temat - szablony'a. b. c 'c' (jedno słowo) i' # '(0 + słowa). Uniwersalny wybór.

3. fanout - transmisja do wszystkich powiązanych kolejek.

4. nagłówki - routing nagłówka (klucz/wartość), przydatne dla złożonych polityk.

• "wypłaty. psp. pasek. udało się „,” płatności. psp.. nieudane ',' zakłady. na żywo. # ',' rg. limit. naruszenie ".
• Wymienniki według domeny: 'płatności. temat ',' zakłady. temat „,” ryzyko. temat "; indywidualne - dla „platformowych” imprez systemowych. audyt ".

Kolejki i zasady

Kolejka robocza: konsumowana przez handlowców biznesowych.
Kolejki retry: z TTL (opóźnienie) i DLX dla wykładniczych kopii zapasowych (na przykład, '5s → 1m → 5m → 1h').
DLQ (Dead-Letter Kolejka): końcowy „zrzut” po wyczerpaniu retras.
Priorytety: dla zadań pilnych (wnioski> listy).
Leniwe/Kworum: leniwe - oszczędzanie pamięci RAM z dużymi zaległościami; kworum - oparte na konsensusie HA.

• "praca. q '→' x-dead-letter-exchange = retry. „ex”
• "ponowna próba. 1m. q '→' x-message-ttl = 60000 ',' x-dead-letter-exchange = praca. „ex”
• 'dlq. q "→ monitorowanie i ręczna rekultywacja

Gwarancje i procedury dostawy

Co najmniej raz - domyślnie: możliwe są duplikaty → idempotencja jest obowiązkowa.
Najwyższy czas - minimalne opóźnienie, ale ryzyko utraty (dla sygnałów „nieistotnych”).
Dokładnie raz - rzadko praktyczne w brokerach; osiągnął trudniejsze i droższe. Za pieniądze: przynajmniej raz + twardy idempotencja.

• W jednej kolejce i z jednym konsumentem, zamówienie jest zachowane; z równoległości + retras, kolejność może być zakłócona.
• W przypadku podmiotów posiadających wymóg zamówienia serializuj strumień (pojedynczy aktywny konsument na klucz) lub przenoś go do autobusów „log” (streaming).

Idempotencja i publikacje transakcyjne

Idempotence-Key w wiadomości (ULID/UUID), dedup storage with TTL or upsert by key.
Wzorzec skrzynki zewnętrznej: pisanie zdarzenia do 'outbox 'w ramach transakcji biznesowej, łącznik publikuje brokerowi → wyklucza „podwójny wpis „/stratę.
Metadane korelacji: 'message _ id',' trace _ id', 'causation _ id',' lokator _ id'.

RPC za pośrednictwem brokera (w razie potrzeby)

Żądanie jest publikowane z "reply _ to" i "correlation _ id', odpowiedź jest w określonej kolejce.
Stosowanie ograniczone (zewnętrzni dostawcy, kontrole synchroniczne), kontrolowanie czasu i tendencji czatu (w przeciwnym razie - degradacja do rozproszonego monolitu).
W przypadku gorących ścieżek użytkownika preferowane są zdarzenia asynchroniczne + projekcje stanu.

Umowy i schematy danych

Formaty: Avro/Protobuf/JSON-Schema. Dla JSON, naprawić wersję i wymagane pola.
Polityka ewolucji: zmiany kompatybilne wstecz; łamanie zmian bez migracji jest zabronione.
PII - tokenizacja/szyfrowanie pól; cel i okres trwałości.

Obsługa błędów, Retray, DLQ

Klasyfikacja: tymczasowy (sieć/5xx) retray →; plik (walidacja/schemat) → DLQ.
Wykładniczy backoff + jitter, granica próby, etykiety z trucizną.
Opóźniona dostawa: za pośrednictwem TTL/Delayed-exchange.
Narzędzie „reinject to work” z DLQ po naprawie przyczyny.

Obserwowalność i SLO

Metryka producenta: prędkość publikacji, błędy/potwierdzenia.
Metryka kolejki: długość, szybkość zużycia, procent przekładni, czas kolejki p99.
Konsumenci: opóźnienie, przepustowość, czas przetwarzania, udział NACK.
SLO: p99 E2E opóźnienie dostawy zdarzenia ≤ X sekund; dostępność ≥ 99. 9%; Wskaźnik DLQ ≤ Y%.
Śledzenie: end-to-end 'trace _ id'/' span _ id', logi przez' message _ id'.
Alerts: wzrost DLQ/lags, spadek kworum, przepięcie NACK, etapy wsteczne.

Bezpieczeństwo i dostęp

TLS/MTLS w tranzycie; szyfrowanie na dysku podczas przechowywania trwałych kolejek.
RBAC/ACL: publish/consume rights by vhost/namespace/topic.
Segmentacja: domeny wrażliwe (płatności/CCM) - oddzielne wymienniki/klastry.
Tajemnice w skarbcu/SOPS; dziennik audytu publikacji/subskrypcji.
Lokalizacja danych: przechowywanie i przechowywanie według regionów (UE, Turcja, LatAm).

Wysoka dostępność i DR

Kolejki kworum/replikacja, nieparzysta liczba węzłów, anty-powinowactwo AZ.
Replikacja międzyregionalna (federacja/łopata) dla domen krytycznych.
Regulamin przełączania (runbook), okresowe ćwiczenia DR (dzień gry).
Topologie wersioning jako kod (IaC) - powtarzalne depozyty i szybki resync.

Wydajność i dostrajanie

Producent: wydawca potwierdza, kanał ponownego wykorzystania, asynchroniczne publikacje.
Kolejki: prefetch na średni czas trwania zadania; leniwe dla głębokich zaległości; rozdzielenie „gorących” kolejek przez węzły.
Sieć/system operacyjny: 10/25G, deskryptory plików, dostrajanie TCP. JVM/GC - dla profilu obciążenia.
Testy na obciążenia wybuchowe (mecze, turnieje, płatności szczytowe).

Typowe wzory routingu dla iGaming

1. Zdarzenia płatnicze (temat):

Wymiana: "płatności. temat "

• "wypłaty. psp. pasek. odniosła sukces "
• "wypłaty. psp.. failed "
• "withdrawal. poproszony. #`

• 'prowadzący. pisarz. q '(zobowiązanie: "płatności. #`)
• 'crm. wyzwalacze. q '(zobowiązanie: "płatności... sukces ")
• 'risk. recenzje. q '(wiązanie: "wycofanie. #`)

2. Punktacja przeciwpiechotna (bezpośrednia + ponowna próba):

'risk. praca. q „←” ryzyko. bezpośrednie „(” routing _ key = ryzyko. sprawdzić ")

'risk. ponowna próba. 1m. q '(TTL 60s → DLX powrót do' risk. bezpośrednie ")

'risk. dlq. q 'dla śmiertelnych.

3. Powiadomienia (fanout + priorytet):

"powiadomić. fanout '→' e-mail. q (prio) ',' sms. q ',' push. q "

Priorytety: wnioski/limity powyżej mailingów marketingowych.

4. Audyt i ślad (nagłówki):

Nagłówek bindings '{„najemca „: „X „, „krytyczny”:” true”} '→ oddzielna kolejka audytu.

Przykład systemu minimalnych wiadomości (JSON)

json
{
"message_id": "01HX8H8Y6D6W0T1S2A3B4C5D6E",
"trace_id": "f4d2a1...e9",
"occurred_at": "2025-11-05T11:20:45. 321Z",
"tenant_id": "eu-1",
"schema_version": 3,
"event": "payments. psp. stripe. succeeded",
"payload": {
"payment_id": "pay_123",
"player_id": "p_987",
"amount": { "currency": "EUR", "value": 50. 00 },
"psp_tx": "tx_456",
"idempotency_key": "ulid_..."
}
}

Integracja z innymi pętlami

Streaming/analytics: ważne tematy można powielać w magistrali dziennika (Kafka/Redpanda) do odciągania i regeneracji.
Fichestor: wydarzenia → funkcje online (Redis) i strony offline (Parkiet/OLAP).
Orkiestra sagi: polecenia poprzez bezpośredni/temat, wydarzenia - pub/sub; kroki kompensacyjne - jako oddzielne wiadomości.

Lista kontrolna implementacji

1. Zdefiniuj wymienniki domeny i standard klucza routingu.
2. Zaprojektuj pracę/retry/DLQ dla każdego krytycznego przepływu.
3. Włączanie potwierdzeń wydawcy, „prefetch”, priorytetów i opóźnień w razie potrzeby.
4. Wprowadź identyfikatory idempotence-key, outbox i correlation.
5. Zatwierdzanie schematów danych i zasad ewolucji.
6. Konfiguracja TLS/RBAC, segmentacja według domeny/lokatora.
7. Ustaw SLO i wpisy (lag, DLQ-rate, p99).
8. Przygotuj plan DR i zautomatyzowane topologie IaC.
9. Wykonaj badania obciążenia i chaosu.
10. Udokumentuj uruchomienie incydentu i ponownie wstrzyknij z DLQ.

Anty-wzory

Jeden „gigantyczny” wymiennik bez kluczowej dyscypliny; przypadkowe „jak trzeba” wiązania.
Brak retry/DLQ i mieszanie błędów czasowych/śmiertelnych.
Synchroniczny RPC over broker na gorących ścieżkach użytkownika.
Brak idempotencji i outbox → podwoje/utrata pieniędzy.
Przechowywanie PII w jasnym, udostępnianie publikować/zużywać dla wszystkich.

Podsumowanie

Dobrze zaprojektowany broker wiadomości to solidna arteria zdarzeń, w której routing jest przewidywalny i tolerancja błędów jest wbudowana na poziomie topologii. Użyj wymienników tematycznych, jednego standardu klucza, pracy/retry/DLQ dla każdego strumienia krytycznego, idempotencji i outbox, ścisłych SLO i obserwowalności. W tandemie z autobusem strumieniowym i projekcjami stanu, daje to platformie iGaming trwałą prędkość, przejrzystość i kontrolę nad złożonością w miarę wzrostu obciążenia.