Rate Limiting и Throttling для API

Langdock сейчас предоставляет лимит в 60 000 токенов в секунду и другие ограничения. На первый взгляд это кажется щедрым лимитом, но когда начнёшь с ним работать, он быстро становится тесным. Обработка файлов, множественные запросы, быстрые вызовы, отсутствие поддержки истории диалогов в API поставщика — причин переполнить лимит предостаточно. Если ты сам разработчик API, то должен поддерживать сервис в живом состоянии и не позволять одному активному клиенту захватить все ресурсы, иначе все пострадают. Что можно противопоставить такой ситуации?

API Rate Limiting и Throttling

Rate Limiting и Throttling защищают API от перегрузок, злоупотребления и несправедливых паттернов использования, ограничивая количество запросов.

Краткое описание

Rate Limiting и Throttling — это механизмы, которые контролируют количество запросов к API в течение определённого периода. Rate Limiting определяет, сколько запросов разрешено клиенту, и отклоняет лишние с кодом 429 Too Many Requests. Throttling снижает скорость обработки, чтобы разгрузить backend при высокой нагрузке и обеспечить стабильные времена ответа. Оба подхода защищают от brute-force атак, скрейпинга, непредвиденных скачков нагрузки и DDoS атак. Реализации основаны на алгоритмах Fixed Window, Sliding Window, Token Bucket или Leaky Bucket. Важные вспомогательные меры включают информативные HTTP-заголовки, указание Retry-After, дифференцированные лимиты по эндпоинтам или пользователям и мониторинг лимитов.

Ключевые компоненты

Rate Limiting

Rate Limiting ограничивает количество запросов от клиента в определённый временной интервал. Если клиент превысит лимит, запрос будет отклонён. Ограничение может быть глобальным, на уровне API, эндпоинта, клиента или учётной записи пользователя.

Throttling

Throttling снижает скорость обработки запросов, не отклоняя их сразу. Он применяется, когда backend временно перегружен или нужно обеспечить равномерную обработку. Throttling можно реализовать через очереди, backoff или замедленную обработку.

Fixed Window

Алгоритм Fixed Window считает запросы в фиксированных временных окнах, например каждую минуту или час. Он прост в реализации, но может привести к всплескам в начале и конце окна.

Sliding Window

Алгоритм Sliding Window использует скользящее временное окно и избегает всплесков на границах окна. Он справедливее, чем Fixed Window, но сложнее в реализации.

Token Bucket

Алгоритм Token Bucket заполняет контейнер токенами с постоянной скоростью. Каждый запрос тратит один токен. Пока токены есть, запросы обрабатываются. Когда контейнер пуст, запросы отклоняются или задерживаются. Token Bucket позволяет кратковременные всплески, но стабильно ограничивает долгосрочную скорость.

Leaky Bucket

Алгоритм Leaky Bucket ставит запросы в очередь и отпускает их с постоянной скоростью. Он сглаживает всплески трафика особенно сильно и предотвращает скачки. Хорош для равномерной обработки, но может привести к задержкам.

HTTP статус-код 429

Когда клиент превысит Rate Limit, сервер отвечает 429 Too Many Requests. Заголовок Retry-After сообщает клиенту, когда можно повторить запрос. Это обеспечивает корректные повторные попытки и снижает нагрузку.

Заголовки лимитов

Информативные заголовки вроде X-RateLimit-Limit, X-RateLimit-Remaining и X-RateLimit-Reset помогают клиентам понять текущую загруженность и спланировать запросы. Они улучшают Developer Experience и снижают случайные превышения лимитов.

Per-User и Per-Endpoint лимиты

Глобальные лимиты просты, но часто недостаточно гибки. Лучше использовать дифференцированные лимиты для каждого аутентифицированного пользователя, клиента или эндпоинта. Бесплатные тарифы могут иметь строже ограничения, платные клиенты получают выше квоту.

Load Shedding

Load Shedding — форма throttling, при которой запросы активно отбрасываются при экстремальной нагрузке, чтобы держать систему стабильной. Приоритизация важных запросов и отказ от менее критичных операций помогают системе выжить.

Distributed Rate Limiting

В распределённых системах Rate Limiting должен работать согласованно на всех инстансах. Для этого используют централизованное хранилище вроде Redis или базы данных. Альтернативно можно применить методы приближения, например Sliding Window Log в Redis.

Мониторинг и оповещения

