صف های پیام: کافکا و RabbitMQ

صف های پیام: کافکا، RabbitMQ

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

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

صف های پیام پایه و اساس معماری رویداد گرا (EDA) در iGaming هستند. آنها میکروسرویس های نرخ، پرداخت، ضد تقلب، CRM، اطلاعیه ها و تجزیه و تحلیل را پیوند می دهند. در عمل، دو دسته از راه حل ها رایج ترین هستند:

Apache Kafka یک event log (log) توزیع شده است که بر روی جریان، تکرار و مقیاس بندی افقی از طریق احزاب متمرکز است.
RabbitMQ یک کارگزار صف AMQP با مسیریابی انعطاف پذیر (مبادلات/اتصال)، اولویت ها، TTL، تأییدیه ها و وظایف صف کلاسیک است.

هر دو ابزار بالغ هستند، اما مشکلات مختلفی را حل می کنند: کافکا - برای جریان های مقیاس پذیر و تجزیه و تحلیل، RabbitMQ - برای ارکستراسیون وظیفه عملیاتی، RPC و مسیریابی متنوع.

در iGaming مناسب است

کافکا - انتخاب کنید که:

ما نیاز به رویدادهای TPS بالا (شرط، حوادث بازی، تله متری) و مقیاس افقی از طریق احزاب.
سرد/گرم دوباره مصرف (دوباره خواندن داده های نوار)، احتباس و تراکم برای aggregates (تعادل، شرایط بازیکن) مهم هستند.
ما نیاز به فرآیندهای جریان (Kafka Streams/ksqlDB/Flink) برای جمع آوری زمان واقعی: رهبران مسابقات، محدودیت های بازی مسئول، سیگنال های ضد تقلب.

RabbitMQ - انتخاب کنید که:

ما به صفهای وظیفه کلاسیک نیاز داریم: بررسی KYC، پرداختهای معوق/مکرر، ارسال ایمیل/SMS/فشار، وبهچ به PSP.
مسیریابی انعطاف پذیر (موضوع/مستقیم/fanout)، اولویت ها، TTL، تاخیر، الگوهای مرده و RPC.
محدودیت های مصرف کننده (prefetch/QoS)، مدیریت بار ساده و بازپرداخت سریع مورد نیاز است.

نتیجه مکرر: کافکا برای رویدادها و تجزیه و تحلیل + RabbitMQ برای ارکستراسیون و ادغام.

مدل داده و مسیریابی

کافکا

موضوعات → به احزاب تقسیم, هر ورود به سیستم دستور داد است.
کلید پیام دسته → سفارش در کلید را تعریف می کند.
مصرف کنندگان افست را می خوانند، گروه های پردازش مقیاس مصرف کنندگان.
حفظ زمان/حجم ؛ تراکم log آخرین نسخه کلید را ذخیره می کند.

RabbitMQ

مبادلات (مستقیم/fanout/موضوع/هدر) + اتصالات → پیام ها به صف می شوند.
تأییدیه (ack/nack/request)، ناشر تأیید، اولویت ها، TTL، حرف مرده (DLX/DLQ).
صف های Quorum (قایق) برای در دسترس بودن بالا ؛ صف های تنبل برای صرفه جویی در RAM.

تضمین تحویل و قابلیت اطمینان

حداکثر یک بار: بدون بازپرداخت ؛ خطر از دست دادن، حداقل تاخیر.
حداقل یک بار: استاندارد پیش فرض → تکراری → کنترل کننده های idempotent (کلید درخواست/معامله، uppert، جدول dedup، صندوق پستی) امکان پذیر است.
دقیقا یک بار: در کافکا، تولید کننده idempointent + موضوعات معامله + مصرف توافق شده است در رابطه به دست آورد، اما اغلب آن را گران تر و سخت تر است ؛ در RabbitMQ - محدود و با استخوان. در جریان پرداخت واقعی/شرط بندی، حداقل یک بار + idempointence دقیق اعمال می شود.

تمرین بی نظیر:

منحصر به فرد idempotency کلید (UUID/ULID) در هر رویداد/دستور.
الگوی جعبه خروجی در + Change Data Capture (Debezium) پایگاه داده خدمات → پیشگیری از نوشتن دو.
Dedup توسط (کلید، created_at) در یک ردیف جداگانه با TTL.

سفارش/سفارش پیام

