Rate limiting (ограничение количества запросов/действий, разрешённых в временном окне) — это часто встречающийся вариант использования Redis — быстрые атомарные счётчики Redis и TTL делают его идеальным. Существует несколько алгоритмов (фиксированное окно, скользящее окно, token bucket), каждый с собственными компромиссами.
() {
key = ;
count = redis.(key);
(count === ) redis.(key, windowSec);
count <= limit;
}
Подход фиксированного окна: атомарный счётчик для каждой пары (пользователь, временное окно) с TTL — увеличение при каждом запросе, отклонение при превышении лимита. Просто и эффективно, использует атомарную операцию INCR и автоматическое истечение.
✗ Limitation: bursts at window boundaries (2x limit possible across two adjacent windows)
SLIDING WINDOW → tracks requests over a rolling time period (no boundary bursts)
→ often uses a SORTED SET: add each request with a timestamp score,
remove old entries (ZREMRANGEBYSCORE), count remaining (ZCARD)
✓ More accurate/smooth ✗ More memory and complexity
TOKEN BUCKET → tokens refill at a steady rate; each request consumes a token
→ allows bursts (up to the bucket size) while limiting the average rate
→ often implemented with a Lua SCRIPT for atomic check-and-consume
✓ ATOMIC counters (INCR) → correct under concurrency, no race conditions
✓ Fast (in-memory) → minimal latency added to each request
✓ TTL → automatic window cleanup (no manual expiry management)
✓ SHARED across servers → distributed rate limiting (all app servers use one Redis)
→ Redis is the standard tool for distributed rate limiting.
Реализация rate limiting с помощью Redis — это обычный, практический вариант использования, поэтому понимание его — ценное знание — rate limiting (защита API и сервисов от злоупотреблений, обеспечение справедливого использования, предотвращение перегрузки) — это почти универсальная необходимость, а Redis — это стандартный инструмент для неё.
Понимание почему Redis идеален — это ключевой момент: его атомарные счётчики (INCR) обеспечивают корректность подсчёта rate limit при конкурентном доступе (без race conditions и потери данных), его скорость (в памяти) добавляет минимальную задержку к каждому запросу, TTL автоматически очищают окно, и, что важно, это общий инструмент для всех серверов — обеспечивая распределённое rate limiting, где все серверы приложений применяют один согласованный лимит (необходимо в многосерверных развёртываниях, где per-server лимиты в памяти не будут работать).
Понимание алгоритмов и их компромиссов позволяет вам выбрать подходящий: фиксированное окно (самое простое — атомарный счётчик на временное окно с TTL, но позволяющее всплески на границах), скользящее окно (более плавное и точное, использует отсортированное множество timestamped запросов, с большими затратами памяти), и token bucket (позволяет контролируемые всплески при ограничении среднего темпа, часто через Lua скрипт для атомарности).
Знание того, как реализовать эти подходы (особенно простой, частый паттерн фиксированного окна с INCR + EXPIRE), это практический, применимый навык.
Поскольку rate limiting — это общее требование для защиты сервисов, и поскольку Redis (с его атомарными счётчиками, скоростью, TTL и общей поддержкой многих серверов) — это стандартный, идеальный инструмент для распределённого rate limiting, понимание того, как реализовать его с помощью Redis — алгоритмы, их компромиссы и почему Redis так хорошо подходит — это ценное, часто применяемое знание для создания надёжных, защищённых сервисов, одного из самых распространённых практических применений Redis помимо кеширования.