Redis, истечение сеанса и обратный поиск

В настоящее время я запускаю веб-приложение и хочу использовать Redis для хранения сеансов. При входе в систему сеанс вставляется в Redis с соответствующим идентификатором пользователя, а срок действия истекает через 15 минут. Теперь я хотел бы реализовать обратный поиск сеансов (получить сеансы с определенным идентификатором пользователя). Проблема здесь в том, что я не могу выполнить поиск в ключевом пространстве Redis, как это реализовать. Один из способов - установить redis для каждого userId, содержащий все идентификаторы сеанса. Но так как Redis не разрешает истечение срока действия элемента в наборе, а сеансы истекают, в наборах будет тонна несуществующих идентификаторов сеанса.

Каким будет лучший способ удалить идентификаторы из наборов при истечении срока действия ключа? Или, есть ли лучший способ выполнить то, что я хочу (обратный поиск)?

Ответ 1

В текущей ветке релиза Redis (2.6) вы не можете получать уведомления, когда элементы истекли. Вероятно, это изменится в следующих версиях.

Тем временем, чтобы поддержать ваше требование, вам необходимо вручную реализовать поддержку уведомлений об истечении срока. Итак, у вас есть:

session:<sessionid> -> a hash storing your session data - one of the field is <userid>
user:<userid> -> a set of <sessionid>

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

Когда вы создаете сеанс 10 для пользователя 100:

MULTI
HMSET session:10 userid:100 ... other session data ...
SADD user:100 10
ZADD to_be_expired <current timestamp + session timeout> 10
EXEC

Затем вам нужно создать демона, который будет опросить zset, чтобы определить истечение сеанса (ZRANGEBYSCORE). Для каждого истекшего сеанса он должен поддерживать структуру данных:

вывести сеанс из zset (ZREMRANGEBYRANK)
восстановить сеанс userid (HMGET)
удалить сеанс (DEL)
удалить сеанс из набора userid (SREM)

Основная трудность заключается в том, чтобы гарантировать отсутствие условий гонки, когда демон опросит и обработает элементы. См. Мой ответ на этот вопрос, чтобы узнать, как он может быть реализован:

как обрабатывать сеанс expire basing redis?