Каковы недостатки репликации сеансов на Tomcat? - PullRequest
10 голосов
/ 14 июня 2010

Я пытался решить, что лучше в режиме обратного прокси-сервера Tomcat + Apache для репликации сеанса.Что чаще встречается при развертывании?репликация сеанса или сеанс флешки?Есть ли недостатки для репликации сеанса?

Спасибо

Ответы [ 2 ]

14 голосов
/ 16 июня 2010

Я могу указать на следующие соображения, если вы идете для репликации сеанса.

Производительность

Основной недостаток будет в производительности.Реплицированные сеансы включают копирование данных сеанса на все серверы в кластере.Чем больше серверов в кластере, тем больше дополнительных издержек.

Tomcat помогает с этими издержками, определяя два режима репликации сеансов.

DeltaManager (по умолчанию) и BackupManager

С этого URL http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html

Использование описанной выше конфигурации позволит выполнить репликацию сеанса «все ко всем» с использованием DeltaManager для репликации дельт сеанса.Под всеми мы подразумеваем, что сеанс реплицируется на все другие узлы в кластере.Это прекрасно работает для небольших кластеров, но мы не рекомендуем его для больших кластеров (много узлов tomcat).Также при использовании дельта-менеджера он будет реплицироваться на все узлы, даже на узлы, на которых приложение не развернуто.

Чтобы обойти эту проблему, вам нужно использовать BackupManager.Этот менеджер реплицирует данные сеанса только на один резервный узел и только на узлы, на которых развернуто приложение.Недостаток BackupManager: не такой боевой тест, как у дельта-менеджера

Считайте этот URL , чтобы получить полезные советы по проектированию кластера при включении репликации сеанса.

Память

Сколько одновременно работающих пользователей будет поражать приложение?чем больше пользователей, тем больше данных сохраняется в сеансах, и, следовательно, возникает перегрузка для репликации сеансов.

Соображения по коду

Кроме того, необходимо обеспечить ввод данных всеанс приложения сериализуем.Сериализация данных сеанса имеет некоторые издержки для репликации состояния сеанса.Рекомендуется сохранять размер сеанса достаточно небольшим, поэтому разработчикам необходимо проверить объем данных, помещаемых в сеанс.

Sticky Sessions

Учитывая этисоображения, это на самом деле зависит от критичности вариантов использования.Если вы проводите только липкие сеансы, то существует вероятность потери пользовательских данных во время критической поездки.

Есть ли у вас средства для восстановления после этого, например, путем сохранения важных данных в базе данных на каждом этапезаказ или оплата проезда?Если нет, пользователь должен войти и начать заново.Это хорошо для веб-сайтов, которые не являются транзакционными, но просматривают данные типа брошюр или заполняют формы для сбора данных, которые не являются платежами и т. Д.

0 голосов
/ 13 января 2015

Я предпочитаю Sticky сессию с memcache.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...