الحدود القصوى والحصص للاستخدام
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تعمل الحدود والحصص على حماية بنية Google الأساسية من عملية آلية تستخدم واجهة برمجة تطبيقات Notification Center API بطريقة غير ملائمة. قد تنتج الطلبات الزائدة من واجهة برمجة التطبيقات عن خطأ إملائي غير ضار، أو قد تنتج عن نظام مصمم بشكل غير فعّال ينفذ طلبات بيانات غير ضرورية من واجهة برمجة التطبيقات. بغض النظر عن السبب، من الضروري حظر الزيارات من مصدر معيَّن بعد وصولها إلى مستوى معيَّن للحفاظ على سلامة نظام Google Workspace بشكل عام. ويضمن هذا الوضع ألّا تؤثر إجراءات أحد المطوّرين سلبًا في المنتدى الأكبر.
في حال تعذُّر طلب البيانات من واجهة برمجة التطبيقات، وهو أمر مستبعد، ستتلقّى استجابة رمز حالة HTTP. يتضمّن رمز الحالة 403 معلومات خطأ بشأن إدخال غير صحيح، ويحتوي رمز حالة HTTP لـ 503 على معلومات خطأ تشير إلى حصص واجهة برمجة التطبيقات التي تم تجاوزها. تسمح هذه الاستجابات للتطبيق المخصّص برصد هذه الأخطاء واتّخاذ الإجراء المناسب.
إذا كانت هناك حاجة إلى إكمال طلباتك خلال فترة زمنية ثابتة، أرسِل طلباتك بالتوازي أو استخدِم سلاسل محادثات متعددة في تطبيق Java أو C# . أحد الأمثلة على الطلبات المتوازية هو طلب دفعات صغيرة من رسائل البريد الإلكتروني من مستخدمين مختلفين بدلاً من إضافة الكثير من رسائل البريد الإلكتروني أو إزالتها من مستخدم واحد في وقت واحد. في حال استخدام سلاسل المحادثات، جرِّب البدء بـ 10 سلاسل محادثات، وسلسلة محادثات واحدة لكل عنوان بريد إلكتروني للمستخدم. يُرجى العِلم أنّ اقتراح سلسلة المحادثات يتضمّن مقايضات ولا يفيد في جميع حالات واجهات برمجة التطبيقات. إذا كان عدد الطلبات مرتفعًا جدًا، ستحدث أخطاء في الحصة.
بالنسبة إلى جميع الأخطاء المستندة إلى الوقت (بحد أقصى N عنصر لمدة N ثانية لكل سلسلة محادثات)، وخاصةً أخطاء رمز الحالة 503، ننصحك باستخدام الرمز عند اكتشاف استثناء. وباستخدام خوارزمية الرقود الأسي، عليك الانتظار قليلاً قبل إعادة محاولة الاتصال. من أمثلة واجهة برمجة تطبيقات مركز التنبيه لسلسلة محادثات واحدة، الانتظار لمدة 5 ثوانٍ وإعادة محاولة الاتّصال الذي تعذّر تنفيذه. إذا تم الطلب بنجاح، كرِّر هذا النمط لسلاسل المحادثات الأخرى. إذا لم ينجح الطلب الثاني، يجب أن يخفّض تطبيقك معدّل تكرار الطلب حتى تتم معالجة الطلب بنجاح. على سبيل المثال، يمكنك زيادة المهلة الأولية التي تبلغ 5 ثوانٍ إلى 10 ثوانٍ، وإعادة محاولة إجراء المكالمة التي تعذّر تنفيذها مرة أخرى. أيضًا، حدد حد إعادة المحاولة. على سبيل المثال، يمكنك إعادة محاولة طلب من 5 إلى 7 مرات بأوقات تأخير مختلفة قبل أن يعرض التطبيق رسالة خطأ للمستخدم.
| فئات حدود واجهة برمجة التطبيقات |
الحدود القصوى المسموح بها |
| معدلات QPS وQPD في مركز التنبيه |
تفرض واجهة برمجة التطبيقات قيودًا على عدد الطلبات لمشروع وحدة تحكم واجهات برمجة التطبيقات. الحد الأقصى لعدد الطلبات في الثانية لمشروع واجهة برمجة التطبيقات (QPS) هو 1,000. ويبلغ الحد الأقصى لعدد الطلبات لكل مستخدم في الثانية (QPS) 150 طلبًا.
وفي حال تجاوز هذه الحدود، يعرض الخادم رمز حالة HTTP 503. استخدِم خوارزمية خوارزمية الرقود الأسي الثنائي عند إعادة محاولة تنفيذ طلباتك.
|
| الأنواع الأخرى من الحدود |
القيود والإرشادات |
| تنسيق البيانات (التلقائي) |
تنسيق البيانات التلقائي هو JSON.
|
| الطلبات غير المصرّح بها |
لا تسمح Google بالطلبات غير المصرّح بها لواجهة برمجة التطبيقات هذه. يُعتبر الطلب غير مصرَّح به في حال عدم تقديم رمز مميّز للتفويض. لمزيد من المعلومات، يُرجى الاطّلاع على تفويض الطلبات.
|
طلب زيادة في الحصة لكل مشروع
بناءً على استخدام مشروعك للموارد، قد تريد طلب زيادة في الحصة. أما طلبات البيانات من واجهة برمجة التطبيقات التي يجريها حساب خدمة، فيُعتبر أنّ هذه الطلبات تستخدم
حسابًا واحدًا. إنّ التقدّم بطلب للحصول على حصة أكبر لا يضمن الموافقة. قد تستغرق زيادات الحصص الكبيرة وقتًا أطول للموافقة عليها.
لا تحتوي جميع المشروعات على الحصص نفسها. مع تزايد استخدام Google Cloud بمرور الوقت،
قد تحتاج حصصك إلى زيادة. إذا كنت تتوقّع زيادة ملحوظة في الاستخدام، يمكنك طلب تعديلات على الحصص بشكل استباقي من صفحة الحصص
في Google Cloud Console.
لمزيد من المعلومات، اطّلِع على المراجع التالية:
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-03-25 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-03-25 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Usage limits and quotas\n\nLimits and quotas protect the Google infrastructure from an automated process that uses the Alert Center API in an inappropriate way. Excessive requests from an API might result from a harmless typo, or might result from an inefficiently designed system that makes needless API calls. Regardless of the cause, blocking traffic from a specific source once it reaches a certain level is necessary for the overall health of the Google Workspace system. It ensures that one developer's actions cannot negatively impact the larger community.\n\nIn the unlikely event that your API request fails, you'll receive an HTTP status code response. A status code of `403` has error information about incorrect input and an HTTP status code of `503` has error information indicating which API quotas have been exceeded. These responses allow your custom application to detect these errors and take appropriate action.\n\nIf your requests need to be completed in a fixed period of time, send your requests in parallel or use multiple threads in your Java or C# application. An example of parallel requests is requesting small batches of emails from different users rather than adding or removing lots of emails from one user simultaneously. In the case of threads, try starting with 10 threads, one thread per user email. Note, the thread recommendation has trade-offs and is not useful for all API situations. If the number of requests gets too high, quota errors will occur.\n\nFor all errors that are time based (maximum of \u003cvar translate=\"no\"\u003eN\u003c/var\u003e things for \u003cvar translate=\"no\"\u003eN\u003c/var\u003e seconds per thread), especially the 503 status code errors, we recommend your code catch the exception and, using an [exponential backoff](http://wikipedia.org/wiki/Truncated_binary_exponential_backoff) algorithm, wait for a small delay before retrying the failed call. A Alert Center API example for one thread is to wait 5 seconds and retry the failed call. If the request is successful, repeat this pattern for the other threads. If the second request is not successful, your application should scale back on the frequency of the request until a call is successful. For example, increase the initial 5 second delay to 10 seconds and retry your failed call again. Also, decide on a retry limit. For example retry a request 5 to 7 times with different delay times before your application returns an error to the user.\n\n| API Limit Categories | Limits |\n|--------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Alert Center QPS and QPD rates | The API limits the number of requests for your APIs Console project. The API project's maximum number of requests per second (project QPS) is 1000. And, the maximum number of requests per user per second (user QPS) is 150. If these limits are exceeded, the server returns an HTTP `503` status code. Use the [exponential backoff](http://wikipedia.org/wiki/Truncated_binary_exponential_backoff) algorithm when retrying your requests. |\n\n\n| Other Types of Limits | Limitations and Guidelines |\n|-----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Data format, default | The default data format is JSON. |\n| Unauthorized requests | Google does not allow unauthorized requests to this API. A request is considered unauthorized if no authorization token is provided. For more information, see [Authorizing requests](/workspace/admin/alertcenter/guides/authorizing). |\n\nRequest a per-project quota increase\n------------------------------------\n\n\nDepending on your project's resource usage, you might want to request a quota\nadjustment. API calls by a service account are considered to be using a\nsingle account. Applying for an adjusted quota doesn't guarantee approval. Quota adjustment\nrequests that would significantly increase the quota value can take longer to be approved.\n\n\nNot all projects have the same quotas. As you increasingly use Google Cloud over\ntime, your quota values might need to increase. If you expect a notable upcoming\nincrease in usage, you can proactively\n[request quota adjustments](https://cloud.google.com/docs/quota#requesting_higher_quota)\nfrom the [Quotas page](https://console.cloud.google.com/iam-admin/quotas)\nin the Google Cloud console.\n\nTo learn more, see the following resources:\n\n- [About quota adjustments](https://cloud.google.com/docs/quotas/overview#about_increase_requests)\n- [View your current quota usage and limits](https://cloud.google.com/docs/quota#viewing_your_quota_console)\n- [Request a higher quota limit](https://cloud.google.com/docs/quota#requesting_higher_quota)"]]
