Знакомство: зачем Go-сервису Redis

Redis — сервер баз данных, который держит данные в оперативной памяти, а не на диске: чтение и запись выполняются за доли миллисекунды, тогда как даже хорошо настроенная дисковая СУБД отвечает за миллисекунды и медленнее. Команды Redis обрабатываются по одной, в одном потоке: параллельные запросы от вашего Go-приложения выстраиваются в очередь, зато каждая операция атомарна — два инкремента счётчика из разных горутин не затрут друг друга, мьютексы не понадобятся. Отсюда два практических следствия. Первое: пропускная способность одного инстанса ограничена одним ядром, хотя на обычном железе это десятки и сотни тысяч простых операций в секунду — для кэша и сессий хватает почти всегда. Второе: длинные команды блокируют всех, поэтому перебор всей базы через KEYS или гигантские значения в Redis не тащат. Данные при этом не обязаны исчезать при перезагрузке: Redis умеет сохранять снимки на диск (RDB) и вести журнал изменений (AOF), после рестарта он восстанавливает состояние. Но помнить стоит главное: Redis — про скорость и недолговечные данные, а не про гарантии хранения.

Вопрос «зачем нужен redis» честнее отвечать задачами, а не определениями. Первая роль — кэш: тяжёлый SQL-запрос или ответ внешнего API кладётся в Redis на десять минут, и из десяти тысяч обращений до базы доходит десяток. Вторая — сессии: пользователь логинится, сервер пишет его данные в Redis, и любой из пяти инстансов бэкенда достаёт сессию по cookie — состояние больше не привязано к конкретной машине, балансировщик крутит трафик как хочет. Третья — счётчики и лимиты: просмотры статьи, попытки входа, rate limit — атомарные операции в один поток делают это безопасно и без блокировок. Четвёртая — очереди: списки и потоки Redis превращаются в простой механизм фоновых задач ровно до того момента, когда нагрузка оправдает Kafka. Пятая — рейтинги и тренды: сортированные множества хранят топ игроков с обновлением очка за одну команду. Заметьте закономерность: везде данные читаются часто, живут недолго и допускают восстановление после потери. Как только задача перестаёт этим свойствам соответствовать — возвращаемся в Postgres и не геройствуем.

С Memcached Redis сравнивают реже, чем десять лет назад, но вопрос живой. Memcached — многопоточный кэш ключ-значение: очень быстрый, предельно простой, без структур данных, персистентности и каналов событий. Он до сих пор хорош, когда нужен тупой гигантский кэш строк и ничего больше. Redis умеет то же самое плюс структуры, срок жизни ключей с точностью до миллисекунд, снимки и журналы, репликацию и Pub/Sub — и берёт за это один процесс вместо десятка. С Postgres сравнение вообще не о скорости: это инструменты для разных слоёв архитектуры. Postgres — источник правды с транзакциями, внешними ключами и диском; Redis — слой скорости для недолговечных данных. Типичный зрелый сервис живёт с тремя хранилищами: Postgres для данных, Redis для горячего, поисковый движок для текстового поиска. Практическое правило, которое я применяю на code review: если потеря данных из хранилища ломает бизнес — это база; если просто заставит пользователей перелогиниться — Redis.

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

За Go-кодом Redis стоит библиотека go-redis: проект вырос из личного репозитория автора и в 2022 году переехал в организацию redis на GitHub — с тех пор путь импорта выглядит как github.com/redis/go-redis/v9, и клиент числится рекомендуемым самой Redis. Девятая мажорная версия сделала контекст обязательным параметром каждой команды — примерно как database/sql давно живёт с context в сигнатурах. Для нас это значит: старые туториалы с вызовами rdb.Get(key) без контекста описывают восьмую версию, и копировать их сигнатуры не стоит. Альтернативы существуют — redigo старше и ближе к ручной работе с протоколом, rueidis моложе и агрессивнее по производительности, — но по количеству проектов, документации и ответов на Stack Overflow go-redis держит первое место, поэтому курс построен на нём. Установка и первое подключение к Redis из Go — тема следующего урока, а пока закончим обзор меню второго кода.

Спорное мнение, которое я защищаю на архитектурных созвонах: пока сервис один и трафик скромный, Redis можно не заводить вовсе. Инстанс — это не только память, но и новая точка отказа, мониторинг, бэкапы и ещё один участник дежурного чата; монолит вместо него держит горячие данные в карте с мьютексом, а тяжёлые запросы ускоряет индексом в Postgres. Граница применимости конкретная: как только инстансов становится два и больше, карта с мьютексом перестаёт работать — состояние нужно делить между процессами, и здесь Redis вне конкуренции. То же с фоновыми воркерами, очередями задач и распределёнными лимитами: один процесс решает их в памяти, несколько — уже про Redis. Проверка перед внедрением честная: назовите задачу, которую не решает текущая связка, и покажите, где она болит в цифрах. Ответа нет — не тащите второй этаж ради строчки в резюме.