Как организовать сессии пользователей с помощью Redis?

Question

[blabs]

Вводные
- Под одним аккаунтов может сидеть только один пользователь
- У сессии есть срок жизни = 48ч
- Токены нужны для того, чтобы обрабатывать API запросы

Вариант: Помещаем в Redis токен и идентификатор пользователя (id), а также устанавливаем TTL, по истечению которого запись удаляется. При каждом запросе (GET/POST/PUT/DELETE) мы обновляем токен.

Вопросы

1. На сколько применим выше вариант организации пользовательских сессий?
   
2. Есть ли инструмент, который позволит искать запись в Redis по значению, а не ключу?
   
3. Есть ли альтернативные решения при условии, что токены читать нужно через Redis? К примеру, последний токен хранить в PostgreSQL и при его обновлении там также обновлять
   

Comments

[blabs]

Немного расширю вводные

UserCases

1. Регистрация нового пользователя (вызов метода Reg)

Фронт отправляет POST запрос с данными, которые нужно записать в таблицу Members, сгенерив предварительно UID и повестив его вместе с данными в эту таблицу, а также сделать запись в Redis. В ответ сервер отдает UID

2. Авторизация пользователя (вызов метода Login)

Фронт отправляет запрос c данными для авторизации, сервер идет в таблицу Members, берет данные, в частности uid, генерит новый, заменяет старый в Members, а также обновляет его в Redis. Возвращает данные пользователей вместе с UID

3. Запись прогресса

Фронт отправляет запрос с UID. Сервер проверяет его в Redis, если он валидный, делает запрос в таблицу Members, обновляет соответствующие данные, а также перезаписывает UID и обновляет его в Redis

4. Запрос списка наград

Фронт отправляет UID и CONTEST_ID. Сервер проверяет валидность UID в Redis, если валидный идет в таблицу Rewards и берет все награды для Campaign_ID, а также проверяет какие награды получал пользователь в таблице Members -> Progress.

ЧТО ВИДНО ИЗ КЕЙСОВ
- Практически во всех методах идет обращение в таблицу members
- UID проверяется на валидность до момента обработки основного запроса
- Обновляем UID при POST/PUT/DELETE запросах в таблице Redis/PostgreSQL + TTL в Redis

ВОПРОС, НУЖЕН ЛИ НАМ REDIS И ПОЧЕМУ?

1. С одной стороны у нас появляется дополнительная прослойка
   
2. С другой стороны это прослойка уменьшает объем запросов в основную БД при условии, что будет достаточное кол-во не валидных запросов со старыми токенами. Но какой их процент в реальности?
   
3. Если действовать только на базе PostgreSQL, у нас добавляется логика обработки срока жизни токена. Т.е. нужно добавить поля когда выдан и сколько действует uid. Возможно проверка увеличит скорость обработки запроса
   

[blabs]

Вводные
- Под одним аккаунтов может сидеть только один пользователь одновременно
- У сессии есть срок жизни равный 48ч

Answer 1

[Andrey Tsvetkov]

1. Очень даже приемлемый вариант.
2. Такого инструмента нет. Выбираете все ключи по маске, далее сравниваете значения. То есть все ваши сессии должны иметь примерно такой вид sessions:session_id, делаете выборку ключей по маске sessions:* и ищете нужное значение перебором.

При каждом запросе (GET/POST/PUT/DELETE) мы обновляем токен.

обновлять надо TTL для записи

Comments

[blabs]

Андрей, спасибо. Дополнил комментарий вводными данными и уточняющим вопросом. Зачем нам в этом случае Redis, почему нельзя ограничиться только PostgreSQL?

[Andrey Tsvetkov]

PostgreSQL не потянет и пятой части от ожидаемой нагрузки. Вернее можно, конечно, организовать кластер из 4-5 машин и он потянет такую нагрузку, но оно того не стоит. Можете посмотреть ещё в сторону любой key/value базы, но более чем уверен, redis-а будет более чем достаточно. Сам для сессий использую схему, подобную той, что вы описали на базе Redis

[blabs]

Andrey Tsvetkov, есть возможность описать как именно у вас организованы пользовательские сессии? Что храните, при каких событиях перезаписываете?

[Andrey Tsvetkov]

Ничего сверхъестественного. У апи есть приватная часть и публичная. Для доступа к приватной части необходима авторизация. После авторизации в куку пишем айдишник(рандомная генерация), так же данный ID используем в качестве ключа в redis, в котором храним json с данными по пользователю: user_id, client_id, role. Срок жизни ключа в redis 10-60 минут(зависит от настроек клиента). При запросах к приватной части api вытаскиваем id из куки, ищем его в redis, достаём данные, проверяем возможность доступа к конкретному ресурсу с конкретным действием(получить, создать, обновить, удалить), если всё сходится, возвращаем результат запроса, а так же обновляем TTL в redis и обновляем куку в браузере.

Answer 2

[Пума Тайланд]

Если мало сессий то пойдёт и постгрес, просто постгрес уже на тысячу коннекторы ляжет на спину а редис далее не чихнет

Comments

[blabs]

Спасибо за обратную связь.

Подскажите, описанная выше схема с Redis по вашему опыту жизнеспособна или мы что то упустили?

[blabs]

Вводные
- Под одним аккаунтов может сидеть только один пользователь одновременно
- У сессии есть срок жизни равный 48ч
- Ожидается до 20к одновременных запросов на сервер

[Пума Тайланд]

blabs, а какие у вас с этим проблемы? Прототип накидать один час, запустить какой нибудь тест минут десять

[blabs]

Пума Тайланд, мы в целом так и планировали. Но хотели больше опираться на мировую практику и опыт на высоконагруженных проектах. Мы думали в сторону того, чтобы в Redis запихать и другие параметры настроек, которые статичные и можно восстановить из основной БД. Но опять же, интересен реальный опыт. Чем нам симпатизирует PostgreSQL, так это то, что он уже может сам разложить строку в Json формат, что уменьшает операции на самом сервере.

[Пума Тайланд]

blabs, не очень понятно зачем вам это надо, приведите все в джсон и ничего не раскладывайте