amBrain
AdTechJan 22, 2026قراءة 8 دقائق

هندسة بنية مزايدة فورية بسعة 100K QPS

منصة المزايدة الآنيةتطوير DSPتطوير SSPمنصة تبادل الإعلاناتالإعلان البرمجيالبنية التحتية للمزايدةمعدل النقر (CTR)زمن استجابة منخفضمراكز البياناتأداء عالٍ
تعذّر تحميل الصورة

أنظمة RTB يجب أن تُقيّم طلبات المزايدة وتمنحها درجة وتردّ عليها خلال 10ms عند أكثر من 100,000 استعلام في الثانية. إليك كيف تعمل البنية عند هذا النطاق.

يصل طلب مزايدة من منصة تبادل الإعلانات. أمام بنية المزايدة 10ms لتقييم الظهور الإعلاني، وتسجيله مقابل الحملات النشطة، وحساب سعر المزايدة، وإعادة الرد.

تفويت المهلة يعني ضياع الظهور. لا توجد محاولة ثانية. وعند 100,000+ QPS، تعني نسبة انتهاء مهلة قدرها 1% وحدها 1,000 فرصة ضائعة في الثانية.

ضع المزايدين في موقع مشترك مع منصات التبادل لاستعادة زمن التقييم

زمن استجابة الشبكة بين المزايد وad exchange يقلّص مباشرةً الوقت المتاح لتقييم العروض. المزايد الذي يبعد 50ms شبكيًا عن ad exchange يكون قد خسر قبل أن ينفَّذ كوده.

فرق تطوير DSP التي تضع خوادم المزايدة بجوار منصات التبادل الكبرى تستعيد ميلي ثوانٍ حاسمة:

  • النشر في 6-8 مراكز بيانات عالمية يستعيد 5-15ms من زمن التقييم لكل طلب مقارنةً بالنشر المركزي
  • مجموعات التوسّع التلقائي في كل منطقة تستجيب لأنماط الحركة - شرق الولايات المتحدة يبلغ ذروته في ساعات العمل بينما تتقلّص آسيا والمحيط الهادئ
  • نسخ المزايد الإقليمية تحتفظ بنسخ محلية من بيانات استهداف الحملات، تُزامَن كل 5-10 ثوانٍ من المخزن المركزي
  • كابلات الألياف الضوئية بين مراكز البيانات تنقل حركة المزامنة، لكن مسار تقييم المزايدات لا يعبر حدود المناطق أبدًا

اختيار مركز البيانات قرار هندسي من الدرجة الأولى لأي منصة جانب طلب (DSP). كل جزء من الألف من الثانية في مسافة الشبكة يترجم مباشرة إلى معدلات فوز أقل.

تعذّر تحميل الصورة
الموقع المشترك مع ad exchanges يستعيد 5-15ms من زمن التقييم لكل طلب مزايدة

أزل تخصيص الذاكرة من المسار الساخن لتقييم المزايدات

عند 100K QPS تحدّد أنماط تخصيص الذاكرة ما إذا كان النظام يلتزم بميزانية زمن الاستجابة. وتوقّفات جمع القمامة غير الملحوظة عند 100 QPS تصبح كارثية على النطاق الكبير.

مسار تقييم المزايدة يستخدم تقنيات محددة:

  • جداول بحث محسوبة مسبقًا لمعايير استهداف الحملات وحدود التكرار وقيود الميزانية - تُحدَّث بشكل غير متزامن كل 5-10 ثوانٍ من مخزن الحملات الرئيسي
  • تجميع الكائنات وتخصيص الذاكرة بأسلوب arena لإلغاء تخصيصات الكومة لكل طلب تمامًا
  • بنى بيانات بلا أقفال للحالة المشتركة - bloom filters لتحديد تكرار الظهور، وعدّادات ذرّية لضبط وتيرة الميزانية
  • أشجار قرار مبنيّة مسبقًا لتقييم الاستهداف - بناء الشجرة يكلّف ثوانٍ، وتقييمها يكلّف ميكروثواني

انعدام التخصيص في المسار الساخن ليس تحسيناً، بل شرط أساسي عند 100K QPS.

شغّل استدلال نموذج التعلّم الآلي في أقل من 3ms لكل مزايدة

نماذج التنبؤ بمعدل النقر واحتمال التحويل يجب أن تنفّذ الاستدلال خلال 2-3ms ضمن خط تقييم المزايدة الكامل. كل جزء من الألف من الثانية يُنفق على الاستدلال لا يبقى متاحًا لبقية منطق المزايدة.

