Message Broker ve Olay Yönlendirme

(Bölüm: Teknoloji ve Altyapı)

Kısa Özet

Message Broker, iGaming'de temel bir entegrasyon ve etkinlik veri yolu katmanıdır. Ücretlerin mikro servisleri, ödemeler, sahtekarlık önleme, KYC, CRM ve analizler arasında iletilerin iletilmesini, arabelleğe alınmasını ve yönlendirilmesini uygular. İyi tasarlanmış değişimler (exchange), kuyruklar, yönlendirme tuşları ve yeniden teslim kuralları düşük gecikme süresi, trafik patlamalarına karşı direnç ve öngörülebilir SLO'lar sağlar.

iGaming platformunda broker rolü

Ayırma hizmetleri: Sabit eşzamanlı çağrılar yerine olayları yayınlama.
Esnek yönlendirme: Bir olay - birçok tüketici (CRM, risk, analitik).
Yük yönetimi: kuyruklar, prefetch/QoS, backprescher.
Güvenilirlik ve kurtarma: onaylar, retrays, DLQ, replikasyon.
Denetim ve uyumluluk: olay izleme, PII maskeleme, saklama politikası.

Mesajlaşma Modelleri

Noktadan Noktaya (görev kuyruğu): Bir tüketici bir görevi işler (KYC, e-posta, PSP webhook).
Pub/Sub (domain events): Birkaç kuyruk için fan çıkışı ile eşanjöre yayın.
Komisyoncu aracılığıyla RPC: Korelasyon ile istek/yanıt (nadiren sıcak yollarda, ancak entegrasyonlar için yararlıdır).

Yönlendirme Kavramları (AMQP Classics)

1. Doğrudan - 'routing _ key'in tam eşleşmesi.

2. konu - şablonlar'a. b. c'c "(bir kelime) ve '#' (0 + kelime). Evrensel bir seçim.

3. fanout - tüm ilgili kuyruklara yayın.

4. üstbilgiler - başlık yönlendirme (anahtar/değer), karmaşık ilkeler için kullanışlıdır.

• 'ödemeler. psp. çizgili. Başarılı ',' ödemeler. psp.. başarısız oldu ',' bahisleri. Canlı yayın. # ',' rg. limit. İhlal.
• Alana göre eşanjörler: 'ödemeler. Konu ',' bahisler. Konu ',' risk. Konu '; bireysel - 'platform' sistem olayları için. Denetim '.

Kuyruklar ve Politikalar

İş kuyruğu: iş işleyicileri tarafından tüketilir.
Kuyrukları yeniden deneyin: TTL (gecikme) ve DLX ile üstel yedeklemeler için (örneğin, '5s> 1m - 5m> 1h').
DLQ (Dead-Letter Queue): Retraların tükenmesinden sonraki son "damper".
Öncelikler: acil görevler için (sonuçlar> mektuplar).
Lazy/Quorum: tembel - büyük birikimli RAM tasarrufu; Çoğunluk - konsensüs tabanlı HA.

• 'çalışmak. Q '-' x-dead-letter-exchange = retry. 'ext'
• 'yeniden deneyin. 1m. Q '-' x-message-tl = 60000 ',' x-dead-letter-exchange = work. 'ext'
• 'dlq. q '> İzleme ve manuel iyileştirme

Teslimat garantileri ve prosedürleri

En az bir kez - varsayılan: kopyalar mümkündür - idempotans zorunludur.
En fazla bir kez - minimum gecikme, ancak kayıp riski ("kritik olmayan" sinyaller için).
Tam olarak bir kez - brokerlerde nadiren pratik; daha zor ve daha pahalı elde edildi. Para için: en az bir kez + zor idempotence.

• Bir kuyrukta ve tek bir tüketiciyle, sipariş korunur; Paralellik + retraces ile sıra bozulabilir.
• Sipariş gereksinimi olan varlıklar için, akışı seri hale getirin (anahtar başına tek aktif tüketici) veya "günlük" veri yollarına (akış) aktarın.

