Введение в Redis
Этот модуль нужен, чтобы использовать Redis как инженерный инструмент, а не как универсальную кнопку "сделать быстро". Redis отлично подходит для горячих данных, TTL, счётчиков, rate limiting, простых очередей, pub/sub и некоторых координационных задач.
Но Redis не заменяет основную базу данных по умолчанию. Его сила в скорости и простых структурах в памяти, а слабые места появляются там, где нужны сложные запросы, строгая долговечность, большие объёмы данных или неаккуратная работа с ключами.
Что будет внутри
Разберём модель in-memory хранилища, базовые структуры данных, команды, Go-клиент, кеширование, TTL, eviction, persistence, replication, cluster, locks, rate limits, streams и pub/sub.
В рабочей системе Redis чаще всего стоит рядом с основным хранилищем:
Application -> Redis for hot/temporary data
Application -> PostgreSQL for source of truth
Как понять, что освоил
Вы освоили модуль, если можете выбрать подходящую структуру данных, задать ключи и TTL, объяснить cache-aside, не сломать систему big keys, отличить Redis lock от транзакционной гарантии и понимать, что произойдёт при рестарте или вытеснении данных.
Рабочие ориентиры
- Redis ускоряет частые простые операции, но не отменяет проектирование основного хранилища.
- TTL и invalidation важнее, чем сам факт кеширования. Устаревшие данные тоже баг.
- Ключи, размеры значений и cardinality надо проектировать заранее. Иначе Redis быстро становится скрытой production-проблемой.
- Для каждого сценария заранее выбирайте fail-open/fail-closed policy: кеш уроков может деградировать в PostgreSQL, а rate limit для login обычно безопаснее закрывать строже.
- Observability нужна с первого дня: hit/miss ratio, ошибки Redis, latency, eviction, memory и slowlog должны быть видны до инцидента.
- Security не "потом": Redis не должен быть публичным, токены и сессии в нём требуют ACL/TLS/backup hygiene так же, как обычная база.
Связь с RateDesk
В проекте RateDesk Redis появляется как адаптер к use case: кеш популярных курсов/конверсий, TTL, invalidation на обновлении курса и возможный rate limit для API. Теория в этом модуле объясняет, какие решения надо зафиксировать в cache contract, но сами issue, acceptance criteria и тесты живут в проектном треке.