کافکا نظم را در درون حزب تضمین میکند. کلید را انتخاب کنید تا کل «زندگی» موجودیت (به عنوان مثال، «player _ id» برای تعادل) در یک کلید باشد.
سفارش RabbitMQ به شدت با تحویل مکرر/چندین مصرف کننده تضمین نمی شود. خطوط لوله حیاتی برای سفارش - بهتر در کافکا و یا از طریق مصرف کننده تک فعال و سریال سازی جریان.

طراحی topicals و صف

کافکا:

گرانولاریته: "دامنه. رویداد «(به عنوان مثال،» پرداخت. سپرده گذاری ایجاد شده است.)
کلید: 'player _ id'، 'account _ id'، 'bet _ id' برای سفارش.
دسته = N توسط TPS هدف (قانون: 1 دسته ≈ پیام های X/ثانیه/مصرف کننده) ؛ ذخیره سازی برای رشد.
نگهداری: حوادث - ساعت/روز ؛ تراکم - برای «ایالات».

RabbitMQ:

مبادلات توسط دامنه: "پرداخت. مستقیم، خطر. موضوع '.
صف برای مصرف کنندگان: "kyc. چک کن. س، PSP. وب سایت ها تلاش مجدد Q '.
DLQ در هر تاخیر کار برای بازپرداخت.
Prefetch همروندی، صفهای حد نصاب برای HA را مشخص میکند.

خطاها، Retrays و DLQ ها

طبقه بندی خطاها: موقت (شبکه/PSP 5xx) → retrays ؛ fatal (اعتبارسنجی، طرح) → بلافاصله DLQ.
عقب نشینی نمایشی + لرزش، حد مجاز، تشخیص قرص سمی.
صف های مجدد را با مراحل (5s، 1m، 5m، 1h) جدا کنید.
کنترل کننده DLQ: هشدار، ردیابی، تجزیه دستی، تزریق مجدد با پچ.

قرارداد داده ها و شماتیک

از Avro/Protobuf + Schema Registry استفاده کنید (برای استاندارد کافکا).
Versioning: تغییرات سازگار با عقب (اضافه کردن زمینه های اختیاری)، ممنوعیت مهاجرت شکستن.
زمینه های PII - رمزگذاری/نشانه گذاری ؛ مطابق با GDPR و مقررات محلی است.

💡 > نظارت، مشاهده و SLO

معیارهای تولید کنندگان/مصرف کنندگان: تاخیر، توان، خطا، retrai، زمان پردازش.
Logs + tracing (شناسه همبستگی: 'trace _ id', 'message _ id').
SLO: p99-latency انتشار/تحویل، تاخیر مصرف کننده مجاز، زمان بازیابی پس از فایل ها.
هشدار برای رشد DLQ، تاخیر بیش از حد، کاهش در احزاب/حد نصاب.

ایمنی و انطباق

TLS در حمل و نقل، رمزگذاری مخفی (SOPS/خرک)، ACL محدود/RBAC.
موضوعات/صفهای جداگانه برای دامنههای حساس (پرداختها، KYC).
گزارش حسابرسی نشریات/اشتراک ها، ذخیره سازی کلید های خارج از کد.
الزامات منطقه ای (EU/Turkey/LatAm): نگهداری، محلی سازی ذخیره سازی، ماسک کردن.

در دسترس بودن بالا، تحمل خطا و DR

کافکا:

خوشه ای از کارگزاران 3-5 حداقل ؛ تکرار. عامل ≥ 3.
مین. اینسینک. کپی و acks = همه برای سوابق با دوام.
تکرار متقابل منطقه ای (MirrorMaker-2) برای دکتر

RabbitMQ:

صف های Quorum برای HA، تعداد زوج/فرد گره ها با quorum.
فدراسیون/بیل برای تکرار مرکز بین داده، اسکریپت DR.
پایه سرد/گرم، آزمایش سوئیچینگ.

عملکرد و تنظیم

کافکا (تهیه کننده):

ادامه بده. خانم 'и' دسته ای. اندازه 'برای قصابی ؛ فشرده سازی. تایپ کنید '(lz4/zstd).
'بسته = همه'، اما مراقب تاخیر ؛ خیلی مهم است. در. پرواز. درخواست ها per. اتصال 'با idemotency.

کافکا (کارگزار/موضوع):

احزاب به اندازه کافی ؛ NVMe شبکه 10/25G را هدایت می کند ؛ تنظیمات JVM GC.

کافکا (مصرف کننده):

