Fastify vs Express в 2026: производительность, плагины и миграция

12 мая 2026 г. 12K

Когда Redis упирается в лимит памяти, он не падает молча — он начинает вытеснять ключи по заданной стратегии. Выбор правильной eviction policy определяет, потеряете ли вы критичные данные или безболезненно освободите место. Разберёмся, какие политики существуют и когда какую применять.

Зачем нужны eviction policies

Redis хранит всё в оперативной памяти. Параметр maxmemory задаёт потолок, а maxmemory-policy — что делать при его достижении. Без явной настройки Redis использует noeviction и просто отказывает в записи, возвращая OOM command not allowed.

allkeys-lru vs volatile-lru

Обе политики используют LRU (Least Recently Used) — вытесняют ключи, к которым дольше всего не обращались:

allkeys-lru — выбирает жертву среди ВСЕХ ключей. Подходит, когда Redis — чистый кэш и любой ключ можно удалить.
volatile-lru — вытесняет только ключи с TTL. Ключи без expire неприкосновенны. Удобно, когда часть данных персистентные (конфиги), а часть — временные.

Важно: Redis не реализует точный LRU. Он сэмплирует случайные ключи (по умолчанию 5) и удаляет наименее свежий из выборки. Увеличить точность:

maxmemory-samples 10

allkeys-lfu — когда частота важнее свежести

С Redis 4.0 появилась LFU (Least Frequently Used) — вытесняет ключи, к которым обращались реже всего. LFU лучше LRU когда:

Есть «горячие» ключи с постоянными запросами (топ товаров, популярные профили)
Batch-операции сканируют много ключей разово — LRU сохранит их как «свежие», вытеснив реально нужные данные
Паттерн доступа неравномерный: 20% ключей получают 80% запросов

Настройка LFU:

# Скорость затухания счётчика (0-10, по умолчанию 1)
lfu-decay-time 1
# Логарифмический фактор роста (по умолчанию 10)
lfu-log-factor 10

noeviction и OOM

Политика noeviction — осознанный выбор: лучше отказать в записи, чем потерять данные. Redis продолжает обслуживать чтения, но на запись отвечает ошибкой. Оправдано когда Redis — primary store, или вы хотите явный сигнал о переполнении.

Опасность: если приложение не обрабатывает OOM, пользователи увидят 500-ки. Всегда ловите ошибку в клиентском коде и имейте план — алерт, автоскейлинг, сброс TTL.

Настройка maxmemory и мониторинг

Базовая конфигурация:

# Лимит — 75% от доступной RAM
maxmemory 6gb
maxmemory-policy allkeys-lfu
maxmemory-samples 10

Менять на лету без рестарта:

redis-cli CONFIG SET maxmemory-policy allkeys-lfu
redis-cli CONFIG SET maxmemory 8gb

Ключевые метрики:

# Потребление памяти
redis-cli INFO memory | grep used_memory_human
# Вытесненные ключи
redis-cli INFO stats | grep evicted_keys
# Hit rate кэша
redis-cli INFO stats | grep keyspace_hits
redis-cli INFO stats | grep keyspace_misses

Формула hit rate: hits / (hits + misses) * 100. Здоровый кэш — 90%+. Если после включения eviction hit rate ниже 80%, вытесняются нужные ключи.

Подводные камни

volatile-* без TTL — если ни у одного ключа нет expire, volatile-политики ведут себя как noeviction и вернут OOM.
Фрагментация — used_memory_rss может быть значительно выше used_memory. Следите за mem_fragmentation_ratio.
Lazy freeing — удаление больших структур блокирует поток. Включите lazyfree-lazy-eviction yes.
Реплики — не вытесняют сами, получают DEL от мастера. Реплика может упасть по OOM раньше из-за output buffer.

Какую политику выбрать

Redis = чистый кэш, ключи равноценны → allkeys-lru
Горячие ключи, паттерн 80/20 → allkeys-lfu
Часть ключей персистентные, часть с TTL → volatile-lru или volatile-lfu
Потеря данных недопустима → noeviction

Начните с allkeys-lfu — наиболее универсальный вариант для продакшн-кэшей. Мониторьте evicted_keys и hit rate, корректируйте по результатам нагрузочного тестирования.