حدود المعدل

تحديد المعدل في واجهة X-Radius ليس رقمًا واحدًا. إنه مجموعة صغيرة من النوافذ الثابتة بطول دقيقة، كلٌّ منها يحدّ كلفةً مختلفة، وقد يُحسب الطلب الواحد في أكثر من واحدة منها في آنٍ معًا.

وكل حدّ أدناه عدّادٌ لكل دقيقة في نافذة ثابتة، مشتركٌ بين نسخ الواجهة عبر Redis، فالميزانية للنسخة كلها لا لعمليةٍ واحدة.

كيف يبدو الـ 429

{
  "error": {
    "code": "ERR_RATE_LIMITED",
    "message": "Too many requests. Please slow down and try again shortly.",
    "request_id": "c41e77b920",
    "details": { "reason": "rate_limited" }
  }
}

لا توجد ترويسة Retry-After ولا ترويسة تبلّغ بالميزانية المتبقية. والنافذة دقيقة واحدة، فالبرنامج الذي ينتظر دقيقةً يكون دائمًا داخل نافذة جديدة؛ والتراجع الأسّي ابتداءً من ثوانٍ قليلة مقبول وألطف.

وقيمة details.reason هي دائمًا rate_limited حرفيًا. وهي لا تسمّي الميزانية التي استنفدتها — استنتجها من النقطة التي ناديتها.

الميزانيات الخمس لكل مستأجر

هذه تحدّ المستأجر المصادَق عليه، بمفتاح المستأجر حين تكون بيانات الاعتماد لمدير. وهي التي يلقاها التكامل عمليًا.

وt_mutate يمرّر GET وHEAD وOPTIONS مباشرةً، فلا تكلّفه القراءات شيئًا. أما الأربع الأخرى فمركَّبة على نقاط بعينها بجوار فحص صلاحيتها، ما يعني أن كتابةً ثقيلة واحدة تُحسب في t_mutate و في t_heavy. فخطّط على هذا الأساس: ثلاثون طلب تقرير في الدقيقة لن تستهلك من t_mutate شيئًا لأن التقارير طلبات GET، لكن ثلاثين صفَّ تصدير تستهلك ثلاثين من t_heavy وثلاثين من t_mutate.

وt_values يُحسب في نافذة الدقيقة الثابتة نفسها كغيره، فسقفه في النافذة عشرة مضروبةً في ستين. وهو موجود لأن t_heavy لم يتسع له: فالثقيل ثلاثون في الدقيقة للمستأجر كله وكان مقاسًا لحفنة مديرين يفتحون صفحات تقارير، بينما مسار قيم لوحة القيادة يُستطلع بمؤقّت من كل مدير داخل على اللوحة. فمستأجر بعشرين مقعدًا يستنفد الثقيل في دورة استطلاع واحدة.

الميزانيات تتناسب مع فئة الترخيص

الأرقام أعلاه هي المرجع. وما يحصل عليه المستأجر فعلًا هو المرجع مضروبًا في فئة حصة الموارد في ترخيصه:

وكلٌّ من الميزانيات الخمس يتناسب بالحصة نفسها، فاضرب أي مرجع أعلاه فيها. فمستأجر من فئة small يحصل على 75 كتابةً في الدقيقة مقابل مرجع t_mutate البالغ 300، وعلى نداءَي صادر مقابل خمسة.

والضرب يقرّب لأعلى ولا يبلغ الصفر أبدًا — فمرجعٌ قدره خمسة في الدقيقة عند 25% يصير 2 لا 1. والفئة تُشتقّ من سقف المشتركين المرخَّص ما لم يثبّتها مشغّل: حتى 100 مشترك small، وحتى 1,000 medium، وحتى 10,000 large، وما فوق ذلك أو ترخيص بلا سقف هو xl. أما الفئة max فبالتثبيت الصريح فقط.

والفصل مقصود وأحادي الاتجاه: المشغّل يضبط المرجع، والترخيص يضبط الحصة منه، والمستأجر لا يضبط أيًّا منهما. ولا يوجد نداء في الواجهة يرفع سقفك أنت.

