حدود الاستخدام

بما أنّ Google Chat API هي خدمة مشتركة، نطبّق الحصص والقيود لضمان استخدام جميع المستخدمين لها بشكل عادل وحماية الأداء العام في خدمات Google Workspace.

وإذا تجاوزت إحدى الحصص، ستتلقّى استجابة رمز حالة HTTP 429: Too many requests. قد تؤدي أيضًا عمليات التحقق الإضافية للحدّ من الأسعار على الخلفية في Chat إلى ظهور استجابة الخطأ نفسها. إذا حدث هذا الخطأ، يجب عليك استخدام خوارزمية الرقود الأسي وإعادة المحاولة لاحقًا. وما دمت تبقى ضمن الحصص المحدّدة لكل دقيقة والمذكورة في الجداول التالية، ليس هناك حد أقصى لعدد الطلبات التي يمكنك تقديمها يوميًا.

ينطبق نوعان من الحصص على طرق Chat API، وهما: الحصص لكل مساحة وحصص لكل مشروع.

الحصص لكلّ مساحة

تحدّ الحصص لكلّ مساحة من معدّل طلبات البحث في مساحة معيّنة، وتتم مشاركتها بين جميع تطبيقات Chat القائمة على طلبات البيانات من خلال طُرق Chat API المدرَجة لكل حصة.

تفاصيل الجدول التالي حول حدود طلبات البحث لكل مساحة:

الحصة لكل مساحة	طرق Chat API	الحدّ الأقصى المسموح به (لكل 60 ثانية، تتم مشاركته بين جميع تطبيقات Chat في المساحة)
عدد مرّات القراءة في الدقيقة	media.download spaces.get spaces.members.get spaces.members.list spaces.messages.get spaces.messages.list spaces.messages.attachments.get spaces.messages.reactions.list	900
الكتابة في الدقيقة	media.upload spaces.delete spaces.patch spaces.messages.create (ينطبق أيضًا على الردود التلقائية الواردة على الويب) spaces.messages.delete spaces.messages.patch spaces.messages.reactions.create spaces.messages.reactions.delete	60

الحصص لكل مشروع

تحد الحصص لكل مشروع من معدل طلبات البحث لمشروع Google Cloud، وبالتالي تنطبق على تطبيق Chat واحد يستدعي طُرق Chat API المحدّدة لكل حصة.

تفاصيل الجدول التالي حدود طلبات البحث لكل مشروع يمكنك أيضًا العثور على هذه الحدود في صفحة الحصص.

الحصة لكل مشروع	طرق Chat API	الحدّ الأقصى (لكل 60 ثانية)
عدد الرسائل التي تمت كتابتها في الدقيقة	spaces.messages.create spaces.messages.patch spaces.messages.delete	3,000
عدد مرّات قراءة الرسائل في الدقيقة	spaces.messages.get spaces.messages.list	3,000
عمليات كتابة العضوية في الدقيقة	spaces.members.create spaces.members.delete	300
عدد القراءات في الدقيقة	spaces.members.get spaces.members.list	3,000
عمليات الكتابة في الفضاء في الدقيقة	spaces.setup spaces.create spaces.patch spaces.delete	60
عدد مرّات القراءة في الدقيقة	spaces.get spaces.list spaces.findDirectMessage	3,000
عدد عمليات الكتابة في المرفق في الدقيقة	media.upload	600
عدد مرات قراءة المرفق في الدقيقة	spaces.messages.attachments.get media.download	3,000
عدد مرّات كتابة التفاعل في الدقيقة	spaces.messages.reactions.create spaces.messages.reactions.delete	600
عدد مرّات قراءة التفاعل في الدقيقة	spaces.messages.reactions.list	3,000

الحدود القصوى للاستخدام

