Что такое Redis? Кэширование, сессии и когда он нужен

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

Что такое Redis и как он работает?

Redis хранит каждое значение под ключом: значением "product:42" может быть строка JSON, значением "cart:alice" список. Поскольку чтение идет из памяти, одна операция обычно занимает меньше миллисекунды. Помимо строк, есть списки, множества, сортированные множества, хеши и потоки (streams), поэтому Redis служит не только кэшем, но и счетчиком, таблицей рейтинга и простой очередью. Каждому ключу можно задать время жизни (TTL); когда оно истекает, ключ удаляется автоматически.

У Redis есть режимы записи на диск (снимки RDB и журнал AOF), но по своей природе он не является основным местом хранения. Данные, которые нельзя потерять, например заказы, платежи и учетные записи, живут в реляционной базе; с выбором поможет наша статья PostgreSQL или MySQL. Redis хранит быстро читаемую копию этих данных.

Зачем нужен кэш?

Каждый раз, когда открывается страница товара, одни и те же запросы снова уходят в базу данных. Кэш на короткое время сохраняет копию результата и отвечает на следующие запросы из нее. Выигрыш двойной: пользователь быстрее получает ответ, а базе не нужно тысячи раз выполнять одну и ту же работу. Не вся скорость страницы зависит от кэша; про изображения, JavaScript и настройки сервера подробнее в статье как ускорить сайт.

Для чего используют Redis?

• Кэш запросов и API: хранить результаты дорогих запросов или ответы внешних сервисов в течение заданного времени.
• Хранилище сессий: когда работают несколько серверов, сессия пользователя лежит в одном месте, доступном всем.
• Ограничение частоты запросов (rate limiting): считать запросы в минуту для IP или пользователя и останавливать тех, кто превысил лимит.
• Очереди и фоновые задачи: ставить в очередь письма, уведомления или формирование отчетов и обрабатывать их в отдельном процессе.
• Рейтинги и счетчики: живые таблицы очков на сортированных множествах, счетчики просмотров и лайков.
• Распределенные блокировки: не дать одной и той же задаче выполняться одновременно на двух серверах, например чтобы запускалась только одна копия задачи по расписанию.

Шаблон cache-aside: как настроить кэш на Redis

Самый распространенный шаблон называется cache-aside (ленивая загрузка). Приложение сначала обращается к Redis; если значение есть, возвращает его. Если нет, читает из базы, записывает результат в Redis с TTL и возвращает. Когда данные меняются, сначала обновляется база, затем удаляется соответствующий ключ; следующее чтение снова положит свежие данные в кэш. Пример на Node.js ниже показывает этот поток:

import { createClient } from 'redis';

const redis = createClient({ url: process.env.REDIS_URL });
await redis.connect();

// Cache-aside: read from Redis first, fall back to the database on a miss.
async function getProduct(id: string, loadFromDb: (id: string) => Promise<object | null>) {
  const key = 'product:' + id;
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const product = await loadFromDb(id);
  if (product) {
    // A TTL keeps stale data from living forever.
    await redis.set(key, JSON.stringify(product), { EX: 300 });
  }
  return product;
}

// On every write, the database is updated first and the cache key is removed.
async function onProductUpdated(id: string) {
  await redis.del('product:' + id);
}

У каждого ключа в кэше должно быть два ответа: когда он умрет сам (TTL) и какая запись его удалит? Ключ без ответа на оба вопроса рано или поздно покажет пользователю устаревшие данные.

Самые частые ошибки кэширования

• Нет TTL: на пути записи, где забыли инвалидацию, устаревшие данные остаются навсегда.
• Данные конкретного пользователя под общим ключом: если ключ не содержит пользователя или права доступа, один пользователь может увидеть данные другого.
• Считать кэш единственной копией: когда Redis перезапускается или вытесняет ключи из-за нехватки памяти, система должна восстановиться из базы.
• Много ключей истекает одновременно: все запросы в одну секунду падают на базу; небольшая случайная добавка к TTL распределяет нагрузку.
• Кэшировать все подряд: хранить редко читаемые или и так быстрые данные значит тратить память без выигрыша.

Когда Redis нужен, а когда лишний?

В приложении, которое работает на одном сервере, с небольшим трафиком и уже быстрыми запросами, Redis означает еще один компонент, который нужно мониторить и резервировать. Сначала стоит измерить медленные запросы, добавить недостающие индексы и попробовать простой кэш в памяти процесса. Redis становится оправданным, когда приложение работает на нескольких серверах и сессии или кэш должны быть общими, когда одни и те же данные читаются много раз в секунду, когда внешний API медленный или платный за каждый запрос, или когда нужны ограничение частоты, очереди или распределенные блокировки. Удобнее всего запускать Redis рядом с приложением при разработке в контейнере; подробнее в статье что такое Docker.

Итог

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