Распределённое ограничение частоты запросов с Redis
Узнайте, как распределять состояние ограничений частоты запросов между несколькими экземплярами шлюза и служб с помощью Redis, атомарных операций и сценариев Lua, избегая состояний гонки.
«Распределённое ограничение частоты запросов с Redis» — бесплатный урок API Rate Limiting & Scalability Patterns на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения API Rate Limiting & Scalability Patterns, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс API Rate Limiting & Scalability Patterns содержит 4 уроков всего.
Части этого урока еще не переведены и отображаются на английском.
The Multi-Instance Problem
When you run several gateway replicas, each one keeping its own in-memory counter means a client gets N x limit total — once per instance.
To enforce one global limit, every instance must read and update shared state.
Why Redis
Redis is the de facto choice for distributed rate limiting because it offers:
- Sub-millisecond in-memory reads and writes
- Atomic commands like
INCR - Built-in expiry for automatic window resets
- Lua scripting for multi-step atomic logic
A Naive Counter
The simplest fixed-window counter uses INCR plus EXPIRE:
The first request in a window creates the key and sets a TTL; later requests just increment.
INCR rate:user:42
-- if reply == 1 (first hit):
EXPIRE rate:user:42 60The Race Condition
Running INCR then EXPIRE as two separate calls has a bug: if the process crashes between them, the key has no TTL and the limit never resets.
The fix is to make the check-and-increment atomic.
Atomicity with Lua
Redis runs a Lua script as a single atomic unit. We can check the count, increment, and set expiry without interruption.
local c = redis.call('INCR', KEYS[1])
if c == 1 then
redis.call('EXPIRE', KEYS[1], ARGV[2])
end
if c > tonumber(ARGV[1]) then
return 0
end
return 1Calling the Script
From the gateway you invoke the script with EVAL, passing the key, the limit, and the window size.
A return of 1 means allow; 0 means reject with 429 Too Many Requests.
allowed = redis.eval(script, keys=['rate:user:42'], args=[100, 60])
if allowed == 0:
return Response(status=429)Sliding Window with Sorted Sets
For smoother limiting, store request timestamps in a sorted set. Remove old entries, count what remains, then add the new one.
ZREMRANGEBYSCORE rate:user:42 0 (now-window)
ZCARD rate:user:42
ZADD rate:user:42 now nowReturning Rate Limit Headers
Good gateways tell clients where they stand using standard headers:
X-RateLimit-LimitX-RateLimit-RemainingRetry-Afteron a429
The Lua script can return remaining count alongside the allow flag.
Handling Redis Failures
What if Redis is unreachable? Two strategies:
- Fail open — allow traffic; favors availability
- Fail closed — reject traffic; favors protection
Most APIs fail open with a local fallback limiter to avoid a full outage.
Reducing Latency
Every limit check is a network hop. Cut overhead by:
- Co-locating Redis near the gateway
- Using connection pooling
- Batching counters with a short local cache for very hot keys
Keying by Identity
The rate limit key defines what you are limiting. Common choices:
rate:ip:1.2.3.4for anonymous trafficrate:user:42for authenticated usersrate:apikey:abcfor API clients
Pick the most specific identity available so one abuser cannot exhaust a shared bucket.
Quick Check
Test your grasp of distributed limiting.
Recap
You learned to share rate limit state across instances:
- A shared Redis store gives one global limit
- Lua scripts make check-and-increment atomic
- Sorted sets enable sliding windows
- Decide fail open vs. closed for Redis outages
Изучай API Rate Limiting & Scalability Patterns с ИИ-репетитором — бесплатно
Пиши и запускай код прямо в браузере, получай мгновенную помощь от ИИ-репетитора 24/7 и продолжи учиться на сайте или в приложении.
- Курсы
- 12
- Уроки
- 48
Часто задаваемые вопросы
Урок «Распределённое ограничение частоты запросов с Redis» бесплатный?
Да — полный текст урока «Распределённое ограничение частоты запросов с Redis» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс API Rate Limiting & Scalability Patterns, подпишись на CoddyKit PRO. Курс API Rate Limiting & Scalability Patterns содержит 4 уроков всего.
Чему я научусь в уроке «Распределённое ограничение частоты запросов с Redis»?
Узнайте, как распределять состояние ограничений частоты запросов между несколькими экземплярами шлюза и служб с помощью Redis, атомарных операций и сценариев Lua, избегая состояний гонки. Ты практикуешь API Rate Limiting & Scalability Patterns с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать API Rate Limiting & Scalability Patterns?
Предыдущий опыт не требуется. API Rate Limiting & Scalability Patterns на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.
Сколько времени занимает урок «Распределённое ограничение частоты запросов с Redis»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке API Rate Limiting & Scalability Patterns?
Да. Каждый урок API Rate Limiting & Scalability Patterns включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- Шаблоны интеграции шлюзов API
- Глобальное ограничение и ограничение для сервисов
- Динамическая настройка ограничений частоты
- Распределённое ограничение частоты запросов с Redis