GH GambleHub

کارگزار پیام و مسیریابی رویداد

(بخش: تکنولوژی و زیرساخت)

خلاصه ای کوتاه

پیام کارگزار یک لایه اساسی از ادغام و اتوبوس رویداد در iGaming است. این پیاده سازی تحویل، بافر و مسیریابی پیام ها بین خدمات میکرو نرخ، پرداخت، ضد تقلب، KYC، CRM و تجزیه و تحلیل. مبادلات به خوبی طراحی شده (مبادلات)، صف ها، کلید های مسیریابی و قوانین تحویل مجدد، تاخیر کم، مقاومت در برابر انفجار ترافیک و SLO های قابل پیش بینی را فراهم می کند.

نقش کارگزار در پلت فرم iGaming

خدمات جداسازی: انتشار رویدادها به جای تماسهای همزمان سخت.
مسیریابی انعطاف پذیر: یک رویداد → بسیاری از مصرف کنندگان (CRM، ریسک، تجزیه و تحلیل).
مدیریت بار: صف، prefetch/QoS، backprescher.
قابلیت اطمینان و بازیابی: تأییدیه، بازپرداخت، DLQ، تکرار.
ممیزی و انطباق: ردیابی رویداد، پوشش PII، سیاست نگهداری.

مدل های پیام رسانی

Point-to-Point (صف کار): یک مصرف کننده یک کار را پردازش می کند (KYC، ایمیل، PSP webhook).
Pub/Sub (رویدادهای دامنه): انتشار به مبدل با فن برای چندین صف.
RPC از طریق کارگزار: درخواست/پاسخ با همبستگی (به ندرت در مسیرهای داغ، اما برای ادغام مفید است).

💡 > مفاهیم مسیریابی (AMQP کلاسیک)
مبادلات و اتصالات تعیین می کند که پیام در کدام صف قرار می گیرد:

1. direct - تطبیق دقیق 'routing _ key'.

2. موضوع - قالب ها ب. «c» (یک کلمه) و «#» (0 + کلمه). انتخاب جهانی

3. fanout - پخش به تمام صف های مرتبط.

4. هدر ها - مسیریابی هدر (کلید/مقدار)، برای سیاست های پیچیده مفید است.

نمونه هایی از کلید ها و توپولوژی ها:
  • سلام. پی اس پی راه راه. موفق شد، پرداخت کند. PSP... شکست خورده، شرط. زندگی می کنند. «RG». محدود کردن نقض شود.
  • صرافان بر پایه دامنه: "پرداختها. موضوع، شرط بندی. موضوع '،' خطر. موضوع '؛ فرد - برای رویدادهای سیستم «پلت فرم». حسابرسی کند.
توصیه ها:
استاندارد سازی طرح کلید دامنه. زیر دامنه فعل. وضعیت (مار)مورد نقطه - یکنواخت).
کاهش اتصال - یک مبدل → بسیاری از صف، نه «بسیاری از مبدل» غیر ضروری است.
برای چند اجاره: vhost/namespace در هر مشتری، پیشوندها در کلید: 'tenantX. پرداخت ها پی اس پی...

صف ها و سیاست ها

صف کار: مصرف شده توسط گردانندگان کسب و کار.
صفهای تلاش مجدد: با 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 پس از رفع علت.

💡 > قابلیت مشاهده و SLO

معیارهای تولید کننده: سرعت انتشار، خطاها/تأییدیه ها.
معیارهای صف: طول، میزان مصرف، درصد 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 سرعت، شفافیت و کنترل پیچیدگی را به عنوان بار رشد می کند.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

Telegram
@Gamble_GC
شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.