Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 В любом проекте присутствуют сложные структуры, которые нужно кэшировать. Например, профиль пользователя. Он состоит из нескольких полей: идентификатор, электронная почта, номер телефона и тд. Возникает вопрос: как лучше хранить такие структуры в Redis?

2 Первое интуитивное решение - это хранить каждое поле по отдельному ключу.

3 Допустим, есть пользователь с ID56, с электронной почтой<a>user@test.com</a>и номером телефона+7-111-111-11-11. Он будет записан следующим образом:

4 Преимущества:

5 <ul><li>интуитивно понятная модель хранения</li>

6 <li>просто получить значение конкретного поля</li>

7 </ul>Недостатки:

8 <ul><li>количество хранимых ключей растет в кратном размере от количества пользователей</li>

9 <li>при обновлении профиля будет происходить N запросов</li>

10 <li>так как каждое поле хранится в своем ключе, обновление информации юзера происходит не атомарно, и несколько параллельных запросов на обновление могут привести к неконсистентному состоянию кэша. Например, пользователь поменял почту наemail2, а номер телефона наphone2во время недоступности сервера, а потом передумал и решил сразу сменить наemail3иphone3. Когда сервер восстановится, к нему придет сразу 2 запроса на обновление. Оба запроса обрабатываются параллельно и каждое поле обновляется атомарно. Такая логика может привести к тому, что в кэше почта будетemail2, а телефон phone3 и наоборот. Получается, что состояние профиля в Redis неконсистентно и состоит из 2х разных обновлений. При этом в реляционной базе данных поля будут консистентны:email2+phone2илиemail3+phone3</li>

11 </ul>Хранить каждое поле в отдельном ключе - не лучшее решение в рамках данной задачи. Попробуем второй вариант с использованием сериализации объекта. Например, перед записью конвертировать объект в JSON строку:

12 Преимущества:

13 <ul><li>один атомарный запрос на запись/обновление всего профиля</li>

14 <li>количество хранимых ключей равно количеству профилей</li>

15 </ul>Недостатки:

16 <ul><li>Без модуля RedisJSON нельзя получить значение одного поля, нужно достать всю структуру</li>

17 <li>дополнительная логика сериализации/десериализации со стороны кода бэкенда</li>

18 </ul>Стоит отметить, что в некоторых задачах не требуется получать отдельно поля структуры и тогда вариант с сериализацией можно использовать.

19 <h2>Redis Hashes</h2>

20 К счастью, Redis предоставляет структуру данных для хранения сложных объектов - Hashes. В языках программирования эту структуру так же называют словарем, мапой или ассоциативным массивом.

21 Используя Hashes, профиль юзера будет храниться в единственном ключе. В любой момент можно получить значение отдельного поля объекта. Также в приложении не будет логики преобразования данных перед записью.

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

23 Формат хранимых переводов будет следующим:

24 Основной ключ - это идентификатор перевода. Для простоты в данном примере используется английское слово как идентификатор. Внутри словаря лежит структура: язык -> перевод.

25 <h3>Запись</h3>

26 Первым делом запишем несколько переводов в нашу систему с помощью команды hset key field value [field value ...]:

27 Команда hset возвращает количество добавленных полей. Если ключа не существовало, то он будет создан.

28 Похоже, что в переводе словаhelloна русский язык есть ошибка. Правильный перевод - это "здравствуйте". Для обновления поля используется та же команда hset:

29 В ответе вернулся нуль, потому что ничего не добавилось и только изменилось существующее поле.

30 <h3>Чтение</h3>

31 Когда пользователь заходит на стартовую страницу платформы, его нужно поприветствовать на понятном языке. Например, пользователь находится в России, и нужно получить русский перевод приветствия с помощью команды hget key field:

32 Может показаться, что в ответе вернулась несуразица, однако здесь нет ошибки. Redis сохраняет строки так, как ему передают. Когда в терминале запрашиваются значения, возвращается их UTF-8 интерпретация. Когда эта строка обрабатывается со стороны бэкенда, получается валидный русский текст.

33 Если необходимо получить всю структуру, в данном примере все переводы, используется команда hgetall key:

34 <h3>Удаление</h3>

35 Если какой-то перевод оказался лишним, то его можно удалить командой hdel key field [field ...]:

36 В ответе на команду hdel возвращается количество удаленных полей.

37 <h2>Резюме</h2>

38 Хранить сложные объекты можно по-разному. Это напрямую зависит от проекта. Однако чаще всего следует использовать встроенные типы данных Redis для максимальной производительности и функциональности. Несколько преимуществ использования Redis Hashes:

39 <ul><li>один атомарный запрос на запись/обновление всего объекта или отдельных полей</li>

40 <li>количество хранимых ключей равно количеству объектов</li>

41 <li>можно получить/обновить/удалить значение одного поля</li>

42 <li>эффективный формат хранения, абстрагированный от бэкенда</li>

43 </ul>