Idempotency ve işlemsel yayıncılık

Bir mesajda Idempotency-Key (ULID/UUID), TTL ile tekilleştirme depolama veya anahtarla upsert.
Giden kutusu deseni: Bir ticari işlem içindeki 'giden kutusu 'tablosuna bir olay yazarken, bağlayıcı komisyoncuya yayınlar - "çift giriş "/kaybını hariç tutar.
Korelasyon meta verileri: 'message _ id', 'trace _ id', 'causation _ id', 'tenant _ id'.

Komisyoncu aracılığıyla RPC (gerektiğinde)

İstek 'reply _ to've' correlation _ id'ile yayınlanır, yanıt belirtilen kuyruktadır.
Sınırlı (harici sağlayıcılar, senkron kontroller), kontrol zaman aşımları ve sohbet eğilimi (aksi takdirde - dağıtılmış bir monolite bozunma) kullanın.
Sıcak kullanıcı yolları için asenkron olaylar + durum projeksiyonları tercih edilir.

Veri Sözleşmeleri ve Şemalar

Formatlar: Avro/Protobuf/JSON-Schema. JSON için, sürüm oluşturma ve gerekli alanları düzeltin.
Evrim politikası: Geriye dönük uyumlu değişim; Göçler olmadan değişiklikleri kırmak yasaktır.
PII - alanların tokenizasyonu/şifrelenmesi; Amaç ve raf ömrü.

Hata İşleme, Retray, DLQ

Sınıflandırma: geçici (ağ/5xx) yeniden ödeme; Dosya (doğrulama/şema) - DLQ.
Üstel geri dönüş + titreme, yeniden deneme sınırı, zehir hapı etiketleri.
Gecikmeli teslimat: TTL/Gecikmeli değişim yoluyla.
Araç, nedeni düzelttikten sonra DLQ'dan "işe iade" eder.

Gözlemlenebilirlik ve SLO

Üretici metrikleri: yayınlama hızı, hatalar/onaylar.
Kuyruk metrikleri: uzunluk, tüketim oranı, retrays yüzdesi, p99 kuyruk süresi.
Tüketiciler: gecikme, iş hacmi, işlem süresi, NACK payı.
SLO: p99 E2E X saniye ≤ olay tesliminin gecikmesi; kullanılabilirlik ≥ 99. 9%; DLQ oranı ≤ Y %.
İzleme: uçtan uca 'trace _ id'/' span _ id', 'message _ id'ile kaydeder.
Uyarılar: DLQ/geciken büyüme, çekirdek düşüşü, NACK dalgalanması, yeniden deneme aşamaları yapışıyor.

Güvenlik ve erişim

Transit TLS/MTLS; Kalıcı kuyruklar depolandığında diskte şifreleme.
RBAC/ACL: vhost/namespace/topic'e göre yayınlama/tüketme hakları.
Segmentasyon: hassas alanlar (ödemeler/CCM) - ayrı değiştiriciler/kümeler.
Vault/SOP Sırlar; Yayınların/aboneliklerin denetim günlüğü.
Veri yerelleştirme: Bölgelere göre depolama ve saklama (AB, Türkiye, LatAm).

Yüksek Kullanılabilirlik ve DR

Çekirdek kuyrukları/çoğaltma, tek sayıda düğüm, AZ anti-afinitesi.
Kritik alanlar için bölgeler arası çoğaltma (federasyon/kürek).
Anahtarlama düzenlemeleri (runbook), periyodik DR egzersizleri (oyun günü).
Topolojileri kod (IaC) olarak sürüm oluşturma - tekrarlanabilir tortular ve hızlı resync.

Performans ve ayarlama

Yapımcı: yayıncı onaylar, kanal yeniden kullanımı, asenkron yayınlar.
Kuyruklar: görevin ortalama süresi için prefetch; Derin birikimler için tembel; "Sıcak" kuyrukların düğümlerle ayrılması.
Ağ/İşletim Sistemi: 10/25G, dosya tanımlayıcıları, TCP ayarı. JVM/GC - yük profili için.
Patlama yükleri için testler (maçlar, turnuvalar, zirve ödemeleri).

