Rate limiter на Redis

Фиксированное окно — самая простая схема, которая закрывает большинство внутренних сценариев. Каждая минута — своя корзина: ключ вида ratelimit:sms:202506011407 содержит счётчик обращений, срок жизни равен длине окна. Запрос сначала инкрементирует счётчик, потом сверяет с лимитом: Incr вернул число выше разрешённого — отказ, ниже — пропуск. Всё атомарно: INCR выполняется сервером единым шагом, поэтому параллельные горутины и инстансы не потеряют увеличения, — тот же приём из урока про счётчики и INCR, только с отказом в конце. Отказ честнее сопровождать заголовками X-RateLimit-Limit и X-RateLimit-Remaining: приличный API сообщает клиенту, сколько попыток осталось, а Retry-After подскажет, когда откроется новое окно после истечения TTL.

У фиксированного окна есть известная слепая зона — граница корзин. Лимит сто в минуту не означает «не больше ста за любые шестьдесят секунд»: на стыке окна клиент может провести сто запросов в последние секунды текущей корзины и ещё сто в первые секунды следующей — двести обращений за короткий интервал при формальном соблюдении лимита. Для защиты платного API этого мало, для большинства внутренних сценариев — достаточно. Классическая ошибка — «улучшить» схему укорачиванием окна: окно в одну секунду при всплеске от ботов пропускает пачки запросов между секундами и добавляет лишнюю нагрузку на Redis. Если честность квоты принципиальна, нужен следующий приём — скользящее окно, которое считает настоящие последние шестьдесят секунд, а не абстрактную корзину.

Скользящее окно считает запросы честно: не «сколько инкрементов в текущей минуте», а «сколько отметок времени в последних шестидесяти секундах». Хранителем отметок выступает ZSET из урока про отсортированные множества: член — уникальный идентификатор запроса, score — время в миллисекундах. Перед подсчётом старые отметки выметаются ZRemRangeByScore с границей от нуля до now минус шестьдесят тысяч, затем ZCard отвечает числом живых отметок, и если оно ниже лимита — ZAdd записывает новую. Все три команды отправляются пайплайном из урока про пайплайны: один сетевой рейс вместо трёх, что на горячем пути решает. Результат — ровный лимит без границы корзин: сто запросов за любые шестьдесят секунд, не больше.

Скользящее окно покупает точность памятью и командами: каждая попытка — запись в ZSET, а пиковый трафик в сто тысяч запросов в минуту держит столько же членов в ключе. Для лимитов в тысячи в минуту это копейки, для сотен тысяч — уже решение об архитектуре: на таких объёмах обычно берут локальные лимитеры в памяти каждого инстанса с Redis как вторым рубежом или token bucket на Lua-скрипте. Есть и средний путь — квантование: члены со score, округлённым до секунды, при конфликте инкрементируются ZIncrBy вместо ZAdd — окно помнит секунды, а не запросы, память падает в разы при погрешности в пределах одной секунды. Выбирайте по типу трафика: API для людей прощает квантование, тарификация платных вызовов — нет.

Ключ лимитера определяет, кого именно считаем, и ошибка здесь дороже ошибки алгоритма. Считать по IP — дефолт для публичных эндпоинтов, но за корпоративным NAT сотни людей делят один адрес, и честные пользователи ловят отказ за ботов. Считать по идентификатору пользователя — правильно для авторизованных API: после middleware из урока про сессии userID уже лежит в контексте запроса. Рабочая комбинация — двухуровневый лимит: глобальный на endpoint плюс персональный на клиента. Первый защищает Redis и базу от шторма, второй не даёт одному клиенту съесть общую квоту. И правило гигиены: единая функция построения ключа, как и для кэша из урока про кэширование запросов — рассыпанные конкатенации по хендлерам превращают аудит лимитов в археологию.

Отказ лимитера — не ошибка сервиса, а штатный ответ, и оформление решает, как его встретят клиенты. Статус правильный — 429 Too Many Requests, а не 403: первый говорит «подожди и повтори», второй — «тебе сюда нельзя вообще», и мониторинг клиента реагирует на них по-разному. Заголовок Retry-After с числом секунд до нового окна экономит и чужие попытки, и ваш Redis: без него клиент повторяет по своему таймеру, обычно чаще, чем нужно. На публичных эндпоинтах не раскрывайте детали квот: слишком точный Remaining подсказывает переборщикам, когда лимит кончится, — достаточно Limit и Reset. Внутреннему фронтенду, наоборот, честный Remaining позволяет спрятать кнопку до окна и не показывать пользователю ошибку.