تخطي إلى المحتوى
Guide

تحديد معدل واجهة برمجة التطبيقات (API): 4 خوارزميات يجب أن يعرفها كل مطور

| 9 min read

تم شرح النافذة الثابتة والنافذة المنزلقة ودلو الرمز المميز ودلو التسريب باستخدام الرسوم البيانية ورؤوس X-RateLimit ومنطق إعادة محاولة Node.js الذي يمكنك نسخه ولصقه.

Data visualization with streaming lines and analytics
Photo by Joshua Sortino on Unsplash

تقوم المهمة المجمعة الخاصة بك باستقبال 200 طلب في 3 ثوانٍ ويتم إرجاع كل استجابة 429 Too Many Requests. يقوم معالج webhook الخاص بك بضرب واجهة برمجة تطبيقات تابعة لجهة خارجية ويتم حظره لمدة 15 دقيقة. تكامل العميل يصبح صامتًا لأن حلقة إعادة المحاولة الخاصة بهم تستهلك الحصة اليومية في الساعة الأولى. حصة هذه الإخفاقات سبب جذري واحد: الكود لا يحترم حدود المعدل.

يغطي هذا الدليل خوارزميات تحديد المعدل الأساسية الأربعة، ويوضح لك كيفية القراءة X-RateLimit الرؤوس من أي واجهة برمجة تطبيقات، ويمنحك نسخة ولصق كود Node.js لإعادة محاولة المنطق مع التراجع الأسي.

خوارزميات تحديد المعدل الأربعة

يجيب كل محدد للسعر على نفس السؤال: "هل يجب قبول هذا الطلب أم يجب علي رفضه؟" تختلف الخوارزميات الأربع في كيفية تتبع الوقت والتعامل مع الدفقات.

1. نافذة ثابتة

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

من السهل إنشاء نافذة ثابتة: عداد واحد وطابع زمني واحد لكل عميل. العيب هو مشكلة الحدود. يمكن للعميل إرسال الحد الكامل في نهاية نافذة واحدة والحد الكامل في بداية اليوم التالي، احصل على ضعف المعدل المقصود في فترة قصيرة. واجهة برمجة التطبيقات الأقدم لـ GitHub يستخدم محدد المعدل النوافذ الثابتة؛ لقد انتقلوا منذ ذلك الحين إلى أساليب أكثر تطوراً.

2. نافذة منزلقة

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

نافذة منزلقة تقضي على مشكلة انفجار الحدود. التكلفة أعلى للذاكرة: حيث تقوم بتخزين طابع زمني لكل طلب، وليس عداد واحد. ريديس ZRANGEBYSCORE يجعل هذا عمليًا على نطاق واسع. تستخدم Cloudflare والعديد من بوابات API النوافذ المنزلقة لحدود المعدل لكل مستخدم.

3. دلو رمزي

تصور دلوًا يحمل الرموز. كل طلب يكلف رمزا واحدا. إعادة تعبئة الرموز بمعدل ثابت. إذا كان الجرافة فارغًا، فسيتم رفض الطلب. إذا كان الدلو ممتلئًا، فلن تتراكم الرموز المميزة الزائدة.

دلو الرمز المميز هو الخوارزمية الأكثر شيوعًا في الإنتاج. Stripe وAWS API Gateway ومعظم الخدمات السحابية يستخدم مقدمو الخدمة متغيرات منه. تتحكم سعة الجرافة في حجم الانفجار، كما تتحكم في معدل إعادة الملء الإنتاجية المستدامة. تمنحك المعلمتان تحكمًا دقيقًا في شكل حركة المرور.

4. دلو متسرب

عكس دلو الرمز المميز. الطلبات تملأ دلوًا. يستنزف الدلو بمعدل ثابت. إذا يفيض الدلو، ويتم رفض الطلبات الزائدة. يبقى معدل الإخراج ثابتا بغض النظر عن المدخلات رشقات نارية.

تعمل الجرافة المتسربة بشكل جيد لتشكيل حركة المرور حيث تحتاج إلى معدل إخراج ثابت: عمال قائمة الانتظار، تسليم webhook، وخطوط أنابيب ترميز الفيديو. المقايضة هي أن يتم وضع الرشقات في قائمة الانتظار بدلاً من ذلك من خدم؛ الكمون يزيد تحت الحمل.

مقارنة الخوارزميات الأربعة

خوارزمية انفجار مسموح؟ ذاكرة حالة الاستخدام الشائع
نافذة ثابتة رشقات نارية على الحافة (2x عند الحدود) منخفض (عداد واحد) عدادات بسيطة، والتحليلات
نافذة منزلقة على نحو سلس، لا توجد طفرات الحدود متوسط ​​(الطابع الزمني لكل طلب) حدود واجهة برمجة التطبيقات (API) لكل مستخدم
دلو رمزي رشقات نارية تسيطر عليها تصل إلى القدرة منخفض (قيمتان) معظم واجهات برمجة تطبيقات الإنتاج (Stripe، AWS)
دلو متسرب في قائمة الانتظار، معدل إخراج ثابت متوسطة (قائمة الانتظار) تشكيل حركة المرور، والعمال في طوابير

