الانتقال إلى المحتوى الرئيسي

حدود المعدل

يُحدد حد المعدل الحد الأقصى لعدد الطلبات التي يمكن لتطبيق ما إرسالها إلى API خلال فترة زمنية محددة. هذه الآلية ضرورية للحفاظ على الصحة العامة وموثوقية الخدمات.

لماذا نستخدم تحديد المعدل​

استقرار وأداء API
  • يمنع عميلًا واحدًا من إغراق الخوادم بطلبات مفرطة.
  • يضمن أوقات استجابة متسقة وقابلة للتنبؤ لجميع العملاء.
  • يحمي الخدمات الخلفية من ارتفاعات مرور غير متوقعة.
  • يحافظ على نمط تحميل مستقر ومضبوط على البنية التحتية.
الأمان
  • يعزز الدفاع ضد محاولات الهجوم، مثل القوة الغاشمة.
  • يُخفف من خطر الحرمان من الخدمة الموزع (DDoS).
  • يُقلل من التأثير الناجم عن تكاملات ضعيفة التنفيذ.
  • يُحدد الضرر المحتمل الناجم عن بيانات اعتماد API المخترقة.
تخصيص الموارد
  • يضمن وصولًا متوازنًا إلى موارد API لجميع العملاء.
  • يمنع الاستخدام المفرط من قِبل البعض من تدهور تجربة المستخدمين الآخرين.
  • يسمح بتحديد أولويات حركة المرور وفق معايير واحتياجات الأعمال.
  • يُشجع على ممارسات استهلاك API أكثر كفاءة واستدامة.

كيف يعمل تحديد المعدل​

كل استدعاء API يُحتسب ضمن حد الطلبات المسموح به في الثانية. القيمة الافتراضية هي 10 RPS لكل مستأجر. عند تجاوز الحد، تُعيد API HTTP 429 Too Many Requests.

تأكيد مع فريق التأهيل الخاص بك

الحدود الدقيقة تُهيأ لكل مستأجر. تواصل مع فريق التأهيل الخاص بك لتأكيد الحدود المُطبقة على حسابك قبل التخطيط للتكاملات ذات الإنتاجية العالية.

معالجة أخطاء 429​

طلب زيادة حد المعدل

إذا كانت عمليتك ستشهد زيادة في حجم الطلبات (مؤقتة أو دائمة)، أخطر فريق Unico لرفع حد المعدل لبيئتك. يجب تقديم هذا الطلب قبل حدوث الزيادة الفعلية في الحجم لتجنب توقف تطبيقك.

مراجعة سلوك التطبيق
  • افحص الكود لتحديد أنماط استخدام API غير الفعّالة.
  • ابحث عن حلقات غير مقصودة أو استدعاءات API متكررة.
  • وزّع الطلبات بشكل أكثر انتظامًا عبر الزمن بدلًا من إرسالها في موجات كبيرة.
تطبيق التخزين المؤقت
  • خزّن مؤقتًا البيانات المُطلَبة بتكرار والتي نادرًا ما تتغير.
  • استخدم رمز وصول OAuth2 لكامل مدة صلاحيته البالغة ساعة واحدة — لا تستدعي POST /oauth2/token لكل طلب.
  • طبّق استراتيجيات مناسبة لإبطال التخزين المؤقت.
استخدام Webhooks بدلًا من الاستطلاع

اشترك في Webhooks والأحداث لـ PROCESS_STATE_FINISHED بدلًا من استطلاع GET /client/v1/process/\{id\}. يمكن لحلقة الاستطلاع أن تُنهك بسهولة ميزانية GET-process عند كثرة حركة المرور.

ما يحدث عند الوصول إلى الحد​

تُعيد المنصة:

HTTP/1.1 429 Too Many Requests
Retry-After: 12
الترويسةالمعنى
Retry-Afterعدد الثواني للانتظار قبل إعادة المحاولة. احترمه.

إذا كانت Retry-After غائبة، استخدم التراجع الأسي (1 ثانية، 2 ثانية، 4 ثوانٍ، 8 ثوانٍ، …) بحد أقصى 60 ثانية.

اعتبارات التزامن​

تُحدد حدود المعدل الطلبات في الدقيقة، لكن المنصة لديها أيضًا حدود التزامن على مستوى البنية التحتية. حتى لو كان لديك ميزانية لـ 100 طلب/دقيقة، فإن إرسال الـ 100 جميعها في نفس الثانية أكثر احتمالًا للرفض من توزيعها على مدار الدقيقة.

للتكاملات ذات الإنتاجية العالية، استهدف معدل RPS ثابتًا بدلًا من الموجات.

لدى Trully حصص تسليم خاصة بها لـ Webhook V2. يُتوقع من خادم Webhook الاستجابة خلال دقيقة واحدة؛ الاستجابات الأبطأ تُسقط (لا تتأثر عملية المستخدم). للمعالجة المتسقة، اعترف بـ Webhook بسرعة وقم بمعالجته بشكل غير متزامن.

ما التالي​

آخر تحديث في