
В настоящее время мы используем Redis в качестве хранилища данных. Я создаю новый раздел, в котором нам нужно ранжировать и разбивать пользователей на страницы. Поэтому я думаю использовать отсортированный набор для хранения ранга и идентификатора пользователя. И хэш для хранения данных профиля пользователя. Коллега обратил мое внимание на то, что нам нужно будет делать много запросов к Redis для получения данных профиля пользователя с помощью HGET. поэтому время на передачу и прием будет проблемой. Я планировал использовать HMGET, но после некоторых исследований я обнаружил, что это может вызвать проблемы, когда Redis кластеризован, потому что ключи хранятся в разных узлах Redis. Я использую phpredis, у него есть сегментирование на стороне клиента (я не понимаю, что это такое).
Я думал сделать так:
классифицировать
zadd userRank 1 5
zadd userRank 2 2
zadd userRank 3 4
zadd userRank 4 3
Профиль пользователя
hset userProfile user:5 "{'userId':'5','name':'usera'}"
hset userProfile user:4 "{'userId':'4','name':'userb'}"
hset userProfile user:3 "{'userId':'3','name':'userc'}"
hset userProfile user:2 "{'userId':'2','name':'userb'}"
1) Будет ли HMGET нормально работать в кластеризованном Redis?
2) если нет, что я могу сделать?
3) есть ли лучший способ реализовать это?
решение1
- HMGET должен работать в кластеризованном Redis, поскольку он связан только с одним ключом. Каждый HMGET будет перенаправлен на узел, содержащий ключ
- /
- Не очень хорошая идея хранить каждого сериализованного пользователя в хэше, так как вы потеряете возможность запрашивать/добавлять/удалять некоторые поля.
Предпочитать:
hmset user:5 userId 5 name usera
hmset user:4 userId 4 name userb
hmset user:3 userId 3 name userc
hmset user:2 userId 2 name userb
Ваша схема ранжирования в порядке. Чтобы получить и разбить на страницы пользователей с самым высоким рейтингом, просто сделайтеZREVRANGEBYSCOREа затем запросить каждого пользователя.
Примечание:кластеризацияэто не то же самое, чтошардинг.