ONNX Runtime مع نماذج INT8 المكمّمة يقدم أفضل موازنة بين زمن الاستجابة والدقة:

  • استخراج السمات من طلب المزايدة في أقل من 0.5ms باستخدام مخازن سمات محسوبة مسبقًا تضم إشارات المستخدم والسياق
  • استدلال النموذج خلال 1-2ms عبر تقييم ONNX على دفعات مع تنفيذ مثبَّت على خيوط محددة — بلا تبديل سياق أثناء التسجيل
  • معايرة الدرجة وحساب سعر المزايدة في أقل من 0.5ms باستخدام منحنيات أسعار محسوبة مسبقًا لكل فئة حملة
  • تُنشر تحديثات النموذج عبر تبديل blue-green — يُحمَّل النموذج الجديد في وضع الظل، ويُتحقق منه مقابل تنبؤات الإنتاج، ثم يُستبدل بعملية ذرية واحدة
تعذّر تحميل الصورة
استدلال ML عند 100K QPS يتطلب تقديم نماذج محسَّنًا للعتاد بلا أي عبء تخصيص للذاكرة

المراقبة على نطاق واسع دون إضافة عبء إلى مسار المزايدة

التسجيل التقليدي عند 100K QPS يولّد حملاً أكبر من منطق المزايدة نفسه. ويجب أن تكون منظومة المراقبة بالحرص نفسه على الأداء الذي يُبنى به التطبيق:

  • جمع المقاييس بالعيّنات - سجّل طلبًا واحدًا من كل 1,000 بالتفصيل، وجمّع البقية في عدّادات ومدرّجات تكرارية تُحدَّث ذريًا
  • تتبّع آني للمئينات عند p50 وp95 وp99 لكل منطقة، ولكل ad exchange، ولكل فئة حملة
  • قواطع آلية تسحب نسخة المزايد من الدوران عندما تتجاوز أزمنة استجابتها p99 مهلة منصة التبادل
  • كشف الشذوذ في هبوط معدل المزايدة وتغيّر معدل الفوز وانحرافات سرعة الإنفاق - يلتقط النماذج القديمة وتدهور الشبكة أسرع من مراقبة معدل الأخطاء

تغطية جانب SSP من معادلة المزاد

وتواجه منصة جانب العرض المسألة المعكوسة. فهي تبثّ طلبات المزايدة إلى عشرات المزايدين، وتجمع الردود، وتقيّم الأسعار الدنيا، وتدير المزاد، وتعيد الفائز - كل ذلك ضمن مهلتها الضيقة.

فرق تطوير SSP تواجه تعقيدًا إضافيًا:

  • يعني Header bidding تشغيل عدة مزادات على التوازي - ومهلة كل مزايد هي ميزانية زمن الاستجابة لدى SSP
  • تحسين السعر الأدنى بنماذج التعلم الآلي يجب أن ينفَّذ داخل نافذة المزاد نفسها دون إضافة زمن استجابة
  • منطق مزاد عالي الأداء يقيّم 20-50 استجابة مزايدة لكل ظهور، ويختار الفائز في أقل من 1ms

الإعلان البرمجي على نطاق واسع يفرض على طرفَي المزاد تحسينًا دؤوبًا لخفض زمن الاستجابة.

تكييف بنية المزايدة لمخزون تطبيقات الجوال وداخل التطبيقات

تحمل طلبات المزايدة داخل التطبيقات إشارات مختلفة عن طلبات الويب. فمعرّفات مستوى الجهاز (حيث تتوفر) وسياق التطبيق وقابلية الرؤية المُبلَّغ عنها عبر SDK تحلّ محل الإشارات القائمة على الكوكيز.

نماذج معدل النقر المدرَّبة على مخزون الويب تحتاج إلى إعادة تدريب لسياقات داخل التطبيقات، حيث تختلف أنماط تفاعل المستخدم اختلافًا كبيرًا.

  • نمذجة الإسناد على الجوال تتطلب تكامل postback من خادم إلى خادم مع MMPs
  • إزالة التكرار عبر نوافذ إسناد متعددة تمنع احتساب التحويلات مرتين
  • تسوية المطابقة الاحتمالية والحتمية تعمل بشكل غير متزامن - وتعود النتائج إلى نموذج المزايدة خلال 24 ساعة

منصة المزايدة الفورية المبنية لمخزون الويب وحده تترك 40-60% من إنفاق الإعلانات البرمجية دون استفادة. المخزون على الجوال وداخل التطبيقات يتطلب استثمارًا في بنية تحتية مخصصة.

هل لديك تصميم مشابه على الطاولة؟

أحضر بنيتك الحالية وسيناريو الفشل الذي يقلقك، وسنراجعه معًا خلال نصف ساعة.