ما يعنيه زمن الانتقال فعلاً في الرهان المباشر
عندما نقول «زمن انتقال احتمالات دون 50 مللي ثانية» نعني رقمًا محددًا: زمن ساعة الحائط p50 بين اللحظة التي ينشر فيها التدفق المصدر (Betradar، Genius Sports، BetGenius) سعرًا محدثًا في المجمع الخاص بنا واللحظة التي يُعرض فيها هذا السعر في اتصال WebSocket المفتوح للاعب.
رقم إنتاج Sporbet Soft هو 47 مللي ثانية p50، 180 مللي ثانية p99، تقاس عبر جميع الأسواق الممكنة لجميع الشركاء على نافذة متجددة لمدة 30 يومًا. المنصات التي تعمل بزمن انتقال p99 يبلغ 500 مللي ثانية+ تتم المراجحة عليها. المنصات التي تعمل بـ 50 مللي ثانية p50 لا يحدث ذلك.
المبرر المعماري لإعطاء الأولوية لزمن الانتقال يعيش في تشريح التكامل لدينا.
Redis pub/sub fan-out والاشتراكات المقسمة
النظام الفرعي الأول هو طبقة fan-out. عندما يهبط حدث سعر محدث في المجمع الخاص بنا، يُعاد نشره على موضوع Redis pub/sub. مفتاح الموضوع منظم: odds:{sport_id}:{league_id}:{market_id}. اختيار التفصيلية مهم.
استراتيجية تقسيم Sporbet Soft هي مستوى السوق لأفضل 100 دوري ومستوى الدوري للذيل الطويل. اللاعب الذي يشترك في سوق نتيجة المباراة لمباراة الدوري الإنجليزي الممتاز يشترك في موضوع واحد ويتلقى تدفقًا واحدًا من تحديثات الأسعار لذلك السوق فقط.
Redis هو الأداة الصحيحة هنا لأن ميزانية زمن الانتقال لقفزة fan-out أقل من 5 مللي ثانية. أسبوع مباريات دوري الأبطال واحد يدفع 800 ألف حدث/دقيقة عبر fan-out. مجموعة Redis تستمر في ذلك بزمن انتقال نشر p99 دون مللي ثانية.
WebSockets ذات الجلسات اللاصقة وآلة حالة الاتصال
النظام الفرعي الثاني هو أسطول WebSocket. كل جلسة لاعب تفتح اتصال WebSocket واحد طويل العمر إلى أحد بوابات الحافة لدينا. الاتصال لاصق — أي موجه بواسطة موازن تحميل من الطبقة 4 مع تجزئة متسقة على ملف تعريف ارتباط الجلسة.
آلة حالة الاتصال نفسها أكثر إثارة للاهتمام من المتوقع. كل اتصال يحمل المواضيع المشترك فيها، جلسة اللاعب المصادق عليها، علامة الماء العالية لـ back-pressure ومعرف الحدث الأخير المعترف به. عند إعادة الاتصال — شائع على الشبكات المحمولة — يستأنف العميل من معرف الحدث الأخير المعترف به.
نفس نمط idempotency الذي يستخدمه محرك التسوية الخاص بنا لـ cashout الجزئي يظهر هنا.
الصدفة الثابتة المخزنة على الحافة وميزانية time-to-interactive
زمن الانتقال لاتصال موجود شيء واحد. زمن الانتقال للرسم الأول — الوقت بين اللاعب الذي ينتقل إلى iframe ورؤية احتمالات جديدة — شيء آخر. Sporbet Soft يصل إلى time-to-interactive دون 1.5 ثانية على الهاتف المحمول من خلال التخزين المؤقت على الحافة للصدفة الثابتة لـ iframe.
الصدفة هي وثيقة HTML صغيرة (أقل من 50 كيلوبايت، مضغوطة gzip إلى حوالي 14 كيلوبايت) بالإضافة إلى حزمة JavaScript أقل من 200 كيلوبايت. كلاهما يُخدم من CDN — Cloudflare في حالتنا — مع رؤوس تخزين مؤقت قوية.
تم ضبط التسلسل بأكمله لتجاوز عتبة Google INP البالغة 200 مللي ثانية مع هامش — انظر تسعير sportsbook لكيفية انعطاف ميزانية الأداء هذه في الرسم الثابت.
حماية back-pressure: ماذا يحدث عندما يندفع تدفق upstream
حركة مرور الاحتمالات المباشرة ليست سلسة. بطاقة حمراء في الوقت الإضافي في El Clásico تولد ارتفاعًا بمقدار 50 مرة في أحداث الأسعار على نافذة 30 ثانية. منصة بدون حماية back-pressure ترى تلك الأحداث تصطف في مخزن إرسال WebSocket، وفي النهاية تنفد بوابة الواصفات الملفية وتسقط.
بوابات Sporbet Soft تنفذ back-pressure صريحًا بآليتين. أولاً: علامات الماء العالية لمخزن الإرسال لكل اتصال. ثانيًا: قواطع دائرة على مستوى الأسطول.
حاسم: back-pressure لا يتسبب أبدًا في قبول البوابة لاحتمالات قديمة. ثابت السلامة — كل اتصال يرى تسلسل أحداث غير متناقص رتيب لكل سوق — يصمد تحت جميع الظروف.
متعدد المناطق active-active وfailover دون الثانية
النظام الفرعي الأخير هو طوبولوجيا failover. Sporbet Soft يدير ثلاث مناطق — EU-West، EU-Central، Middle-East — في تكوين active-active. كل منطقة لديها نسخة كاملة من أسطول WebSocket، مجموعة Redis، المجمع ومحرك التسوية.
التوجيه الجغرافي القائم على DNS يرسل كل لاعب إلى أقرب منطقة له. عندما تتدهور منطقة، تعيد طبقة DNS توجيه الاتصالات الجديدة إلى المنطقة الأقرب التالية في غضون 30-60 ثانية. failover من البداية إلى النهاية أقل من ثانية واحدة من الاضطراب المرئي للمستخدم.
المشغلون على iframe — انظر B2B sportsbook iframe — لا يرون أبدًا نافذة صيانة.
لماذا polling API لا يأخذك إلى هناك
المشغلون الذين يقيمون تكاملات API-only يسألون أحيانًا ما إذا كان يمكنهم تحقيق زمن انتقال مماثل من خلال polling نقطة نهاية REST للاحتمالات بتردد عالٍ. الجواب هو لا، والرياضيات بسيطة. فاصل polling 100 مللي ثانية يعطي فجوة طزاجة أسوأ حالة 100 مللي ثانية.
fan-out WebSocket القائم على push يتوسع في الاتجاه الآخر: يرسل البائع حدثًا واحدًا لكل تحديث سوق بغض النظر عن عدد المشتركين. فجوة الطزاجة محدودة بزمن انتقال الشبكة، وليس بفاصل polling.
إذا كنت تقيم بناء API-only، فإن ميزانية زمن انتقال الرهان المباشر وحدها عادةً ما تكون كافية لدفع القرار نحو iframe — انظر مقارنة iframe vs API لدينا.