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

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

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

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

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

تحدّ الحصص لكل مساحة من معدّل طلبات البحث في مساحة معيّنة، وتتم مشاركتها بين جميع تطبيقات Chat التي تعمل في تلك المساحة وتستدعي methods المُدرَجة في 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 واحد يستدعي مثبّت methods Chat API لكل حصة.

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

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

حدود استخدام إضافية

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

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

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

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

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

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

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

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

حيث:

• يبلغ وقت الانتظار 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.

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

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