قوائم انتظار الرسائل: Kafka و RabbitMQ
قوائم انتظار الرسائل: كافكا، RabbitMQ
(القسم: التكنولوجيا والهياكل الأساسية)
موجز موجز
قوائم انتظار الرسائل هي أساس الهندسة المعمارية الموجهة نحو الأحداث (EDA) في iGaming. يربطون الخدمات الدقيقة للأسعار والمدفوعات ومكافحة الاحتيال وإدارة علاقات العملاء والإخطارات والتحليلات. من الناحية العملية، هناك فئتان من الحلول الأكثر شيوعًا:- Apache Kafka هو سجل حدث موزع (سجل) يركز على البث والتكرار والتحجيم الأفقي من خلال الحفلات.
- RabbitMQ هو وسيط قائمة انتظار AMQP مع توجيه مرن (تبادل/ربط) وأولويات و TTL وتأكيدات ومهام قائمة الانتظار الكلاسيكية.
كلتا الأداتين ناضجتان، لكنهما تحلان مشاكل مختلفة: كافكا - للتدفقات والتحليلات القابلة للتطوير، RabbitMQ - لتنسيق المهام التشغيلية، RPC والتوجيه المتنوع.
أين هو مناسب في iGaming
كافكا - اختر متى:- نحن بحاجة إلى أحداث TPS عالية (رهانات، أحداث ألعاب، قياس عن بعد) ومقياس أفقي من خلال الأطراف.
- إعادة الاستهلاك البارد/الساخن (بيانات إعادة قراءة الشريط)، والاحتفاظ والضغط للمجموعات (التوازن، حالة اللاعب) مهمة.
- نحن بحاجة إلى عمليات البث (Kafka Streams/ksqlDB/Flink) لمجموعات الوقت الحقيقي: قادة البطولة، حدود اللعبة المسؤولة، إشارات مكافحة الاحتيال.
- نحن بحاجة إلى قوائم انتظار المهام الكلاسيكية: شيك KYC، والمدفوعات المؤجلة/المتكررة، وإرسال البريد الإلكتروني/الرسائل القصيرة/الدفع، وخطافات الويب إلى PSP.
- التوجيه المرن (الموضوع/المباشر/المعجب)، الأولويات، TTL، التأخير، الحروف الميتة وأنماط RPC.
- هناك حاجة إلى قيود صارمة لكل مستهلك (prefetch/QoS) وإدارة بسيطة للتحميل وإعادة التدوير السريع.
النتيجة المتكررة: كافكا للأحداث والتحليلات + RabbitMQ للتنسيق والتكامل.
نموذج البيانات وتوجيهها
كافكا
يتم تقسيم الموضوعات → إلى أطراف، كل منها عبارة عن سجل مرتب.
يحدد مفتاح الرسالة الدفعة → الطلب داخل المفتاح.
يقرأ المستهلكون التعويض، مجموعات المستهلكين على نطاق المعالجة.
الاحتفاظ حسب الوقت/الحجم ؛ يخزن ضغط السجل أحدث نسخة من المفتاح.
RabbitMQ
التبادلات (مباشرة/fanout/topic/headers) + الارتباطات → الرسائل تدخل في قوائم الانتظار.
تأكيدات (ack/nack/request)، ناشر يؤكد، أولويات، TTL، حرف ميت (DLX/DLQ).
طوابير النصاب (الطوافة) للتوافر العالي ؛ طوابير كسولة لإنقاذ ذاكرة الوصول العشوائي.
ضمانات التسليم والخصوصية
على الأكثر مرة واحدة: لا توجد عمليات إعادة طباعة ؛ خطر الخسارة، الحد الأدنى من التأخير.
مرة واحدة على الأقل: من الممكن تكرار → القياسي الافتراضي → المعالجين الخاصين (مفتاح الطلب/المعاملة، والمزعج، وجدول التخلص، وصندوق الخروج).
مرة واحدة بالضبط: في كافكا، يتم تحقيق منتج خفي + مواضيع المعاملات + الاستهلاك المتفق عليه جنبًا إلى جنب، ولكن في كثير من الأحيان يكون أكثر تكلفة وأكثر صعوبة ؛ في RabbitMQ - محدود وعظام. في تدفقات الدفع/الرهان الحقيقية، يتم تطبيق التطهير الصارم مرة واحدة على الأقل.
- مفاتيح الخصوصية الفريدة (UUID/ULID) لكل حدث/أمر.
- نمط Outbox في + Change Data Capture (Debezium) قاعدة بيانات الخدمة → منع الكتابة المزدوجة.
- Dedup by (key، created_at) في صف منفصل مع TTL.
أمر/رسالة
كافكا يضمن النظام داخل الحزب. اختر المفتاح بحيث تكون «الحياة» الكاملة للكيان (على سبيل المثال، «معرف اللاعب» للتوازن) في مفتاح واحد.
طلب RabbitMQ غير مضمون تمامًا مع عمليات التسليم المتكررة/العديد من المستهلكين ؛ خطوط الأنابيب الحاسمة للطلب - بشكل أفضل في كافكا أو من خلال تسلسل المستهلك الفريد والتيار.
تصميم المواضيع وقوائم الانتظار
كافكا:- الحبيبية: نطاق. '(على سبيل المثال،' المدفوعات. الإيداع. أنشئت ').
- المفاتيح: «player _ id»، «account _ id»، «bet _ id» للطلب.
- الدفعات = N حسب الهدف TPS (القاعدة: 1 دفعة ≈ X رسائل/ثانية/مستهلك) ؛ أرصدة للنمو.
- الاحتفاظ: الأحداث - ساعات/أيام ؛ ضغط - لـ «الدول».
- التبادلات حسب المجال: المدفوعات. مباشرة '،' خطر. '.
- قوائم انتظار للمستهلكين: 'kyc. المدقق. q ',' psp. خطوط الويب. إعادة المحاولة. q '.
- تأخير DLQ لكل طابور عمل للتراجع.
- يحدد Prefetch قوائم انتظار النصاب الخاص بـ HA.
الأخطاء وإعادة التدوير و DLQs
الأخطاء المصنفة: إعادة → مؤقتة (الشبكة/PSP 5xx) ؛ قاتلة (التحقق، المخطط) → DLQ على الفور.
التراجع الأسي + النفاخ، حد إعادة الدرج، الكشف عن حبوب منع الحمل السامة.
قوائم انتظار منفصلة لإعادة المحاولة بالخطوات (5s، 1m، 5m، 1h).
معالج DLQ: التنبيه، التتبع، التحليل اليدوي، إعادة الحقن مع التصحيح.
عقد البيانات والتخطيطات
استخدم Avro/Protobuf + Schema Registry (لكافكا - المعيار الفعلي).
التحرير: تغييرات متوافقة مع الخلف (إضافة مجالات اختيارية)، وحظر كسر الهجرة.
حقول PII - التشفير/الترميز ؛ مع اللائحة العامة لحماية البيانات واللوائح المحلية.
الرصد وقابلية الملاحظة و SLO
مقاييس المنتجين/المستهلكين: التأخر، الإنتاجية، الأخطاء، retrai، وقت المعالجة.
Logs + tracking (correlation ID: 'trace _ id', 'message _ id').
SLO: p99 - زمن انتقال النشر/التسليم، تأخر المستهلك المسموح به، وقت الاسترداد بعد الملفات.
تنبيهات نمو DLQ، تأخر زائد، انخفاض في الحفلات/النصاب القانوني.
السلامة والامتثال
TLS في العبور، التشفير السري (SOPS/Vault)، ACL/RBAC محدود.
مواضيع/قوائم انتظار منفصلة للمجالات الحساسة (المدفوعات، KYC).
سجل مراجعة للمنشورات/الاشتراكات، وتخزين المفاتيح خارج الرمز.
المتطلبات الإقليمية (EU/Turkey/LatAm): الاحتفاظ، وتوطين التخزين، والإخفاء.
ارتفاع التوافر وتحمل الأخطاء و DR
كافكا:- مجموعة السماسرة 3-5 على الأقل ؛ التكرار. العامل ≥ 3.
- min. insync. نسخ طبق الأصل و acks = كل ذلك للسجلات الدائمة.
- التكرار عبر الإقليمي (MirrorMaker-2) لـ DR.
- قوائم انتظار النصاب لـ HA، عدد زوجي/فردي من العقد مع النصاب القانوني.
- Federation/Shovel for inter-data center replication, DR scripts.
- حامل بارد/دافئ، اختبارات التبديل.
الأداء والضبط
كافكا (منتج):- 'باقية. دفعة السيدة «и». ' الضغط. النوع '(lz4/zstd).
- "acks = all'، ولكن مراقبة الكمون ؛ لحن 'max. في. الرحلة. الطلبات. per. connection 'with embuty.
- حفلات كافية ؛ NVMe يقود شبكة 10/25G ؛ إعدادات JVM GC.
- إدارة المجموعة الصحيحة، "الحد الأقصى. استطلاع. الفاصل الزمني. آنسة، أوقفوا الحفلات في الخلف.
- الناشر يؤكد في الجزار ؛ إعادة استخدام القنوات.
- «prefetch» (على سبيل المثال 50-300) حسب وقت العلاج ؛ طوابير كسولة للتراكم الكبير.
- وضع طوابير ساخنة على العقد ؛ ضبط TCP/وصف الملفات.
الأنماط النموذجية للألعاب
Outbox + Kafka للنشر الموثوق لأحداث النطاق (وضع الرهان، الإيداع).
RabbitMQ RPC للطلبات المتزامنة للتكامل (فحص مستند KYC، حساب الخصم).
نمط الملحمة: التنسيق من خلال الأحداث (كافكا) والفرق (RabbitMQ) بخطوات تعويضية.
إخطارات المعجبين: من حدث واحد → CRM، مكافحة الاحتيال، التحليلات.
خطافات ويب PSP الذكية مع تأخيرات تدريجية و DLQ.
الهجرة والهياكل الهجينة
ابدأ بـ RabbitMQ لـ «نظام التشغيل»، أضف كافكا للأحداث والتحليلات.
مطبوعات مكررة: خدمة → صندوق خارجي → موصل في كلا الاتجاهين (Kafka + RabbitMQ) حتى الاستقرار الكامل.
ترحيل المشتركين في التحليلات/تجميع التدفق تدريجياً إلى Kafka Streams/ksqlDB.
قائمة مرجعية مصغرة للاختيار
1. حمل/TPS> عشرات الآلاف/ثانية ؟ → كافكا.
2. هل تحتاج إلى الاحتفاظ وإعادة القراءة مثل من مجلة ؟ → كافكا.
3. توجيه مرن، أولويات، تأخير التسليم، RPC ؟ → RabbitMQ.
4. نظام رئيسي صارم ونطاق أفقي → كافكا (مفتاح/أحزاب).
5. مهام بسيطة/كيو عمل مع التحكم المتزامن → RabbitMQ.
6. من الناحية المثالية، مزيج: كافكا (الأحداث) + RabbitMQ (التنسيق).
أمثلة على التشكيلات الدنيا
مثال: تأخر retrai و DLQ في RabbitMQ (عبر السياسة)
قائمة انتظار العمل: "psp. خطوط الويب. س "
طابور Retras: 'psp. خطوط الويب. إعادة المحاولة. 1 م. q '(TTL = 60، DLX يشير مرة أخرى إلى التشغيل)
DLQ: 'psp. خطوط الويب. dlq '
السياسات (من الناحية المفاهيمية):- 'psp. خطوط الويب. q '→' x-dead-letter-exchange = psp. إعادة المحاولة. التبادل '
- 'psp. خطوط الويب. إعادة المحاولة. 1 م. q '→' x-message-tl = 60000 ',' x-dead-letter-exchange = psp. العمل. التبادل '
- 'psp. خطوط الويب. dlq '→ الرصد والتصحيح اليدوي.
مثال: موضوع مراهنة كافكا
الموضوع: "الرهانات. وضعت. v1 '، الأطراف: 24، RF = 3، الاحتفاظ 7 أيام.
مفتاح الرسالة هو «player _ id» أو «bet _ id» (اختر أيهما أكثر أهمية للطلب).
Схема: Protobuf/Avro с 'bet _ id'، 'player _ id'، 'stake'، 'odds'،' ts'، 'idempotency _ key'.
الاختبار والجودة
اختبارات العقد المنتج/المستهلك + سجل المخطط.
اختبارات الفوضى: قطرات العقدة، تأخير الشبكة، انقسام الدماغ.
يتم تشغيل الحمل باستخدام TPS المستهدف، والتحقق من p99، والنمو المتأخر والتعافي.
موجز
كافكا - الطريق السريع للحدث والبث: طلب المفتاح، الاحتفاظ/الضغط، TPS عالية، تحليلات في الوقت الفعلي.
RabbitMQ - قائمة انتظار المهام التشغيلية: التوجيه المرن، والتأكيدات، والأولويات، وإعادة التصوير/DLQ، RPC.
في iGaming، أفضل الممارسات هي استخدام تكميلي: الأحداث والتحليلات في كافكا، ومهام التكامل/التنسيق في RabbitMQ، مع معايير مخطط موحدة، والخصوصية، والرصد، ومنظمات SLO صارمة.