قراءة رؤوس X-RateLimit

تتضمن معظم واجهات برمجة التطبيقات معلومات حد المعدل في رؤوس الاستجابة. ثلاثة رؤوس تخبرك بكل شيء تحتاج إلى البقاء تحت الحد:

  • X-RateLimit-Limit: الحد الأقصى للطلبات المسموح بها لكل نافذة
  • X-RateLimit-Remaining: الطلبات التي تركتها في النافذة الحالية
  • X-RateLimit-Reset: الطابع الزمني لنظام Unix (بالثواني) عند إعادة ضبط النافذة

عندما تتجاوز الحد، تكون حالة الاستجابة 429 Too Many Requests و Retry-After يخبرك الرأس بعدد الثواني التي يجب الانتظار فيها.

جربه ضد واجهة برمجة تطبيقات botoi. يقوم أمر الضفيرة هذا بتجزئة السلسلة وطباعة رؤوس الحد الأقصى للمعدل:

رؤوس الاستجابة:

يخبرك هذا أن الحد الأقصى هو 5 طلبات لكل نافذة، ويتبقى لديك 4 طلبات بعد هذا الطلب، و تتم إعادة ضبط النافذة عند الطابع الزمني المحدد لنظام Unix. تتبع هذه القيم في عميل HTTP الخاص بك لتجنب الاصطدام 429s في المقام الأول.

نصيحة: يتحول X-RateLimit-Reset إلى وقت الانتظار: waitMs = (resetTimestamp - Math.floor(Date.now() / 1000)) * 1000

أعد محاولة المنطق مع التراجع الأسي في Node.js

عندما تصل إلى 429، لا تعيد المحاولة على الفور. حلقة إعادة المحاولة الضيقة تجعل المشكلة أسوأ: عليك البقاء معدل محدود لفترة أطول وسيقوم الخادم بوضع علامة مسيئة عليك. استخدم التراجع الأسي مع الارتعاش بدلاً من ذلك.

استخدمه مع أي نقطة نهاية:

تقوم الوظيفة بالتحقق من وجود أ Retry-After الرأس أولاً. إذا أخبرك الخادم كم من الوقت للانتظار، واحترام ذلك. في حالة عدم وجود رأس، فإنه يعود إلى التراجع الأسي: ثانية واحدة، ثانيتان، 4 ثواني، 8 ثواني. الارتعاش العشوائي (0-500 مللي ثانية) يمنع مشكلة القطيع الهادر حيث يوجد المئات يقوم العملاء بإعادة المحاولة في نفس اللحظة بالضبط.

الاختناق الاستباقي: تجنب 429s قبل حدوثها

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

يتتبع محدد المعدل من جانب العميل الطوابع الزمنية للطلب في نافذة منزلقة. قبل كل طلب، يتحقق مما إذا كانت النافذة ممتلئة وينتظر إذا لزم الأمر. يمكنك إرسال الطلبات على أقصى قدر من الأمان معدل دون واحد 429.

نموذج تحديد معدل بوتوي

يستخدم Botoi نظامًا لتحديد المعدل من مستويين:

يخطط انفجار (في الدقيقة) الحصة النسبية مصادقة
مجاني (0 دولار) 5 متطلبات/دقيقة 100/يوم لا شيء (يعتمد على IP)
المبتدئين (9 دولارات شهريًا) 30 طلب/دقيقة 300,000 / شهر مفتاح واجهة برمجة التطبيقات
برو (49 دولارًا / شهرًا) 300 طلب/دقيقة 3,000,000/شهر مفتاح واجهة برمجة التطبيقات
الأعمال (199 دولارًا شهريًا) 1000 طلب/دقيقة 30,000,000/شهر مفتاح واجهة برمجة التطبيقات

يتتبع الوصول المجهول الطلبات حسب عنوان IP. تتم إعادة تعيين العدد اليومي عند منتصف الليل بالتوقيت العالمي المنسق عبر أ عداد Cloudflare KV. تستخدم الطلبات التي تمت مصادقتها مفتاح واجهة برمجة التطبيقات (API) لتحديد الهوية وتحديد الحدود يتم تنفيذها من خلال أونكي محدد معدل دلو الرمز المميز على الحافة.

كل رد من api.botoi.com يشمل الثلاثة X-RateLimit رؤوس الموصوفة أعلاه، لذا فإن منطق إعادة المحاولة الخاص بك يعمل بنفس الطريقة بغض النظر عن الخطة.