iGaming için tipik yönlendirme desenleri

1. Ödeme olayları (konu):

Değişim: 'ödemeler. Konu '

• 'ödemeler. psp. çizgili. Başarılı oldu '
• 'ödemeler. psp.. başarısız oldu '
• 'withdrawal. Talep edildi. #`

• 'ledger. Yazar. q '(bind:' ödemeler. #`)
• 'crm. Tetikleyiciler. q '(bind:' ödemeler... Başarılı oldu ')
• 'Risk. eleştiriler. q '(bağla:' geri çekilme. #`)

2. Antifraud puanlama (doğrudan + tekrar):

'Risk. çalışmak. Q '←' riski. Doğrudan '(' routing _ key = risk. Kontrol et ')

'Risk. yeniden deneyin. 1m. Q '(TTL 60'lar - DLX tekrar' riske. Doğrudan ')

'Risk. Dlq. Q 'ölümcül için.

3. Bildirimler (fanout + öncelik):

'notify. Fanout '-'e-posta. q (prio) ',' sms. Q ',' it. q '

Öncelikler: pazarlama postalarının üzerindeki sonuçlar/sınırlar.

4. Denetim ve izleme (başlıklar):

Üstbilgi '{"tenant ": "X ", "critical":" true"} '- ayrı bir denetim kuyruğunu bağlar.

Minimum Mesaj Şeması Örneği (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_..."
}
}

Diğer döngülerle entegrasyon

Akış/analitik: önemli konular, yeniden işleme ve yeniden işleme için günlük veriyolunda (Kafka/Redpanda) çoğaltılabilir.
Fichestor: olaylar - çevrimiçi özellikler (Redis) ve çevrimdışı taraflar (Parquet/OLAP).
Saga orkestrasyon: doğrudan/konu, olaylar aracılığıyla komutlar - pub/sub; Telafi adımları - ayrı mesajlar olarak.

Uygulama kontrol listesi

1. Etki alanı değiştiricilerini ve yönlendirme anahtar standardını tanımlayın.
2. Her kritik akış için bir iş/yeniden deneme/DLQ tasarlayın.
3. Gerektiğinde yayıncı onaylarını, 'prefetch', öncelikleri ve gecikmeyi etkinleştirin.
4. Idempotency-key, giden kutusu ve korelasyon kimliklerini girin.
5. Veri şemalarını ve evrim kurallarını onaylayın.
6. TLS/RBAC'yi, etki alanına/kiracıya göre bölümlemeyi yapılandırın.
7. SLO ve uyarıları ayarlayın (lag, DLQ-rate, p99).
8. DR planı ve otomatik IaC topolojileri hazırlayın.
9. Yük ve kaos testleri yapın.
10. Olay runbook'unu belgeleyin ve DLQ'dan yeniden enjekte edin.

Anti-desenler

Anahtar disiplini olmayan bir "dev" değiştirici; rastgele "zorunda olduğunuz gibi" bağlar.
Yeniden deneme/DLQ eksikliği ve zamansal/ölümcül hataların karıştırılması.
Senkronize RPC üzerinden broker kullanıcı sıcak yollarda.
Idempotency ve outbox eksikliği - çiftler/para kaybı.
Açık PII depolama, herkes için yayınlamak/tüketmek paylaşın.

Özet

İyi tasarlanmış bir Message Broker, yönlendirmenin öngörülebilir olduğu ve topoloji seviyesinde hata toleransının yerleşik olduğu sağlam bir olay arteridir. Konu eşanjörleri, tek bir anahtar standart, her kritik akış için iş/yeniden deneme/DLQ, idempotency ve giden kutusu, sıkı SLO'lar ve gözlemlenebilirlik kullanın. Akış veriyolu ve durum projeksiyonlarıyla birlikte bu, yük büyüdükçe iGaming platformuna sürekli hız, şeffaflık ve karmaşıklık üzerinde kontrol sağlar.