ويستحق استثناء واحد المعرفة: بيانات اعتماد بوابة المشترك توضع في ميزانية لكل مشترك لا لكل مستأجر، ولا تتناسب مع الفئة. فسقفٌ على مستوى المستأجر يجعل أمسيةً مزدحمةً بشحن الكروت تردّ 429 على جمهور المشتركين كله، فيُخنق المشترك المسيء وحده بدلًا من ذلك.

ميزانيات لكل مشغّل على النقاط الحساسة

حفنة من النقاط المصادَق عليها تحمل ميزانيةً خاصة بمفتاح (المستأجر، المدير) لا بالمستأجر. وهي موجودة لأن النقطة أداةُ استقصاء بقدر ما هي عملية — سطحُ تخمين رموز، أو مسحُ فضاء معرّفات، أو إصدارُ بيانات اعتماد — وميزانيةٌ على مستوى المستأجر تتيح لمشغّل واحد إنفاق ميزانية الموقع كله.

وهذه مسطّحة — لا تضاعفها فئة الترخيص، لأنها تحدّ خاصيةً أمنية لا حصةَ موارد.

ولاحظ أن card_timeline يعدّ الاستعلام المرفوض أيضًا. فالمحدِّد مركَّب قبل فحص الرؤية عن قصد: فخلفه كان مسح فضاء المعرّفات بلا أي قياس، وهو بالضبط ما وُجدت الميزانية لمنعه.

النقاط العامة

المسارات غير المصادَق عليها محدودة بعنوان المصدر، بـ 20 في الدقيقة افتراضيًا (PUBLIC_RATE_LIMIT وPUBLIC_RATE_WINDOW)، ولكل نقطة ميزانيتها المسمّاة كي لا يتشارك الدخول وبحث المستأجر ميزانيةً واحدة. والدخول والتسجيل الذاتي وحلّ المضيف وتوفّر الاسم المختصر والكابتشا وعودات الدفع ونماذج الموقع العام كلها من هذا الصنف.

أما نقاط تبادل الدخول الآلي لبوابة المشترك فلها ميزانية منفصلة أعلى — 120 في الدقيقة (PORTAL_ZEROLOGIN_RATE_LIMIT) — لأنها تُنادى عبر مُرحِّل أو من خلف ترجمة عناوين الموقع، حيث يتشارك كل مشترك شرعي عنوان مصدر واحدًا.

كيف تكتب برنامجًا لا يصطدم

• وزّع العمل على النافذة. فالعدّاد نافذة ثابتة لا سلّة رموز، فثلاثمئة كتابة في الثانية الأولى وثلاثمئة في التالية هما نافذتان كاملتان متتاليتان. والمعدّل الثابت أفضل بكثير من الدفعات.
• لا ترقّم لجلب البيانات بالجملة. فحلقة على جدول كبير تحرق ميزانية t_mutate بلا فائدة وستبلغ سقف الإزاحة على أي حال. اصفف مهمة تصدير بدلًا من ذلك.
• استعمل نقاط العمليات الجماعية. فلأكثر المجموعات فعلٌ جماعي يأخذ مصفوفة معرّفات. وPOST /users/bulk-disable واحد بخمسمئة معرّف يكلّف طلبًا واحدًا من t_mutate، بينما خمسمئة نداء منفرد تكلّف خمسمئة ولن تتسع في دقيقة.
• عند 429 تراجع ثم أعد إرسال البايتات نفسها. فإن كانت العملية تحمل request_id فأعد استعماله — انظر منع التكرار. والـ 429 هو صنف الخطأ الوحيد الذي تكون فيه إعادة إرسال البايتات نفسها هي التصرف الصحيح.
• عامل نقاط الفحص والصادر بوصفها أفعالًا يدوية. فبعشرة وخمسة في الدقيقة لترخيص قياسي، هي مقاسة لمشغّل يضغط زرًّا لا لحلقة استطلاع.

وإن كان تكاملك يحتاج فعلًا أكثر مما توفّره الفئة، فالسقف يرفعه مشغّل النسخة على الترخيص، لا عبر الواجهة البرمجية.