أساليب مجربة لمستهلكي واجهة برمجة التطبيقات (API).

  • اقرأ العناوين الموجودة في كل رد. لا تحدد حدود معدل التعليمات البرمجية من الوثائق. تغير واجهات برمجة التطبيقات الحدود دون إشعار. العناوين هي مصدر الحقيقة.
  • استخدم التراجع الأسي مع الارتعاش. تتسبب الفواصل الزمنية لإعادة المحاولة الثابتة في المزامنة إعادة المحاولة عبر العملاء. ينشر التوتر الحمل.
  • دفعة حيث تدعمها واجهة برمجة التطبيقات (API). طلب واحد يحتوي على 10 عناصر يكلف حدًا واحدًا للسعر رمز مميز. عشرة طلبات فردية تكلف 10.
  • ردود ذاكرة التخزين المؤقت. إذا لم تتغير البيانات بين الطلبات، فقم بتخزين النتيجة وتخطي استدعاء API. نادرًا ما تتغير سجلات DNS وشهادات SSL وبيانات WHOIS خلال دقائق.
  • استخدم قائمة الانتظار للعمل في الخلفية. لا تطلق مكالمات API من حلقة فعالة. ادفع العمل على قائمة انتظار (BullMQ، SQS، Cloudflare Queues) ومعالجة العناصر بمعدل يتم التحكم فيه.
  • مراقبة حصتك المتبقية. سجل X-RateLimit-Remaining لك لوحة المقاييس. قم بتعيين تنبيه عند انخفاضه عن 20% من الحد الأقصى.

النقاط الرئيسية

  • أربع خوارزميات تهيمن. النافذة الثابتة هي الأبسط. دلو الرمز المميز هو الأكثر شيوعًا. نافذة منزلقة تقضي على رشقات نارية الحدود. دلو متسرب ينعم الإخراج.
  • رؤوس X-RateLimit هي واجهة برمجة التطبيقات الخاصة بك. يقرأ Limit, Remaining، و Reset على كل استجابة للبقاء تحت الحد الأقصى.
  • التراجع الأسي مع مقابض الارتعاش 429s. انسخ fetchWithRetry الوظيفة المذكورة أعلاه في قاعدة التعليمات البرمجية الخاصة بك ولف كل استدعاء واجهة برمجة التطبيقات الخارجية.
  • الاختناق الاستباقي يمنع 429s. قم بتسريع طلباتك من جانب العميل بدلاً من انتظار رد الخادم.
  • لا يوجد حساب مطلوب للاختبار. ضرب أي نقطة نهاية botoi في api.botoi.com مع 5 طلبات مجانية في الدقيقة لرؤية رؤوس حدود المعدل قيد التنفيذ.

FAQ

ما هو تحديد معدل واجهة برمجة التطبيقات (API) ولماذا تستخدمه واجهات برمجة التطبيقات (API)؟
يحدد السعر عدد الطلبات التي يمكن للعميل تقديمها في نافذة زمنية. تستخدمها واجهات برمجة التطبيقات لحماية الخوادم من التحميل الزائد، ومنع إساءة الاستخدام، وضمان المشاركة العادلة للموارد بين العملاء، والحفاظ على إمكانية التنبؤ بتكاليف البنية التحتية. وبدون ذلك، يمكن لعميل واحد أن يجوع الآخرين جميعاً.
ماذا تعني رؤوس X-RateLimit؟
X-RateLimit-Limit هو الحد الأقصى للطلبات المسموح بها لكل نافذة. X-RateLimit-Remaining هو العدد المتبقي لديك. X-RateLimit-Reset هو طابع زمني لنظام Unix عند إعادة ضبط النافذة. تخبرك "إعادة المحاولة بعد" (على 429 ردًا) بعدد الثواني التي يجب عليك الانتظار قبل إعادة المحاولة.
كيف يمكنني التعامل مع استجابة 429 طلبًا كثيرًا جدًا؟
اقرأ رأس "إعادة المحاولة بعد" وانتظر عدة ثوانٍ. في حالة عدم وجود رأس "إعادة المحاولة بعد"، استخدم التراجع الأسي: انتظر ثانية واحدة بعد أول 429، وثانيتين بعد الثانية، و4 بعد الثالثة، وهكذا. قم بإضافة ارتعاش عشوائي (0-500 مللي ثانية) لمنع مشاكل القطيع المدوية عندما يعيد العديد من العملاء المحاولة في نفس الوقت.
ما هي خوارزمية تحديد المعدل الأكثر شيوعًا؟
تعد مجموعة الرمز المميز هي الأكثر شيوعًا في واجهات برمجة تطبيقات الإنتاج. يستخدم Stripe وAWS ومعظم موفري الخدمات السحابية أشكالًا مختلفة منه. تسمح مجموعة الرمز المميز بتدفقات يتم التحكم فيها مع فرض معدل مستدام، والذي يطابق أنماط حركة المرور الحقيقية بشكل أفضل من النوافذ الثابتة.
هل يحد معدل botoi من الطلبات المجهولة؟
نعم. تحصل الطلبات المجهولة (بدون مفتاح API) على 5 طلبات في الدقيقة و100 طلب يوميًا، ويتم تتبعها بواسطة عنوان IP. تحصل الطلبات التي تمت مصادقتها على الخطط المدفوعة على حدود أعلى: يسمح Starter بـ 30/دقيقة، ويسمح Pro بـ 300/دقيقة، ويسمح Business بـ 1000/دقيقة.

ابدأ البناء مع botoi

أكثر من 150 نقطة نهاية API للبحث ومعالجة النصوص وتوليد الصور وأدوات المطورين. باقة مجانية، بدون بطاقة ائتمان.

عرض وثائق API تصفح جميع الأدوات