مدیریت صحیح گروه، حداکثر نظرسنجی. فاصله زمانی. خانم، مهمونيها رو متوقف کن.

RabbitMQ (تهیه کننده):

ناشر در بوت تایید می کند ؛ کانال های استفاده مجدد

RabbitMQ (صف/مصرف کنندگان):

'prefetch' (به عنوان مثال،. 50-300) با زمان درمان ؛ صف های تنبل برای عقب ماندگی های بزرگ.
ارسال صفهای داغ به گرهها ؛ TCP تنظیم/توصیف فایل.

الگوهای معمول برای iGaming

صندوق خروجی + کافکا برای انتشار قابل اعتماد از رویدادهای دامنه (شرط قرار داده شده, سپرده اعتبار).
RabbitMQ RPC برای درخواستهای همزمان به یکپارچگی (بررسی سند KYC، محاسبه تخفیف).
الگوی حماسه: ارکستراسیون از طریق رویدادها (کافکا) و تیم ها (RabbitMQ) با مراحل جبرانی.
اطلاعیه های فن: از یک رویداد → CRM، ضد تقلب، تجزیه و تحلیل.
وب سایت های هوشمند PSP با تاخیر مترقی و DLQ.

مهاجرت و معماری ترکیبی

با RabbitMQ برای «سیستم عامل» شروع کنید، کافکا را برای رویدادها و تجزیه و تحلیل اضافه کنید.
انتشارات تکراری: سرویس → outbox → اتصال در هر دو جهت (Kafka + RabbitMQ) تا تثبیت کامل.
به تدریج مشترکین تجزیه و تحلیل/جریان را به Kafka Streams/ksqlDB مهاجرت کنید.

چک لیست انتخاب مینی

1. بار/TPS> ده ها هزار نفر/ثانیه → کافکا.
2. نیاز به حفظ و دوباره خواندن مانند از یک مجله → کافکا.
3. مسیریابی انعطاف پذیر، اولویت ها، تحویل با تاخیر، RPC ؟ → RabbitMQ.
4. ترتیب دقیق کلید و مقیاس افقی → کافکا (کلید/احزاب).
5. وظایف ساده/کار با کنترل همزمان → RabbitMQ.
6. در حالت ایده آل، ترکیبی: کافکا (رویدادها) + RabbitMQ (ارکستراسیون).

نمونه هایی از حداقل تنظیمات

مثال: Retray تاخیر و DLQ در RabbitMQ (از طریق سیاست)

صف کار: "psp. وب سایت ها من..

Retras صف: PSP. وب سایت ها تلاش مجدد 1 متر q '(TTL = 60s، DLX به عملیات اشاره دارد)

DLQ: "psp. وب سایت ها این طور نیست ؟

سیاست ها (مفهومی):

پی اس پی. وب سایت ها q → 'x-dead-letter-exchange = psp. تلاش مجدد مبادله کنند
پی اس پی. وب سایت ها تلاش مجدد 1 متر q → 'x-message-ttl = 60000', 'x-dead-letter-exchange = psp. کار کن. مبادله کنند
پی اس پی. وب سایت ها DLQ → نظارت و اشکال زدایی دستی.

مثال: موضوع شرط بندی کافکا

موضوع: شرط بندی قرار داده است. v1 '، احزاب: 24، RF = 3، نگهداری 7 روز.
کلید پیام «player _ id» یا «bet _ id» است (انتخاب کنید که برای سفارش مهم تر است).
Схема: Protobuf/Avro с 'bet _ id', 'player _ id', 'stake', 'odds', 'ts', 'idempotency _ key'.

تست و کیفیت

تست قرارداد تولید کننده/مصرف کننده + طرح رجیستری.
آزمون هرج و مرج: قطره گره، تاخیر شبکه، تقسیم مغز.
بار با TPS هدف، بررسی P99، رشد تاخیر و بازیابی اجرا می شود.

خلاصه

Kafka - بزرگراه رویداد و جریان: سفارش کلیدی, حفظ/فشرده سازی, TPS بالا, تجزیه و تحلیل در زمان واقعی.
RabbitMQ - صف کار عملیاتی: مسیریابی انعطاف پذیر، تأیید، اولویت ها، retrays/DLQ، RPC.
در iGaming، بهترین روش استفاده مکمل است: رویدادها و تجزیه و تحلیل در کافکا، وظایف ادغام/ارکستراسیون در RabbitMQ، با استانداردهای طرح یکنواخت، idempotency، نظارت و SLO های دقیق.