کارگزار پیام و مسیریابی رویداد
(بخش: تکنولوژی و زیرساخت)
خلاصه ای کوتاه
پیام کارگزار یک لایه اساسی از ادغام و اتوبوس رویداد در iGaming است. این پیاده سازی تحویل، بافر و مسیریابی پیام ها بین خدمات میکرو نرخ، پرداخت، ضد تقلب، KYC، CRM و تجزیه و تحلیل. مبادلات به خوبی طراحی شده (مبادلات)، صف ها، کلید های مسیریابی و قوانین تحویل مجدد، تاخیر کم، مقاومت در برابر انفجار ترافیک و SLO های قابل پیش بینی را فراهم می کند.
نقش کارگزار در پلت فرم iGaming
خدمات جداسازی: انتشار رویدادها به جای تماسهای همزمان سخت.
مسیریابی انعطاف پذیر: یک رویداد → بسیاری از مصرف کنندگان (CRM، ریسک، تجزیه و تحلیل).
مدیریت بار: صف، prefetch/QoS، backprescher.
قابلیت اطمینان و بازیابی: تأییدیه، بازپرداخت، DLQ، تکرار.
ممیزی و انطباق: ردیابی رویداد، پوشش PII، سیاست نگهداری.
مدل های پیام رسانی
Point-to-Point (صف کار): یک مصرف کننده یک کار را پردازش می کند (KYC، ایمیل، PSP webhook).
Pub/Sub (رویدادهای دامنه): انتشار به مبدل با فن برای چندین صف.
RPC از طریق کارگزار: درخواست/پاسخ با همبستگی (به ندرت در مسیرهای داغ، اما برای ادغام مفید است).
1. direct - تطبیق دقیق 'routing _ key'.
2. موضوع - قالب ها ب. «c» (یک کلمه) و «#» (0 + کلمه). انتخاب جهانی
3. fanout - پخش به تمام صف های مرتبط.
4. هدر ها - مسیریابی هدر (کلید/مقدار)، برای سیاست های پیچیده مفید است.
نمونه هایی از کلید ها و توپولوژی ها:- سلام. پی اس پی راه راه. موفق شد، پرداخت کند. PSP... شکست خورده، شرط. زندگی می کنند. «RG». محدود کردن نقض شود.
- صرافان بر پایه دامنه: "پرداختها. موضوع، شرط بندی. موضوع '،' خطر. موضوع '؛ فرد - برای رویدادهای سیستم «پلت فرم». حسابرسی کند.
صف ها و سیاست ها
صف کار: مصرف شده توسط گردانندگان کسب و کار.
صفهای تلاش مجدد: با TTL (تاخیر) و DLX برای پشتیبانگیری نمایی (برای مثال، '5s → 1m → 5m → 1h').
DLQ (Dead-Letter Queue): «تخلیه» نهایی پس از اتمام retras.
اولویت ها: برای کارهای فوری (نتیجه گیری> نامه ها).
تنبل/Quorum: تنبل - صرفه جویی در RAM با backlog های بزرگ ؛ حد نصاب - مبتنی بر اجماع HA.
- کار کن. q → 'x-dead-letter-exchange = تلاش مجدد. پس از آن
- سعی کنید. 1 متر q → 'x-message-ttl = 60000', 'x-dead-letter-exchange = work. پس از آن
- تو اتاق من. q '→ نظارت و اصلاح دستی
ضمانت نامه ها و روش های تحویل
حداقل یک بار - پیش فرض: تکراری امکان پذیر است → idempotence اجباری است.
حداکثر یک بار - حداقل تاخیر، اما خطر از دست دادن (برای سیگنال های غیر بحرانی).
دقیقا یک بار - به ندرت عملی در کارگزاران ؛ سخت تر و گران تر به دست آورد. برای پول: حداقل یک بار + idemotence سخت.
- در یک صف و با یک مصرف کننده، سفارش حفظ می شود ؛ با موازی + retraces، نظم ممکن است مختل شود.
- برای اشخاصی که نیاز به سفارش دارند، جریان (مصرف کننده تک فعال در هر کلید) را سریال کنید یا آن را به اتوبوس های «log» (جریان) انتقال دهید.
انتشار بی نظیر و معاملات
Idempotency-Key در یک پیام (ULID/UUID)، ذخیره سازی dedup با TTL یا upsert توسط کلید.
الگوی Outbox: نوشتن یک رویداد به جدول «outbox» در یک معامله کسب و کار، اتصال منتشر شده به کارگزار → مانع «ورود دو »/از دست دادن.
فراداده همبستگی: 'message _ id'، 'trace _ id'، 'causation _ id'، 'tenant _ id'.
RPC از طریق کارگزار (در صورت نیاز)
درخواست با 'reply _ to' و 'correlation _ id' منتشر می شود، پاسخ در صف مشخص شده است.
استفاده محدود (ارائه دهندگان خارجی، چک همزمان)، زمان کنترل و تمایل چت (در غیر این صورت - تخریب به یک یکپارچه توزیع شده).
برای مسیرهای داغ کاربر، رویدادهای ناهمزمان + پیش بینی های حالت ترجیح داده می شوند.
قراردادهای داده و طرح
فرمت ها: Avro/Protobuf/JSON-Schema. برای JSON، نسخه و فیلدهای مورد نیاز را اصلاح کنید.
سیاست تکامل: تغییر سازگار با عقب شکستن تغییرات بدون مهاجرت ممنوع است.
PII - نشانه گذاری/رمزگذاری زمینه ها ؛ هدف و عمر مفید.
مدیریت خطا، Retray، DLQ
طبقه بندی: موقت (شبکه/5xx) retray → file (validation/scheme) → DLQ.
عقب نشینی نمایشی + لرزش، حد مجاز، برچسب های قرص سمی.
تحویل با تاخیر: از طریق TTL/تعویض با تاخیر.
ابزار «تزریق به کار» از DLQ پس از رفع علت.
معیارهای تولید کننده: سرعت انتشار، خطاها/تأییدیه ها.
معیارهای صف: طول، میزان مصرف، درصد retrays، زمان صف p99.
مصرف کنندگان: تاخیر، توان، زمان پردازش، سهم NACK.
SLO: p99 E2E تاخیر تحویل رویداد ≤ X ثانیه ؛ دسترسی ≥ 99 9%; نرخ DLQ ≤ Y٪.
Tracing: end-to-end 'trace _ id '/' span _ id', logs by 'message _ id'.
هشدارها: DLQ/رشد رشد، افت حد نصاب، افزایش NACK، چسباندن مراحل مجدد.
امنیت و دسترسی
TLS/MTLS در حمل و نقل ؛ رمزگذاری بر روی دیسک زمانی که صف های مداوم ذخیره می شوند.
RBAC/ACL: انتشار/مصرف حقوق توسط vhost/namespace/topic.
تقسیم بندی: دامنه های حساس (پرداخت/CCM) - مبدل ها/خوشه های جداگانه.
اسرار در خرک/SOPS; گزارش حسابرسی نشریات/اشتراک ها.
محلی سازی داده ها: ذخیره سازی و نگهداری بر اساس منطقه (اتحادیه اروپا، ترکیه، LatAm).
دسترسی بالا و DR
Quorum صف/تکرار, تعداد فرد از گره, AZ ضد وابستگی.
تکثیر بین منطقه ای (فدراسیون/بیل) برای حوزه های بحرانی.
مقررات سوئیچینگ (runbook)، تمرینات دوره ای DR (روز بازی).
توپولوژی های نسخه بندی به عنوان کد (IaC) - سپرده های قابل تکرار و resync سریع.
عملکرد و تنظیم
تهیه کننده: ناشر تأیید می کند، استفاده مجدد از کانال، انتشارات ناهمزمان.
صف ها: پیش فرض برای مدت زمان متوسط کار ؛ تنبل برای عقب مانده های عمیق ؛ جداسازی صف های «داغ» توسط گره ها.
شبکه/سیستم عامل: 10/25G، توصیف فایل، تنظیم TCP. JVM/GC - برای مشخصات بار.
تست برای بارهای پشت سر هم (مسابقات، مسابقات، پرداخت اوج).
الگوهای مسیریابی معمولی برای iGaming
1. رویدادهای پرداخت (موضوع):
تبادل: "پرداخت. موضوع '
کلید های:- سلام. پی اس پی راه راه. موفق شد..
- سلام. PSP.. شکست خورده '
- با کشیدن درخواست شده #`
- گوش بده. نویسنده. q '(اتصال: "پرداخت. #`)
- سی آر ام. راه اندازها. q '(اتصال: "پرداخت... موفق شد)
- ریسک میکنم. بررسی ها q '(اتصال:' خروج. #`)
2. امتیاز ضد گلوله (مستقیم + مجدد):
ریسک میکنم. کار کن. ریسک «←» direct '(' routing _ key = risk. بررسی کنید)
ریسک میکنم. تلاش مجدد 1 متر q '(TTL 60s → DLX بازگشت به' risk. مستقیم ')
ریسک میکنم. DLQ ها Q 'برای کشنده است.
3. اطلاعیه ها (fanout + اولویت):
به من خبر بده. fanout '→' ایمیل. Q (PRIO)، اس ام اس. Q '،' فشار دهید. من..
اولویت ها: نتیجه گیری/محدودیت بالاتر از نامه های بازاریابی.
4. حسابرسی و ردیابی (هدر):
«{» مستاجر «:» X «،» بحرانی «:» درست «}» → یک صف حسابرسی جداگانه.
نمونه ای از طرح پیام حداقل (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_..."
}
}
ادغام با حلقه های دیگر
جریان/تجزیه و تحلیل: موضوعات مهم را می توان در اتوبوس ورود به سیستم (Kafka/Redpanda) برای retching و پردازش مجدد تکرار کرد.
Fichestor: رویدادها → ویژگی های آنلاین (Redis) و احزاب آفلاین (Parquet/OLAP).
ارکستر حماسه: دستورات از طریق مستقیم/موضوع، حوادث - میخانه/زیر ؛ مراحل جبران خسارت - به عنوان پیام های جداگانه.
چک لیست پیاده سازی
1. مبدل های دامنه و استاندارد کلید مسیریابی را تعریف کنید.
2. یک work/retry/DLQ برای هر جریان بحرانی طراحی کنید.
3. ناشر را فعال کنید، «prefetch»، اولویت ها و تاخیر را در صورت نیاز تأیید کنید.
4. idempotency-key، outbox و شناسه های همبستگی را وارد کنید.
5. تصویب طرح داده ها و قوانین تکامل.
6. پیکربندی TLS/RBAC، تقسیم بندی توسط دامنه/مستاجر.
7. تنظیم SLO و هشدارها (تاخیر، نرخ DLQ، p99).
8. آماده طرح DR و توپولوژی IaC خودکار.
9. تست بار و هرج و مرج را انجام دهید.
10. سند دفترچه حوادث و تزریق مجدد از DLQ.
ضد الگوهای
یک «غول» مبدل بدون نظم و انضباط کلیدی ؛ تصادفی «به عنوان شما باید» اتصال.
عدم وجود سعی مجدد/DLQ و مخلوط کردن خطاهای زمانی/کشنده.
RPC همزمان بر روی کارگزار در مسیرهای داغ کاربر.
فقدان idemotency و outbox → دو برابر/از دست دادن پول.
ذخیره سازی PII در روشن، به اشتراک گذاری انتشار/مصرف برای همه.
خلاصه
یک Message Broker خوب طراحی شده یک شریان رویداد قوی است که مسیریابی قابل پیش بینی است و تحمل خطا در سطح توپولوژی ساخته شده است. استفاده از مبدل موضوع، یک استاندارد کلیدی تک، کار/تلاش مجدد/DLQ برای هر جریان بحرانی، idempotency و outbox، SLOs سخت و مشاهده. در کنار پیش بینی های جریان اتوبوس و دولت، این به پلت فرم iGaming سرعت، شفافیت و کنترل پیچیدگی را به عنوان بار رشد می کند.