Подтвердить что ты не робот

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

У меня будут 3 сервера Tomcat и Load Balancer, которые отправляют запросы без использования липких сессий.
< ш > Я хочу поделиться данными сеансов между серверами, и я думаю о сохранении их в БД. Я хотел бы использовать memcached в качестве слоя перед моей БД, чтобы быстрее обслуживать запросы и не ставьте мой db под большую нагрузку.

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

Является ли это хорошим решением или вы видите лучший подход?

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Возможно, это вас интересует: я создал memcached-session-manager с целью как оптимальной производительности, так и неограниченной масштабируемости. Он может работать с любым совместимым с memcached бэкэнд (например, memcachedb, membase и т.д. Или просто memcached). Хотя он был создан для подхода с липкой сессией, уже существует ветка для нестатистических сессий и пример приложения показывает, как это работает. Прямо сейчас есть поток в списке рассылки для дальнейших улучшений для нестатических сеансов (обработка одновременных запросов и предотвращение одноточечной ошибки).

Ответ 2

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

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

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

Ответ 3

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

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