تفرض Google Ads API حدًا على معدّل الطلبات حسب عدد الاستعلامات في الثانية (QPS) على كلٍّ من أرقام تعريف العملاء ومشاريع Google Cloud بشكلٍ مستقل. بالإضافة إلى الطلبات في الدقيقة (التي تقيس مدى تكرار طلبات واجهة برمجة التطبيقات)، تفرض Google Ads API أيضًا حدودًا على العمليات في الدقيقة (التي تقيس إجمالي عدد عمليات واجهة برمجة التطبيقات في جميع الطلبات). تستخدم Google Ads API خوارزمية حاوية الرموز المميّزة لقياس الطلبات وتحديد حدّ مناسب لعدد الاستعلامات في الثانية، لذا يختلف الحدّ الدقيق استنادًا إلى حمولة الخادم الإجمالية في أي وقت معيّن.
الغرض من فرض حدود على معدّل الطلبات هو منع مستخدم واحد من تعطيل الخدمة لمستخدمين آخرين من خلال إغراق خوادم Google Ads API بكمية كبيرة من الطلبات (سواء كان ذلك عن قصد أو عن غير قصد).
يتم رفض الطلبات التي تنتهك حدود معدّل الطلبات مع ظهور الخطأ:
RESOURCE_TEMPORARILY_EXHAUSTED.
يمكنك التحكّم في تطبيقك وتخفيف حدود معدّل الطلبات من خلال تقليل عدد الطلبات بشكلٍ نشط وتقييد عدد الاستعلامات في الثانية من جهة العميل.
هناك عدد من الطرق لتقليل فرص تجاوز حدّ معدّل الطلبات. يمكن أن يساعدك التعرّف على مفاهيم أنماط التكامل في المؤسسات (EIP) ، مثل المراسلة وإعادة التسليم والتقييد، في إنشاء تطبيق عميل أكثر فعالية.
يتم ترتيب أفضل الممارسات المقترَحة التالية حسب درجة التعقيد، حيث تظهر الاستراتيجيات الأبسط في الأعلى والبُنى الأكثر فعالية ولكنها متطورة بعد ذلك:
- خوارزمية الرقود الأسي الثنائي
- الحدّ من المهام المتزامنة
- تجميع الطلبات في دفعة واحدة
- التقييد ومحددات معدّل الطلبات
- الإضافة إلى قائمة المحتوى التالي
خوارزمية الرقود الأسي الثنائي
عندما يتلقّى تطبيقك الخطأ
RESOURCE_TEMPORARILY_EXHAUSTED ، استخدِم سياسة الرقود الأسي الثنائي مع إضافة تأخير عشوائي قبل إعادة محاولة الطلب الذي تعذّر تنفيذه. تزيد خوارزمية الرقود الأسي الثنائي تدريجيًا وقت الانتظار بين عمليات إعادة المحاولة (على سبيل المثال، الانتظار لمدة ثانيتَين، ثم 4 ثوانٍ، ثم 8 ثوانٍ، بالإضافة إلى تأخير عشوائي صغير)، ما يسمح باستعادة حمولة الخادم وحاويات الحصص، مع منع الارتفاعات المتزامنة لعمليات إعادة المحاولة في جميع مثيلات العميل.
الحدّ من المهام المتزامنة
أحد الأسباب الرئيسية لتجاوز حدود معدّل الطلبات هو أنّ تطبيق العميل ينشئ عددًا كبيرًا من المهام المتوازية. على الرغم من أنّنا لا نحدّ من عدد الطلبات المتوازية التي يمكن أن يتلقّاها تطبيق العميل، يمكن أن يؤدي ذلك إلى تجاوز حدّ الطلبات في الثانية على مستوى مشروع على السحابة الإلكترونية من Google Cloud.
يُنصح بضبط حدّ أعلى معقول لإجمالي عدد المهام المتزامنة التي ستُرسِل الطلبات (في جميع العمليات والأجهزة)، وتعديل هذا الحدّ للأعلى لتحسين معدّل نقل البيانات بدون تجاوز حدّ معدّل الطلبات.
علاوةً على ذلك، يمكنك تقييد عدد الاستعلامات في الثانية من جهة العميل (راجِع التقييد ومحددات معدّل الطلبات).
تجميع الطلبات في دفعة واحدة
ننصحك بتجميع عمليات متعددة في طلب واحد. ينطبق ذلك بشكلٍ أساسي على طلبات Mutate لمختلف الخدمات. على سبيل المثال، إذا كنت
تعدِّل حالة عدة مثيلات من AdGroupAd، يمكنك
طلب MutateAdGroupAds مرة واحدة، وإدخال
عدة operations بدلاً من طلب
MutateAdGroupAds مرة واحدة لكل
AdGroupAd. راجِع
إرشادات عمليات الدفعات للحصول على بعض الأمثلة
الإضافية.
على الرغم من أنّ تجميع الطلبات في دفعة واحدة يقلّل من إجمالي عدد طلبات بيانات من واجهة برمجة التطبيقات ويخفّف من حدود معدّل الطلبات على الطلبات في الدقيقة، قد يؤدي ذلك إلى تجاوز حدّ معدّل الطلبات للعمليات في الدقيقة إذا نفّذت عددًا كبيرًا من العمليات على حساب واحد.
التقييد ومحددات معدّل الطلبات
بالإضافة إلى الحدّ من إجمالي عدد سلاسل التعليمات في تطبيقك، يمكنك أيضًا تنفيذ محدّدات معدّل الطلبات من جهة العميل. يضمن ذلك أن تخضع جميع سلاسل التعليمات في جميع العمليات أو المجموعات أو كليهما لحدّ معيّن لعدد الاستعلامات في الثانية من جهة العميل.
راجِع Guava RateLimiter، أو نفِّذ خوارزمية حاوية الرموز المميّزة الخاصة بك لبيئة مجمّعة. على سبيل المثال، يمكنك إدارة الرموز المميّزة في مخزن بيانات موزّع ومنخفض وقت الاستجابة في الذاكرة، مثل Redis أو Memcached، حيث يحصل كل عميل على رمز مميّز ويستخدمه قبل معالجة الطلب. إذا نفدت الرموز المميّزة، ينتظر العميل إلى أن يتم تجديد الدفعة التالية من الرموز المميّزة.
الإضافة إلى قائمة المحتوى التالي
قائمة انتظار الرسائل هي الحلّ لتوزيع حمولة العمليات، مع التحكّم أيضًا في معدّلات الطلبات والمستهلكين. تتوفّر عدة خيارات لقوائم انتظار الرسائل، بعضها برنامج مفتوح المصدر وبعضها مملوك، ويمكن أن يعمل العديد منها مع لغات مختلفة.
عند استخدام قوائم انتظار الرسائل، يمكنك أن يكون لديك عدة منتِجين يرسلون الرسائل إلى قائمة الانتظار وعدة مستهلكين يعالجون هذه الرسائل. يمكن تنفيذ عمليات التقييد من جهة المستهلك من خلال الحدّ من عدد المستهلكين المتزامنين، أو من خلال تنفيذ محدّدات معدّل الطلبات أو عمليات التقييد للمنتِجين أو المستهلكين.
على سبيل المثال، إذا واجه مستهلك رسالة خطأ في معدّل الطلبات، يمكن لهذا المستهلك إعادة الطلب إلى قائمة الانتظار مع تأخير معياري لإعادة المحاولة (باستخدام خوارزمية الرقود الأسي الثنائي) وتعديل حلقة ملاحظات مشترَكة لمحدّد معدّل الطلبات لكي يقلّل جميع المستهلكين تلقائيًا معدّل المعالجة أثناء استرداد البيانات من الخطأ.