هناك حدود إضافية للحصة المخصّصة لإنشاء مساحات من النوع GROUP_CHAT أو SPACE (باستخدام طريقة spaces.create أو spaces.setup). أنشئ أقل من 35 مساحة في الدقيقة و210 مساحة في الساعة من هذه الأنواع. ولا تخضع المساحات من النوع DIRECT_MESSAGE لحدود الحصص الإضافية هذه.

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

حلّ أخطاء الحصص المستندة إلى الوقت

بالنسبة إلى جميع الأخطاء المستندة إلى الوقت (بحد أقصى عدد من الطلبات لكل X دقيقة)، ننصحك بأن يلتقط الرمز البرمجي الاستثناء وأن يستخدم خوارزمية رقودة ثنائية مقتطعة للتأكّد من عدم تحمّل الأجهزة حِملًا زائدًا.

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

مثال على الخوارزمية

تعيد خوارزمية الرقود الأسي محاولة تكرار الطلبات بشكل كبير، ما يزيد من وقت الانتظار بين عمليات إعادة المحاولة إلى أقصى حد لوقت التراجع. مثال:

1. يمكنك تقديم طلب إلى Google Chat API.
2. إذا تعذّر إجراء الطلب، انتظر 1 + random_number_milliseconds ثم أعِد محاولة الطلب.
3. وإذا تعذّر إجراء الطلب، انتظِر 2 + random_number_milliseconds ثم أعِد محاولة الطلب.
4. وإذا تعذّر إجراء الطلب، انتظِر لمدة 4 + random_number_milliseconds ثم أعِد محاولة الطلب.
5. وهكذا، حتى مرة واحدة (maximum_backoff).
6. يمكنك مواصلة الانتظار وإعادة المحاولة لتصل إلى الحد الأقصى المسموح به لعدد عمليات إعادة المحاولة، ولكن مع عدم زيادة فترة الانتظار بين عمليات إعادة المحاولة.

المكان:

• يبلغ وقت الانتظار min(((2^n)+random_number_milliseconds), maximum_backoff)، مع زيادة n بمقدار مرة واحدة لكل تكرار (طلب).
• random_number_milliseconds هو عدد عشوائي بالمللي ثانية أقل من أو يساوي 1,000. يساعد ذلك في تجنُّب الحالات التي تتم فيها مزامنة العديد من البرامج في حالة معيّنة وإعادة المحاولة جميعها في وقت واحد، مع إرسال الطلبات في موجات متزامنة. يُعاد احتساب قيمة random_number_milliseconds بعد كل طلب لإعادة المحاولة.
• وتتراوح مدة maximum_backoff عادةً بين 32 أو 64 ثانية. وتعتمد القيمة المناسبة على حالة الاستخدام.

يمكن للعميل مواصلة إعادة المحاولة بعد انتهاء الوقت maximum_backoff. لا يلزم إعادة المحاولة بعد هذه المرحلة لزيادة وقت التراجع. على سبيل المثال، إذا كان العميل يستخدم وقت maximum_backoff مدّته 64 ثانية، يمكن للعميل إعادة المحاولة كل 64 ثانية بعد الوصول إلى هذه القيمة. ومن المفترض أن يُمنع العملاء في مرحلة ما من إعادة المحاولة إلى أجل غير مسمى.

يعتمد وقت الانتظار بين عمليات إعادة المحاولة وعدد هذه المحاولات على حالة الاستخدام وحالة الشبكة.

طلب زيادة في الحصة لكل مشروع

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

لا تحتوي جميع المشروعات على الحصص نفسها. مع تزايد استخدام Google Cloud بمرور الوقت، قد تحتاج حصصك إلى زيادة. إذا كنت تتوقّع زيادة ملحوظة في الاستخدام، يمكنك طلب تعديلات على الحصص بشكل استباقي من صفحة الحصص في Google Cloud Console.

لمزيد من المعلومات، اطّلِع على المراجع التالية:

• لمحة عن طلبات زيادة الحصة
• عرض استخدام حصتك الحالية وحدودها
• طلب حدّ أعلى للحصة المخصّصة