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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

Я думаю Терракотовые веб-сессии - это то, что вы хотите.

Answer 4

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

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