Redis: структуры данных и роль кеша

Оглавление · Ключи и уровни кеша · Модели хранения

Задача: объяснить, что даёт Redis и какие обязательства остаются у приложения. Нужны ключи, TTL, промах и источник истины. Redis в Atmanki не подключён.

Это не замена SQL по умолчанию

Redis предоставляет структуры по ключам: строки, hashes, списки, sets, sorted sets и streams. Конкретная структура определяет операции: set membership и ранжирование по score — разные запросы. Типы Redis.

Учебные роли: кеш публичного чтения, ограничение частоты, временное состояние, ранжирование. Каждая требует своего контракта. Наличие streams не создаёт автоматически процесс фоновой обработки; у проекта сейчас нет таких задач.

Если PostgreSQL хранит редакторский контент, Redis-копия не получает автоматически уникальность slug, связи, публикацию и транзакции CMS. Сначала задайте источник истины и допустимую потерю данных, затем роль дополнительного сервиса.

Cache-aside

flowchart TD
  Request["Чтение публичной статьи"] --> Cache{"Пригодная копия в Redis?"}
  Cache -->|Да| Hit["Вернуть копию"]
  Cache -->|Нет| Source["Прочитать источник"]
  Source --> Validate["Проверить и сформировать публичный результат"]
  Validate --> Store["Сохранить копию с TTL"]
  Store --> Return["Вернуть результат"]

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

Ключ должен включать существенные измерения: версия формата, идентификатор, язык и область доступа. Публичные и персональные данные нельзя смешивать. TTL ограничивает переиспользование, но не гарантирует мгновенную свежесть после записи.

Команды и границы

Иллюстрация для отдельного учебного Redis, не команда для серверов проекта:

SET lesson:article:first "Учебная копия" EX 60
GET lesson:article:first
DEL lesson:article:first
GET lesson:article:first

SET с EX задаёт значение и срок одной командой. Раздельные SET и EXPIRE оставляют окно сбоя между ними. SET. После DEL GET не находит значение. Этот короткий сценарий не проверен на запущенном Redis и не моделирует конкурентные async-чтения.

Старое чтение может завершиться после инвалидирования и вернуть устаревшую копию в кеш. Массовый miss может нагрузить источник. Смягчение требует политики версий, слияния работы или ограничений, а не одного DEL. Простой lock тоже требует анализа срока владения, отказов и безопасного освобождения.

Недоступность, память и устойчивость

Для необязательного кеша можно читать источник при отказе Redis, но поток промахов способен перегрузить его. Ограничьте работу и наблюдайте hit rate, задержки, ошибки и вытеснение. Для лимитера или сессий режим отказа имеет другой смысл: общий «fallback на БД» не заменяет проектирование.

Redis может сохранять данные через RDB-снимки и AOF-журнал. Гарантии потери при сбое зависят от выбранной политики; хранение в памяти не означает отсутствие persistence. Persistence. Репликация не является резервной копией от ошибочного удаления.

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

Практика

Нарисуйте чтение при hit, miss, отказе Redis и отказе источника. Для каждого укажите ответ пользователю и предел нагрузки. Затем разберите гонку: старое чтение → изменение источника → DEL → завершение старого чтения.

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