go-redis v9: установка и первое подключение

Установка клиента — одна команда go get, как для любой библиотеки Go. Если модуля в папке ещё нет, сначала go mod init с именем модуля, например example.com/cache: без go.mod менеджер зависимостей не знает, куда записывать пакет. Сам путь импорта читается так: домен redis на GitHub — организация, в которую переехал проект в 2022 году; go-redis — репозиторий; /v9 — мажорная версия по правилам семантического версионирования Go, без неё компилятор не найдёт пакет. Имя пакета при этом осталось прежним — redis: импортируете github.com/redis/go-redis/v9, а в коде обращаетесь redis.NewClient, без алиасов и переименований. После go get в go.mod появится строка с версией вида v9.x.x, а в коде — готовый к использованию пакет. Старые туториалы с восьмой версией компилируются редко и учат API без контекстов, поэтому копировать импорты из статей до 2022 года — плохая идея.

Подключение к Redis в go-redis собирается из двух частей: конфигурация redis.Options и фабрика redis.NewClient, которая возвращает клиент. Клиент потокобезопасен и держит пул соединений внутри, поэтому в приложении его создают один раз и переиспользуют, а не строят заново на каждый запрос — это не httputil-клиент из туториалов, где за соединением следишь сам. Полный скелет с проверкой связи — ниже; он же станет шаблоном для всех примеров курса.

Типичная ошибка, которая проявляется не сразу: redis.NewClient вызывается в хендлере при каждом обращении. Несколько дней ничего не происходит, потом сервис начинает жить странно — растёт число открытых сокетов, в логах мелькают задержки на установку связи, а в пики соединения упираются в лимит операционной системы. Причина в том, что каждый клиент тащит собственный пул, и большинство его соединений простаивает: на сотню одновременных запросов приходит сотня пулов по несколько связей. Клиент в go-redis потокобезопасен именно затем, чтобы его создавали один раз — на старте приложения, в main или в конструкторе зависимостей — и передавали всем, кому нужен доступ. Отдельный клиент оправдан разве что для второго сервера или изолированной задачи с другими таймаутами. Увидели NewClient вне инициализации — вопрос на code review: зачем?

Спорное мнение из моих привычек: panic на провале первого Ping — нормально, и убирать его из скелета не нужно. Скрипт или утилита без Redis бессмысленны, и честнее упасть сразу с понятной ошибкой, чем отрабатывать впустую и падать дальше с запутанным стеком: фейл-фаст экономит время разбора. Граница применимости — долгоживущие сервисы: там паника на старте превращается в цикл рестартов, поэтому вместо неё ставят ретраи с дедлайном, а после порога всё-таки паникуют, чтобы оркестратор перезапустил контейнер. В HTTP-хендлерах панике вообще не место: живость проверяет Ping на /healthz, и он же даёт балансировщику сигнал вывести под из ротации. Одно правило объединяет все три мира: ошибки старта нельзя глотать — сервис, который притворяется живым, вредит больше упавшего.

redis.NewClient не устанавливает соединение в момент вызова: клиент создаётся мгновенно, а первое реальное подключение произойдёт при первой команде. Это удобно — конфигурацию можно строить заранее, а живость сервера проверять отдельно; для этого и существует Ping, дешёвый health-check, который часто вешают на эндпоинт /healthz. Пул соединений клиент открывает и закрывает сам: если сервер ночью перезапустился, он восстановит связи без вашего участия — переподключение его работа, а не ваша. Ваш долг один — закрыть клиент при завершении приложения через rdb.Close(), чаще всего с defer сразу после создания. В тестах этот же факт спасает: NewClient с несуществующим адресом не упадёт до первой команды, поэтому конструктор спокойно живёт в setup-функции.

Кейс, который ломает уверенность в скелете урока: docker-compose поднимает приложение и Redis вместе, контейнер базы уже зелёный, а Ping в приложении всё равно падает с connection refused. Причина — два разных события: контейнер запущен и сервер готов принимать команды. Redis инициализирует свои структуры не мгновенно, и в этот промежуток порт либо ещё не слушается, либо слушается с отказами. Лечится по-разному в зависимости от окружения: в docker-compose есть depends_on с условием service_healthy и healthcheck, в Kubernetes — readiness-пробы и init-контейнеры, в простом скрипте — цикл с ретраями и паузой. Смысл один: старт приложения не должен зависеть от того, успел ли сосед приготовиться. Пара ретраев на Ping с задержкой в полсекунды почти всегда закрывает вопрос и стоит три строки кода. Без них старт иногда проходит, а иногда падает — самая неприятная разновидность бага, воспроизводимая только на деплое.

В v9 каждый метод клиента первым параметром принимает context.Context — принципиальное отличие от восьмой версии, где контекста не было вовсе. Контекст даёт единую механику отмены и таймаутов: если клиент запроса ушёл, отменяется и обращение к Redis; если сервер завис, context.WithTimeout оборвёт ожидание и вернёт ошибку дедлайна. В примерах курса стоит context.Background() — контекст без дедлайна, нейтральный для скриптов; в реальном HTTP-сервисе вместо него передают контекст запроса, полученный от хендлера, а точечные таймауты навешивают там, где важна скорость ответа. Привычка одна: контекст — не формальность, а ручка, за которую операцию можно выключить. Мертвой и живой сети с точки зрения кода не отличить, и спасает только дисциплина: подробный разбор — в отдельном уроке про контекст и таймауты.