Настройка Redis как эффективного многоуровневого кеша.

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

Это руководство фокусируется на настройке Redis для рабочих нагрузок кеширования, а не для хранения основных данных.

Понимание уровней кеширования Redis

Во многих архитектурах приложений Redis является общим кешем, расположенным за меньшим внутрипроцессным кешем. Ваше приложение может хранить несколько горячих значений локально в течение миллисекунд, в то время как Redis хранит более крупный набор повторно используемых объектов в течение секунд или минут. Это делает Redis уровнем, который защищает вашу базу данных при скачках трафика.

Эффективная настройка зависит от двух основных областей:

1. Управление памятью: Установка жесткого лимита на объем памяти, который может потреблять Redis.
2. Политики вытеснения: Определение того, как Redis решает, какие ключи удалять при достижении лимита памяти.

1. Установка лимитов памяти для стабильности

Предотвращение потребления Redis всей доступной системной памяти имеет первостепенное значение для стабильности хоста. Директива maxmemory устанавливает абсолютный потолок для памяти, выделенной под набор данных (исключая накладные расходы). Если этот лимит достигнут, Redis начнет вытеснять ключи в соответствии с настроенной политикой.

Директива конфигурации: maxmemory

Эта настройка критически важна для производственных сред. Рекомендуется оставлять некоторый запас для задач операционной системы и накладных расходов Redis (например, внутренние структуры данных, буферы репликации).

Пример конфигурации (redis.conf):

# Установить максимальное использование памяти в 4 гигабайта
maxmemory 4gb

Совет: Всегда используйте читаемые суффиксы (например, 100mb, 2gb) для упрощения управления конфигурацией.

Принудительное применение политики памяти

Если maxmemory установлен, а maxmemory-policy остается noeviction, команды, требующие больше памяти, могут завершиться ошибкой после достижения лимита. Для кеша выберите политику вытеснения, которая позволяет Redis отбрасывать старые записи кеша вместо отклонения обычных операций записи.

2. Выбор правильной политики вытеснения (maxmemory-policy)

Эта директива определяет алгоритм, который Redis использует для выбора ключей для удаления при превышении лимита памяти. Выбор правильной политики сильно зависит от паттернов доступа к данным вашего приложения.

Политики для изменяемых и неизменяемых ключей

Политики обычно делятся на категории в зависимости от того, учитывают ли они установленное время жизни (TTL) ключей:

• Volatile (Изменяемые): Учитывают только ключи, у которых установлено время истечения (EXPIRE или SETEX).
• All Keys (Все ключи): Учитывают все ключи, независимо от TTL.

Для чистого кеширующего слоя, где большинство элементов имеют явное истечение, отлично подходят изменяемые политики. Если вы полагаетесь на внешнюю логику приложения для управления устареванием, вы можете предпочесть неизменяемые политики.

Объяснение ключевых алгоритмов вытеснения

A. Наименее недавно использованный (LRU)

Это самая распространенная и часто используемая по умолчанию политика для общего кеширования. Она удаляет ключ, к которому не было доступа дольше всего. Она лучше всего работает, когда паттерны доступа следуют принципу временной локальности (недавно запрошенные данные, вероятно, будут запрошены снова в ближайшее время).

Конфигурация:

maxmemory-policy allkeys-lru

B. Наименее часто используемый (LFU)

LFU отслеживает, как часто к ключу обращались. Он вытесняет ключи с более низкой оценочной частотой доступа. Это хорошо работает, когда ваша рабочая нагрузка имеет стабильный набор популярных ключей, которые должны переживать случайные сканирования или одноразовые чтения.

Конфигурация:

maxmemory-policy allkeys-lfu

C. Вытеснение на основе TTL

Вытеснение на основе TTL полезно, когда ключи имеют значимое время истечения, и ключи, наиболее близкие к истечению, являются самыми безопасными для удаления.

Конфигурация:

maxmemory-policy volatile-ttl

Эта политика учитывает только ключи с установленным истечением. Если у многих ключей нет TTL, Redis может исчерпать вытесняемые ключи и начать отклонять записи.

D. Случайное вытеснение

Случайное вытеснение просто и иногда приемлемо для одноразовых данных кеша, но оно редко является первым выбором, когда ваш кеш имеет четкие паттерны доступа.

maxmemory-policy allkeys-random

3. Устанавливайте TTL последовательно

Политики вытеснения — это предохранительный клапан, а не единственная стратегия инвалидации кеша. Большинство ключей кеша должны иметь истечение, соответствующее бизнес-ценности данных.

Например, страница с деталями продукта может кешировать отрендеренный фрагмент на пять минут:

redis-cli SET product:123:html "$HTML" EX 300

Поиск разрешений пользователя может потребовать гораздо более короткого TTL, так как устаревшие данные более рискованны:

redis-cli SET user:42:permissions "$JSON" EX 30

Избегайте смешивания постоянных ключей в одной базе данных Redis с одноразовыми ключами кеша, если только вы не используете политику allkeys-* и не готовы к тому, что любой ключ может быть вытеснен. Если некоторые данные никогда не должны вытесняться, храните их в отдельном экземпляре Redis или базе данных с другой политикой.

4. Решите, помогает ли сохранение кеша

Для чистого кеша сохранение Redis необязательно. Отключение RDB и AOF уменьшает дисковый ввод-вывод и сложность перезапуска, но все ключи кеша теряются при перезапуске Redis.

save ""
appendonly no

Это приемлемо, когда ваше приложение может восстановить кеш из базы данных. Если прогрев кеша дорог или холодный кеш может перегрузить базу данных, оставьте RDB-снимки или AOF включенными и протестируйте поведение при перезапуске под нагрузкой.

5. Мониторинг здоровья кеша

Используйте метрики Redis, чтобы убедиться, что кеш помогает:

redis-cli INFO memory
redis-cli INFO stats
redis-cli INFO keyspace

Обратите особое внимание на следующие поля:

Метрика	Что она говорит вам
used_memory_human	Текущий объем памяти, потребляемой Redis.
maxmemory_human	Настроенный потолок памяти.
evicted_keys	Вытесняет ли Redis ключи под давлением.
keyspace_hits и keyspace_misses	Обслуживает ли кеш полезные чтения.
expired_keys	Активна ли очистка TTL.

Если evicted_keys быстро растет, а процент попаданий падает, увеличьте память, сократите TTL для низкоценных ключей или разделите шумные рабочие нагрузки в отдельный кеш.

Пример конфигурации кеша

Это разумная отправная точка для экземпляра Redis, предназначенного для одноразовых записей кеша:

maxmemory 4gb
maxmemory-policy allkeys-lfu
save ""
appendonly no

Для кеша, где каждый ключ имеет тщательно выбранный TTL:

maxmemory 4gb
maxmemory-policy volatile-ttl

Используйте CONFIG GET maxmemory maxmemory-policy, чтобы проверить активные настройки:

redis-cli CONFIG GET maxmemory maxmemory-policy

Вывод

Относитесь к настройке кеша Redis как к задаче контроля емкости. Установите maxmemory, выберите политику вытеснения, соответствующую вашему паттерну доступа, задайте явные TTL для ключей кеша и решите, стоит ли сохранение дискового ввода-вывода. Затем следите за процентом попаданий, вытеснениями и ростом памяти, чтобы кеш защищал вашу базу данных, а не становился следующим узким местом.