Поскольку Google Chat API является общей службой, мы применяем квоты и ограничения, чтобы обеспечить его справедливое использование всеми пользователями и защитить общую производительность Google Workspace.
Если вы превысите квоту, вы получите ответ с кодом состояния HTTP 429: Too many requests
. Дополнительные проверки ограничения скорости на серверной части чата также могут привести к такому же ответу об ошибке. Если возникает эта ошибка, вам следует использовать алгоритм экспоненциальной отсрочки и повторить попытку позже. Пока вы соблюдаете поминутные квоты, указанные в следующих таблицах, количество запросов, которые вы можете делать в день, не ограничено.
К методам Chat API применяются два типа квот: квоты для каждого пространства и квоты для каждого проекта.
Квоты на пространство
Квоты для каждого пространства ограничивают частоту запросов в данном пространстве и распределяются между всеми приложениями чата, действующими в этом пространстве, вызывая перечисленные методы Chat API для каждой квоты.
В следующей таблице приведены ограничения на количество запросов для каждого пространства:
Квота на пространство | Методы API чата | Лимит (за 60 секунд, общий |
---|---|---|
Чтений в минуту | | 900 |
Пишет в минуту | | 60 |
Квоты на проект
Квоты для каждого проекта ограничивают частоту запросов для проекта Google Cloud и, таким образом, применяются к одному приложению Chat, вызывающему указанные методы Chat API для каждой квоты.
В следующей таблице подробно описаны ограничения запросов для каждого проекта. Вы также можете найти эти ограничения на странице «Квоты» .
Квота на проект | Методы API чата | Лимит (за 60 секунд) |
---|---|---|
Сообщений пишется в минуту | | 3000 |
Число прочтений сообщений в минуту | | 3000 |
Количество записей в минуту | | 300 |
Членство читает в минуту | | 3000 |
Пространство пишет в минуту | | 60 |
Пространство читается в минуту | | 3000 |
Записей вложений в минуту | | 600 |
Вложение читается в минуту | | 3000 |
Реакций пишет в минуту | | 600 |
Реакция читается в минуту | | 3000 |
Дополнительные лимиты использования
Существуют дополнительные ограничения квоты на создание пространств типа GROUP_CHAT
или SPACE
(с использованием метода spaces.create
или spaces.setup
). Создавайте менее 35 пространств в минуту и 210 пространств в час для этих типов. На пространства типа DIRECT_MESSAGE
не распространяются эти дополнительные ограничения квоты.
Большие запросы в секунду (QPS) любого API, ориентированного на одно и то же пространство, могут вызвать дополнительные внутренние ограничения, которые не отображаются на странице «Квоты» .
Устранение ошибок квот на основе времени
Для всех ошибок, связанных со временем (максимум N запросов за X минут), мы рекомендуем, чтобы ваш код перехватывал исключение и использовал усеченную экспоненциальную отсрочку , чтобы убедиться, что ваши устройства не создают чрезмерную нагрузку.
Экспоненциальная отсрочка — это стандартная стратегия обработки ошибок для сетевых приложений. Алгоритм экспоненциальной отсрочки повторяет запросы, используя экспоненциально увеличивающееся время ожидания между запросами, вплоть до максимального времени отсрочки. Если запросы по-прежнему не увенчались успехом, важно, чтобы задержки между запросами со временем увеличивались, пока запрос не будет успешным.
Пример алгоритма
Алгоритм экспоненциальной отсрочки повторяет запросы экспоненциально, увеличивая время ожидания между повторными попытками до максимального времени отсрочки. Например:
- Сделайте запрос к Google Chat 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
— случайное число миллисекунд, меньшее или равное 1000. Это помогает избежать случаев, когда многие клиенты синхронизируются по какой-то ситуации и все повторяют попытки одновременно, отправляя запросы синхронизированными волнами. Значениеrandom_number_milliseconds
пересчитывается после каждого повторного запроса. -
maximum_backoff
обычно составляет 32 или 64 секунды. Соответствующее значение зависит от варианта использования.
Клиент может продолжить повторную попытку после достижения maximum_backoff
времени возврата. Повторные попытки после этого момента не требуют дальнейшего увеличения времени отсрочки. Например, если клиент использует время maximum_backoff
равное 64 секундам, то после достижения этого значения клиент может повторять попытку каждые 64 секунды. В какой-то момент клиентам следует запретить повторные попытки на неопределенный срок.
Время ожидания между повторными попытками и количество повторных попыток зависят от вашего варианта использования и условий сети.
Запросить увеличение квоты для каждого проекта
В зависимости от использования ресурсов вашего проекта вы можете запросить увеличение квоты. Вызовы API со стороны учетной записи службы считаются использованием одной учетной записи. Подача заявки на увеличение квоты не гарантирует одобрения. Для утверждения значительного увеличения квоты может потребоваться больше времени.
Не все проекты имеют одинаковые квоты. Поскольку со временем вы все чаще используете Google Cloud, возможно, вам придется увеличить квоты. Если вы ожидаете заметного увеличения использования, вы можете заранее запросить корректировку квот на странице «Квоты» в консоли Google Cloud.
Чтобы узнать больше, посетите следующие ресурсы:
- О запросах на увеличение квот
- Просмотр текущего использования и ограничений квоты
- Запросить более высокий лимит квоты