بما أنّ Google Chat API هي خدمة مشترَكة، نفرض حصصًا وقيودًا للتأكّد من أنّ جميع المستخدمين يستفيدون منها بشكل عادل ولحماية الأداء العام لـ Google Workspace.
في حال تجاوزت الحصة، ستتلقّى استجابة برمز حالة HTTP 429: Too many requests
. قد تؤدي عمليات التحقّق الإضافية من الحدّ الأقصى لعدد الطلبات في الخلفية إلى ظهور استجابة الخطأ نفسها. في حال حدوث هذا الخطأ، عليك استخدام خوارزمية التراجع الأسي وإعادة المحاولة لاحقًا. ما دمت تلتزم بالحِصص المحدّدة لكل دقيقة والمدرَجة في الجداول التالية، لن يكون هناك حدّ لعدد الطلبات التي يمكنك إرسالها في اليوم.
قد تنطبق أنواع حصص متعددة على طرق Chat API: حصص لكل مشروع، وحصص لكل مساحة، وحصص لكل مستخدم.
الحصص لكل مشروع
تضع الحصص لكل مشروع حدًا لعدد طلبات البحث في مشروع Google Cloud، وبالتالي تنطبق على تطبيق Chat واحد يستدعي طرق Chat API المحدّدة لكل حصة.
يوضّح الجدول التالي حدود طلبات البحث لكل مشروع. يمكنك أيضًا الاطّلاع على هذه الحدود في صفحة الحصص.
الحصة لكل مشروع |
طُرق واجهة برمجة التطبيقات للدردشة |
الحدّ الأقصى (كل 60 ثانية) |
---|---|---|
عدد عمليات كتابة الرسائل في الدقيقة |
|
3000 |
عدد الرسائل المقروءة في الدقيقة |
|
3000 |
عمليات الكتابة في العضوية في الدقيقة |
|
300 |
عدد قراءات الأعضاء في الدقيقة |
|
3000 |
عدد عمليات الكتابة في المساحة في الدقيقة |
|
60 |
عدد قراءات المساحة في الدقيقة |
|
3000 |
عمليات الكتابة في المرفقات في الدقيقة |
|
600 |
عدد عمليات قراءة المرفقات في الدقيقة |
|
3000 |
عدد عمليات كتابة التفاعلات في الدقيقة |
|
600 |
عدد التفاعلات في الدقيقة |
|
3000 |
الحصص لكل مساحة
تفرض الحصص لكل مساحة حدًا على معدّل طلبات البحث في مساحة معيّنة، وتتم مشاركتها بين جميع تطبيقات Chat التي تعمل في تلك المساحة وتستدعي طرق Chat API المُدرَجة لكل حصة.
يوضّح الجدول التالي حدود طلبات البحث لكل مساحة:
الحصة المخصّصة لكل مساحة |
طُرق واجهة برمجة التطبيقات للدردشة |
الحدّ الأقصى (كل 60 ثانية) |
---|---|---|
عدد القراءات في الدقيقة |
|
900 |
عمليات الكتابة في الدقيقة |
|
60 |
حصص لكل مستخدم
تحدّ حصص المستخدمين من معدّل طلبات البحث لمستخدم Google Chat. تتعلّق طلبات البحث بجميع تطبيقات Chat التي تستدعي إحدى طرق Chat API نيابةً عن مستخدم (باستخدام مصادقة المستخدم).
يوضّح الجدول التالي الحدود القصوى لطلبات البحث لكل مستخدم:
الحصة لكل مستخدم |
طُرق واجهة برمجة التطبيقات للدردشة |
الحدّ الأقصى (كل 60 ثانية) |
---|---|---|
عدد القراءات في الدقيقة |
|
900 |
عمليات الكتابة في الدقيقة |
|
60 |
حدود الاستخدام الإضافية
تتوفّر حدود حصص إضافية لإنشاء مساحات من النوع GROUP_CHAT
أو SPACE
(باستخدام الطريقتَين spaces.create
أو spaces.setup
).
إنشاء أقل من 35 مساحة في الدقيقة و800 مساحة في الساعة من هذه الأنواع لا تخضع المساحات من النوع DIRECT_MESSAGE
لحدود الحصة الإضافية هذه.
يمكن أن يؤدي استهداف مساحة معيّنة من خلال عدد كبير من الزيارات إلى واجهة برمجة التطبيقات إلى فرض حدود داخلية إضافية لا تظهر في صفحة الحصص.
حلّ أخطاء الحصة المستندة إلى الوقت
بالنسبة إلى جميع الأخطاء المستندة إلى الوقت (الحد الأقصى لعدد N من الطلبات كل X دقيقة)، ننصح بأن يرصد الرمز البرمجي الاستثناء ويستخدم تراجعًا أسيًا مقتطعًا للتأكّد من أنّ أجهزتك لا تُحمّل عبئًا مفرطًا.
التمهّل الأسي هو استراتيجية معيارية للتعامل مع الأخطاء في تطبيقات الشبكة. تعيد خوارزمية الرقود الأسي الثنائي محاولة إرسال الطلبات باستخدام فترات انتظار متزايدة بشكل أسي بين الطلبات، وذلك حتى بلوغ الحد الأقصى لوقت الرقود الأسي الثنائي. إذا استمر تعذُّر تنفيذ الطلبات، من المهم زيادة حالات التأخير بين الطلبات بمرور الوقت إلى أن يتم تنفيذ الطلب بنجاح.
مثال على الخوارزمية
تعيد خوارزمية الرقود الأسي الثنائي محاولة إرسال الطلبات بشكل أسي، ما يؤدي إلى زيادة وقت الانتظار بين عمليات إعادة المحاولة إلى أن يصل إلى الحد الأقصى لوقت الرقود الأسي الثنائي. على سبيل المثال:
- إرسال طلب إلى Google Chat API
- في حال تعذُّر تنفيذ الطلب، انتظِر لمدة 1 +
random_number_milliseconds
وأعِد محاولة تنفيذ الطلب. - في حال تعذّر إرسال الطلب، انتظِر لمدة 2 +
random_number_milliseconds
وأعِد محاولة إرساله. - في حال تعذّر إكمال الطلب، انتظِر 4 +
random_number_milliseconds
وأعِد محاولة إرساله. - وهكذا، حتى
maximum_backoff
مرة. - واصِل الانتظار وإعادة المحاولة حتى بلوغ الحدّ الأقصى لعدد المحاولات، ولكن لا تزد فترة الانتظار بين المحاولات.
where:
- يبلغ وقت الانتظار
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.
لمزيد من المعلومات، يُرجى الاطّلاع على المراجع التالية: