Как настроить политику eviction в Redis

Redis — одна из самых популярных in-memory баз данных, широко используемая для кэширования, хранения сессий, реализации очередей и других задач, где важна высокая скорость доступа к данным. Поскольку данные хранятся в оперативной памяти, объём хранилища ограничен. Чтобы предотвратить исчерпание памяти, Redis предоставляет механизм управления памятью через политику eviction (вытеснение). Эта политика определяет, какие ключи будут удалены, когда достигнут лимит памяти.

Что такое eviction в Redis

Eviction (вытеснение) — это процесс автоматического удаления ключей из Redis, когда объём используемой памяти достигает заданного лимита. Этот механизм активируется только при наличии ограничения `maxmemory`, которое указывает максимальный объём RAM, который может использовать экземпляр Redis.
По умолчанию Redis не ограничивает использование памяти. Это означает, что если вы не установили `maxmemory`, сервер будет использовать столько памяти, сколько потребуется, пока ОС не начнёт убивать процесс или не произойдёт ошибка OOM (Out of Memory).
Когда `maxmemory` задан, Redis начинает следовать выбранной политике eviction. Политика определяет стратегию выбора ключей для удаления: по времени последнего доступа, по сроку жизни, случайно или вовсе запрещает запись новых данных.
Политика eviction не влияет на поведение Redis до достижения лимита. После этого она становится решающей: от неё зависит, сохранится ли производительность системы или начнутся ошибки записи.

Основные политики eviction

Redis поддерживает восемь основных политик eviction. Каждая из них подходит для определённого сценария использования. Ниже приведено подробное описание каждой политики.

1. noeviction

При достижении лимита памяти Redis отказывается выполнять команды, изменяющие данные (например, SET, LPUSH), возвращая ошибку «OOM command not allowed». При этом чтение (GET, HGET) остаётся разрешено.
Подходит для случаев, когда данные критически важны и не должны удаляться автоматически. Часто используется в системах, где Redis применяется как primary storage, а не как кэш.

2. allkeys-lru

Удаляет наименее недавно использованные (Least Recently Used) ключи из *всех* ключей, независимо от наличия TTL. Использует LRU-аппроксимацию — Redis не хранит точное время последнего доступа, а оценивает его на основе выборки.
Оптимален для кэширования, где все ключи потенциально могут быть удалены. Самый популярный выбор для web-приложений.

3. volatile-lru

Аналогичен allkeys-lru, но применяется только к ключам, у которых установлен TTL (время жизни). Ключи без TTL не участвуют в eviction.
Используется, если нужно гарантировать, что бессрочные ключи не будут удалены, например, в сценариях хранения конфигураций или метаданных.

4. allkeys-lfu

Удаляет наименее часто используемые (Least Frequently Used) ключи. LFU учитывает частоту обращений, а не только временной фактор. Полезен, когда некоторые ключи читаются очень редко, но имеют долгий срок жизни.
Требует больше вычислительных ресурсов, чем LRU, но обеспечивает более точный контроль за актуальностью данных.

5. volatile-lfu

Работает как allkeys-lfu, но только для ключей с TTL. Подходит, если вы хотите применять частотный подход к кэшируемым данным, но сохранять постоянные ключи.

6. allkeys-random

Случайным образом удаляет ключи из всех ключей. Прост в реализации, но может привести к удалению «горячих» данных.
Применяется редко, чаще в тестовых средах или при равномерном распределении запросов.

7. volatile-random

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

8. volatile-ttl

Удаляет ключи с наименьшим оставшимся временем жизни (TTL). Чем быстрее истекает TTL — тем выше шанс на удаление.
Хорошо работает, если данные естественным образом устаревают, но требуется принудительная очистка при пиковой нагрузке.

Как настроить политику в Redis

Настройка политики eviction выполняется двумя способами: через конфигурационный файл `redis.conf` или динамически через команду `CONFIG SET`.

Шаг 1: Установите лимит памяти

Перед выбором политики необходимо задать `maxmemory`. Например:

maxmemory 2gb

Поддерживаются суффиксы: b, k, kb, m, mb, g, gb.

Шаг 2: Выберите и примените политику

Добавьте строку в `redis.conf`:

maxmemory-policy allkeys-lru

Доступные значения: `noeviction`, `allkeys-lru`, `volatile-lru`, `allkeys-lfu`, `volatile-lfu`, `allkeys-random`, `volatile-random`, `volatile-ttl`.

Шаг 3: Перезапустите или примените настройки

Если вы редактировали файл, перезапустите Redis:

sudo systemctl restart redis-server

Или примените настройки на лету:

redis-cli CONFIG SET maxmemory 2gb
redis-cli CONFIG SET maxmemory-policy allkeys-lru

Команды `CONFIG SET` работают немедленно, но изменения не сохраняются после перезагрузки, если не выполнить `CONFIG REWRITE`.

Шаг 4: Проверьте текущие настройки

Убедитесь, что изменения применены:

redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy

Также можно посмотреть статус через:

redis-cli INFO memory

В выводе обратите внимание на поля:

• `used_memory_human` — текущее использование памяти;
• `maxmemory_human` — установленный лимит;
• `maxmemory_policy` — текущая политика.

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

Выбор политики зависит от нескольких факторов: типа данных, характера нагрузки, требований к отказоустойчивости и бизнес-логики.

Сценарий 1: Кэширование HTML, API-ответов, изображений

Используйте `allkeys-lru`. Все данные временные, и потеря части кэша допустима. LRU хорошо справляется с паттернами доступа, где «горячие» данные используются чаще.

Сценарий 2: Сессии пользователей + постоянные настройки

Примените `volatile-lru`. Сессии имеют TTL, а настройки — нет. Так вы гарантируете, что настройки не будут удалены.

Сценарий 3: Рекомендательная система с долгоживущими моделями

Выберите `allkeys-lfu`. Некоторые модели запрашиваются редко, но их важно сохранить. LFU позволит удалять именно те, к которым почти не было обращений.

Сценарий 4: Брокер сообщений (очереди)

Лучше использовать `noeviction`, так как потеря сообщений недопустима. Вместо этого настройте внешний мониторинг и масштабирование.

Сравнение LRU и LFU

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

Мониторинг и диагностик

Правильная настройка — это только начало. Важно отслеживать, как политика работает в реальных условиях.

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

• evicted_keys — количество удалённых ключей. Резкий рост может указывать на нехватку памяти.
• keyspace_hits / keyspace_misses — соотношение попаданий/промахов. При высоких eviction rate ожидайте рост misses.
• used_memory_peak — пиковое использование памяти. Помогает понять, нужно ли увеличивать лимит.
• instantaneous_ops_per_sec — нагрузка на Redis. Коррелируйте с eviction.

Инструменты мониторинга

• Redis CLI: команда `INFO memory`, `INFO stats`.
• Prometheus + Redis Exporter — для графиков в Grafana.
• Datadog, New Relic — готовые решения с алертами.

Анализ поведения

Если `evicted_keys` растёт быстро, а `keyspace_misses` тоже растёт — возможно, лимит памяти слишком мал. Рассмотрите увеличение `maxmemory` или переход на кластер Redis.
Если eviction почти не происходит, но память заполнена на 95%, проверьте, не заблокировались ли процессы очистки.

Тестирование политики

Перед внедрением в продакшен протестируйте политику:

1. Запустите Redis с нужной политикой.
2. Загрузите типичный набор данных.
3. Сымитируйте нагрузку (например, через `redis-benchmark`).
4. Наблюдайте за eviction и hit rate.

Экспертное мнение

Политика eviction должна соответствовать жизненному циклу данных. Не существует универсального решения, но есть общие принципы.
Если данные временные — используйте политики с TTL (volatile-*). Если все данные одинаково ценны — allkeys-*.
Избегайте `noeviction` в кэшах: это приводит к ошибкам записи и падению сервисов. Лучше потерять часть кэша, чем сломать API.
LRU подходит для 80% кейсов. LFU — когда важно различать «редко, но регулярно» и «никогда».
Не полагайтесь только на TTL. Даже с корректным сроком жизни при высокой нагрузке может возникнуть давление на память. Eviction — страховка.
Настройка `maxmemory` должна учитывать не только Redis, но и другие процессы на сервере. Оставляйте минимум 20% памяти под ОС и фоновые задачи.

Вопросы и ответы

Заключение

Настройка политики eviction в Redis — критически важный этап при использовании базы данных в качестве кэша или временного хранилища. От правильного выбора зависит стабильность, производительность и отказоустойчивость всего приложения.

• Всегда устанавливайте `maxmemory`, если Redis работает в production.
• Для кэшей выбирайте `allkeys-lru` или `allkeys-lfu` в зависимости от характера доступа.
• Используйте `volatile-*` политики, если в базе есть постоянные данные.
• Мониторьте метрики `evicted_keys` и `keyspace_misses` для оценки эффективности.
• Тестируйте политику перед развёртыванием в продакшене.