Отслеживай, как часто срабатывают лимиты, какие клиенты попадают под ограничения и указывают ли скачки на атаки или сбои. Оповещения при необычных паттернах позволяют быстро реагировать на злоупотребление или проблемы с ёмкостью.

Практический пример

API провайдер ограничивает запросы с помощью алгоритма Token Bucket. Каждому аутентифицированному пользователю доступно 100 токенов в минуту с максимальным всплеском в 20 токенов.

Запрос:

GET /api/v1/products
Authorization: Bearer USER_TOKEN

Ответ при успехе:

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1751300000

Ответ при превышении:

HTTP/1.1 429 Too Many Requests
Retry-After: 45
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1751300000

{
  "type": "https://api.example.com/problems/rate-limit-exceeded",
  "title": "Rate Limit überschritten",
  "status": 429,
  "detail": "Du hast das Limit von 100 Anfragen pro Minute überschritten."
}

Клиент может использовать заголовки и значение Retry-After, чтобы спланировать, когда отправить следующий запрос.

FAQ: Rate Limiting и Throttling

1. Что такое Rate Limiting?

Rate Limiting ограничивает количество запросов, которые клиент может отправить к API за определённый период. Превышения обычно отклоняются с кодом 429 Too Many Requests.

2. Что такое Throttling?

Throttling снижает скорость обработки запросов, чтобы защитить backend и обеспечить стабильные времена ответа. Запросы не отклоняются сразу, а замедляются или ставятся в очередь.

3. В чём разница между Rate Limiting и Throttling?

Rate Limiting отклоняет запросы при превышении лимита. Throttling замедляет обработку, не отклоняя запросы сразу. Оба защищают от перегрузок.

4. Что такое алгоритм Token Bucket?

Token Bucket заполняет контейнер токенами с постоянной скоростью. Каждый запрос тратит один токен. Когда контейнер пуст, запрос отклоняется. Алгоритм позволяет кратковременные всплески.

5. Что такое алгоритм Leaky Bucket?

Leaky Bucket ставит запросы в очередь и отпускает их с постоянной скоростью. Он сглаживает всплески трафика очень сильно и может привести к задержкам.

6. Что такое Fixed Window?

Fixed Window считает запросы в фиксированных временных окнах. Прост в реализации, но может привести к всплескам в начале и конце окна.

7. Что такое Sliding Window?

Sliding Window использует скользящее временное окно и справедливее, чем Fixed Window. Избегает всплесков на границах окна, но немного сложнее в реализации.

8. Что означает HTTP 429?

HTTP 429 Too Many Requests указывает, что клиент превысил Rate Limit. Сервер может через Retry-After сообщить, когда клиент может повторить попытку.

9. Что такое Retry-After?

Retry-After — HTTP-заголовок, который сообщает клиенту, как долго ждать перед повтором запроса. Используется при кодах 429 и 503.

10. Что такое Load Shedding?

Load Shedding отбрасывает запросы при экстремальной нагрузке, чтобы держать систему стабильной. Важные запросы приоритизируются, менее критичные отклоняются.

11. Как реализовать Rate Limiting в распределённых системах?

В распределённых системах используют централизованное хранилище вроде Redis, чтобы управлять лимитами согласованно на всех инстансах. Алгоритмы вроде Sliding Window Log или Token Bucket можно реализовать в Redis.

12. Что такое Per-User лимиты?

Per-User лимиты применяются к каждому аутентифицированному пользователю отдельно. Они справедливее глобальных лимитов, так как учитывают индивидуальное поведение и изолируют злоупотребления.

13. Что такое всплеск?

Всплеск — это короткий поток запросов за очень короткий промежуток времени. Алгоритмы вроде Token Bucket преднамеренно позволяют всплески, если долгосрочная скорость остаётся ограниченной.

14. Должны ли Rate Limits отличаться для разных эндпоинтов?

Да, разные эндпоинты имеют разные затраты ресурсов. Операции записи и сложные запросы часто должны иметь более строгие лимиты, чем простые операции чтения.

15. Почему мониторинг важен для Rate Limiting?

Мониторинг показывает, как часто срабатывают лимиты, какие клиенты попадают под ограничения и указывают ли скачки на атаки или сбои. Так можно оптимизировать лимиты и ёмкость.

Продолжение API обучающего пути

Следующий раздел API обучающего пути посвящён API Monitoring и Observability 2026 — как отслеживать работу APIs с помощью метрик, логов и Distributed Tracing.

Täglicher Artikel