بما أنّ Google Workspace Events API هي خدمة مشترَكة، نطبّق حصصًا وقيودًا للتأكد من أنّ جميع المستخدمين يستخدمونها بشكل عادل ولحماية الأداء العام في Google Workspace.
إذا تجاوزت حصة معيّنة، ستتلقّى الاستجابة 429: Too many requests
لحالة HTTP. قد تؤدي أيضًا عمليات التحقق الإضافية من حدود الأسعار في الواجهة الخلفية لواجهة Google Workspace Events API إلى إنشاء استجابة الخطأ نفسها. إذا حدث هذا الخطأ، يجب استخدام خوارزمية
التراجع الأسي
وإعادة المحاولة لاحقًا. وطالما تبقى ضمن الحصص المحددة لكل دقيقة والمذكورة في
الجداول التالية، ليس هناك حد أقصى لعدد الطلبات التي يمكنك إجراؤها
يوميًا.
الحصص لكل مشروع
تحدّ الحصص لكلّ مشروع من معدّل طلبات البحث لمشروع Google Cloud، وبالتالي تنطبق على تطبيق واحد يستدعي طرق Google Workspace Events API المحدّدة لكل حصة.
يعرض الجدول التالي تفاصيل حدود طلبات البحث لكل مشروع. يمكنك أيضًا العثور على هذه الحدود في صفحة الحصص في Google Cloud Console.
الحصة لكل مشروع |
طرق واجهة برمجة تطبيقات أحداث Google Workspace |
الحدّ المسموح به |
---|---|---|
الكتابة في الدقيقة |
|
600 |
الكتابة في الدقيقة لكل مستخدم |
|
100 |
عدد مرّات القراءة في الدقيقة |
|
600 |
عدد مرّات القراءة في الدقيقة لكل مستخدم |
|
100 |
حلّ أخطاء الحصص المستندة إلى الوقت
بالنسبة إلى جميع الأخطاء المستندة إلى الوقت (بحد أقصى N طلب في X دقيقة)، ننصح بأن يلتقط الرمز الخاص بك الاستثناء ويستخدم تراجع أسّي مقتطع للتأكّد من أنّ الأجهزة لا تحمّل حِملًا زائدًا.
يعد التراجع الأسي استراتيجية قياسية لمعالجة الأخطاء لتطبيقات الشبكة. تعيد خوارزمية التراجع الأسي محاولة إعادة محاولة إرسال الطلبات باستخدام فترات انتظار متزايدة بين الطلبات، وصولاً إلى الحد الأقصى لوقت التراجع. إذا لم تنجح الطلبات إلى الآن، من المهم أن تزيد حالات التأخير بين الطلبات بمرور الوقت إلى أن يتم قبولها.
مثال على الخوارزمية
تعمل خوارزمية التراجع الأسي على إعادة محاولة تنفيذ الطلبات بشكل كبير، ما يزيد من وقت الانتظار بين عمليات إعادة المحاولة وصولاً إلى الحد الأقصى لوقت التراجع. مثال:
- يمكنك تقديم طلب إلى Google Workspace Events API.
- إذا تعذّر إجراء الطلب، يُرجى الانتظار 1 +
random_number_milliseconds
ثم إعادة محاولة الطلب. - إذا تعذّر إجراء الطلب، انتظر 2 +
random_number_milliseconds
ثم أعِد محاولة إجراء الطلب. - إذا تعذّر إجراء الطلب، انتظر 4 +
random_number_milliseconds
ثم أعِد محاولة إجراء الطلب. - وهكذا، حتى مرة واحدة (
maximum_backoff
). - يمكنك مواصلة الانتظار وإعادة المحاولة لتصل إلى الحد الأقصى لعدد عمليات إعادة المحاولة، ولكن لا تزيد فترة الانتظار بين عمليات إعادة المحاولة.
المكان:
- يبلغ وقت الانتظار
min(((2^n)+random_number_milliseconds), maximum_backoff)
، مع زيادةn
بمقدار 1 لكل تكرار (طلب). random_number_milliseconds
هو عدد عشوائي بالمللي ثانية أقل من أو يساوي 1,000. ويساعد ذلك في تجنُّب الحالات التي تتم فيها مزامنة العديد من البرامج في بعض الحالات، ثم إعادة المحاولة في آنٍ واحد وإرسال الطلبات في موجات متزامنة. يُعاد احتساب قيمةrandom_number_milliseconds
بعد كل طلب لإعادة المحاولة.- تتراوح مدّة "
maximum_backoff
" عادةً بين 32 أو 64 ثانية. وتعتمد القيمة المناسبة على حالة الاستخدام.
يمكن للعميل متابعة إعادة المحاولة بعد الوصول إلى الوقت maximum_backoff
.
لا تحتاج عمليات إعادة المحاولة بعد هذه المرحلة إلى مواصلة زيادة وقت التراجع. على سبيل المثال، إذا كان العميل يستخدم وقت maximum_backoff
مدّته 64 ثانية، يمكن للعميل إعادة المحاولة كل 64 ثانية بعد الوصول إلى هذه القيمة. وفي مرحلة ما،
يجب أن يُمنع العملاء من إعادة المحاولة إلى أجل غير مسمى.
يعتمد وقت الانتظار بين عمليات إعادة المحاولة وعدد هذه العمليات على حالة الاستخدام وحالة الشبكة.
طلب زيادة الحصة لكل مشروع
بناءً على استخدام مشروعك للموارد، قد تريد طلب زيادة في الحصة. يُعتبَر طلبات البيانات من واجهة برمجة التطبيقات التي يجريها حساب خدمة على أنّها تستخدم حسابًا واحدًا. لا يضمن التقدّم بطلب للحصول على حصة زائدة الموافقة. قد تستغرق زيادات الحصص الكبيرة وقتًا أطول للموافقة عليها.
لا تملك بعض المشاريع الحصص نفسها. مع تزايد استخدام Google Cloud بمرور الوقت، قد تحتاج إلى زيادة حصصك. إذا كنت تتوقع حدوث زيادة ملحوظة في الاستخدام، يمكنك بشكل استباقي طلب تعديل الحصص من صفحة الحصص في Google Cloud Console.
لمزيد من المعلومات، اطّلِع على المراجع التالية: