Share Сессии между экземплярами tomcat (без использования Sticky Sessions)

Question

У меня будет 3 сервера Tomcat и балансировщик нагрузки, который отправляет запросы без использования 'sticky sessions'.

Я хочу поделиться данными сеансов между серверами, и я думаю, что они сохраняют их в БД. Я хотел бы использовать memcached в качестве слоя перед моей БД, чтобы быстрее обслуживать запросы и don't put my db under heavy load.

Я думаю о предоставлении моего настроенного диспетчера tomcat, который использует memcached, прежде чем получать/сохранять данные сеанса в БД, поскольку на данный момент я не вижу прозрачного способа сделать это (это означает, что мне нужно будет управлять им снова в случае, если я переключусь на другой сервер приложений).

Это хорошее решение или вы видите лучший подход?

Answer 1

Мы делаем аналогичную вещь в нашем приложении (Weblogic, но это не имеет значения), где у нас есть уникальный ключ сеанса, который хранится в виде файла cookie в браузере. Затем этот ключ будет использоваться при каждом запросе для восстановления соответствующих данных сеанса из базы данных.

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

Answer 2

Я думаю, Terracotta Web Sessions - это то, что вы хотите.

Answer 3

Сохранение состояния сеанса вне серверов приложений (Tomcat в вашем случае), является очень распространенной и рекомендуемой конфигурацией для крупномасштабных веб-сайтов. Обычно это делается в поисках архитектурного стиля под названием Shared Nothing.

Вы можете сохранить свое состояние в нескольких разных местах: db, memcached, коммерческий реплицированный кеш и т. Д. Все они работают с различными смесями компромиссов. Лично я имел большой успех с memcached. Memcached чрезвычайно быстрый и стабильный.

Как правило, я выбираю простоту и использую N серверов memcache, где N> 1, скажем 2. Когда пользователи входят в систему, серверы приложений переворачивают монету, чтобы решить, какой сервер хранит состояние пользователя. Куки-файлы, отправленные в браузер, включают информацию о том, какой сервер memcache будет маршрутизироваться с этого момента. Последующие запросы из состояния выбора браузера из соответствующего сервера memcache по каждому запросу. Если сервер memcache терпит неудачу, пользователю придется снова войти в систему, поскольку серверы приложений повторно выбирают новый сервер, но это крайне редко.

Answer 4

Устойчивые сеансы в базе данных ограничивают вашу масштабируемость. Если масштабируемость не так важна для вас, это (db + memcached) является допустимым подходом.

Одна вещь, о которой вам нужно помнить при использовании нестатистических сеансов, - это одновременные запросы: когда у вас есть, например, ajax-запросы (выполняются параллельно/одновременно), они будут обслуживаться разными кошками (из-за нелипкости) и, следовательно, одновременно обращаться к сеансу. Пока у вас есть параллельные запросы, которые могут изменить сеанс, вам нужно реализовать какую-то синхронизацию/сеансовую блокировку.

Возможно, вам это интересно: я создал memcached-session-manager с целью обеспечения оптимальной производительности и неограниченной масштабируемостью. Он может работать с любым совместимым с memcached бэкэнд (например, memcachedb, membase и т. Д. Или просто memcached). Хотя он был создан для подхода с липкими сессиями, уже существует branch for nonsticky-sessions и sample app, показывающий, как он работает. Прямо сейчас есть thread on the mailing list on further improvements for nonsticky-sessions (обработка одновременных запросов и предотвращение одноточечной ошибки).