Масштабируемая обработка сессий

Статьи не читал, но было дело, писал систему для расшаривания сессии в soa-системе. Ключевой момент - иммутабельность сессии на время обработки всего запроса. Идентификатор сессии пробрасывался между сервисами хидером, сессия возвращяоась из кэша. Хранилище выбирай сам исходя из требований, бенчмарки все врут. Кстати субоптимальное решение - просто хранить сессии в базе (у меня был постгр). На нагузке в 500 рпс оно жило, на тысяче заменили на мемкеш (та еще бяка, не используй никогда для хранения сессий). Короче все там просто, не знаю зачем ты паришся. Еще такой хинт: при логине пользователя вся часто используемая инфа скидывается в сессию, и она используется как быстый кэш.

Если бы делал сейчас, вот что поменял бы: забил бы на rest, http оставил бы, но использовал бы только post, а сессию прикреплял бы к каждому запросу целиком в служебном поле в компактном виде (protobuf). Сессии хранил бы в любой бд, мемкеш только как кеш поверх бд. Если пользователей не шибко много, можно все сессии хранить просто в хешмепе, это тоже работает и имеет самую высокую производительность.

но использовал бы только post

o_O. Вы без ссылок программируете, сэр?

Это внутри soa системы только.

Да, и наружу сессию лучше не выдавать, только хеш в куку.

Ну выдают, почему же, иногда сериализируют и шифруют

Во-первых сразу появляется ограничение на размер - большая сессия будет увеличивать трафик у клиента. Потом не тривиально решается задача взять и разлогинить пользователя (сраный бот, например). Но в каких-то простых случаях имеет право на жизнь, да.

субоптимальное решение - просто хранить сессии в базе (у меня был постгр). На нагузке в 500 рпс оно жило, на тысяче заменили на мемкеш (та еще бяка, не используй никогда для хранения сессий)

Таблица в постгресе была какая? TEMP UNLOGGED ?

Нет, обычная.

Там на запись нагрузка фигня. Оперативки на сервере много было, это да.

Это я к тому, что правильные параметры при создании таблицы + правильные параметры в postgresql.conf = не сильно хуже memcache. Вообще задач, для которых memcache сильно лучше грамотной работы с бд я не знаю, выйгрыш от него конечно есть, но он не настолько большой, чтобы плодить новые сущности (ИМХО).

выйгрыш

КЛБ.

Да, это известная тема. Но в моем опыте такой подход оборачивался тем, что IO между базой и бекендами становится узким местом. Помню, админам пришлось второй сетевой интерфейс в сервер СУБД зафигачить. Мемкеш же можно пошардить. Плюс можно еще локальные кешы заюзать, но тут проблема с инвалидацией, лучше локальные кеши использовать если для набора данных не требуется строгая консистентность, а инвалидироавть через шину сообщений (zmq, amqp)