Хэши: HSet, HGet и профили пользователей

Ментальная модель хэша — map[string]string, живущий под одним ключом Redis. Снаружи это обычное имя вроде user:42:profile, изнутри — набор полей со значениями-строками. Записывает поля команда HSET: go-redis v9 принимает map с любыми простыми значениями и сам конвертирует числа и булевы в строки. Читает целиком HGETALL, по одному полю — HGET, удаляет поле HDel, считает поля HLen, отдаёт список имён HKeys. Для record-структур у HSet есть бонус: он принимает структуру Go напрямую и раскладывает поля по именам — их можно переопределить тегом redis, как json-тегом в сериализации. Я всё же чаще передаю map: имена полей видны прямо в месте вызова, и правка модели не меняет запись в Redis за моей спиной. Важная граница типа: значение поля — строка. Вложенную структуру или срез в поле не положить — только сериализовать отдельно; числа и булевы клиент конвертирует, но дальше строковой плоскости хэш не уходит. TTL при этом ставится на весь ключ целиком — отдельному полю срок жизни задать нельзя, к этому вернёмся ниже.

У хэшей два уровня отсутствия, и ошибка новичка — свалить их в один. Ключ может не существовать целиком: тогда и Get, и HGet, и HGetAll работают с пустотой. А может существовать, но без нужного поля: user:42:profile живёт, email в него не записывали. HGet по такому полю возвращает ровно ту же константу redis.Nil, что и чтение несуществующей строки — проверка через errors.Is идентична строковому кэшу, новая семантики не заводится. Обратно-симметричное правило защищает HDel: удаление несуществующего поля не ошибка, команда просто отвечает нулём удалённых записей. Практическое следствие двух уровней: код, который различает «пользователя нет» и «поля нет», обязан сначала проверить существование ключа — через Exists или по содержимому HGetAll. Для профилей это обычно неважно: если ключа нет, вернётся пустая карта, и логика «сходить в базу» отработает одинаково. Но для авторизационных структур, где пустая сессия и отсутствующая сессия ведут на разные экраны, различие становится архитектурным — и там лучше явная проверка Exists.

Главный выигрыш хэша проявляется в записи. HSet умеет обновлять одно поле, не трогая остальные: переименование пользователя — одна команда, и параллельный запрос, читающий город, видит целостные данные, а не полдокумента между перезаписями. Гонки из JSON-мира исчезают конструктивно: нет цикла прочитать-изменить-записать, значит, нет окна, в котором два писателя затирают друг друга. Счётчики внутри хэша — отдельная гордость: HIncrBy увеличивает поле на заданное число атомарно, на стороне сервера, без чтения текущего значения. Профиль с полем likes растёт одной командой, и сто одновременных лайков дадут сто прироста, а не пятьдесят, как случилось бы с read-modify-write из двух шагов. Отсутствующее поле считается нулём: первый HIncrBy создаст его со значением инкремента. Вокруг ядра HSet и HGet собран полный набор утилит: HDel удаляет поля, HLen считает их, HKeys отдаёт имена без значений, HMGet читает несколько полей одним рейсом. Полный справочник не нужен — эти команды встречаются по мере задач, а базовая четвёрка покрывает профильные сценарии целиком.

Правило выбора у меня простое: читается целиком и пишется целиком — JSON; меняется по частям — хэш. Каталог товаров, результат отчёта, страница ленты — это один объект, который живёт и умирает целиком, и JSON-строка с Unmarshal даёт типы бесплатно. Профиль, сессия, конфигурация сервиса — набор независимых полей с разной частотой изменений, и здесь хэш экономит и трафик, и код. Ограничение, которое ломает планы чаще всего — строковые значения: как только внутри объекта появляется вложенный массив тегов или список заказов, хэш перестаёт вмещать его без повторной сериализации, и удобство испаряется. Второе ограничение — TTL только на весь ключ: если email должен жить час, а имя — сутки, вам нужны разные ключи или отдельная схема. Третье — распаковка типов: HGetAll вернёт строки, и каждое число придётся приводить strconv-ом, тогда как Unmarshal делает это сам. В реальных сервисах типы живут вместе: профиль — хэш, его заказы — JSON-строки, и это нормально, потому что типы данных Redis — инструменты, а не религия.