Липкие Сессии и Репликация Сессии

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

Но кажется, что репликация сеанса обычно используется с липкими сеансами, в противном случае идентификатор сеанса необходимо менять всякий раз, когда запрос переходит к другому узлу. ссылка: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html

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

Источник

3 ответа

Решение

Я думаю, что единственное реальное преимущество - это возможность закрывать экземпляры Tomcat без особых раздумий. Особенно это применимо сегодня в облачном мире (например, точечные экземпляры Amazon AWS), когда узлы могут очень часто включаться и выключаться. Альтернативой этому было бы купить приличный балансировщик нагрузки, который поддерживает слив узлов. Но приличные балансировщики нагрузки стоят дорого, а слив требует времени.

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

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

Источник

Как Миндас объяснил это раньше:

Когда вы используете балансировку нагрузки, это означает, что у вас есть несколько экземпляров tomcat, и вам нужно разделить нагрузки.

  • Если вы используете репликацию сеанса без липкого сеанса: представьте, что у вас есть только один пользователь, использующий ваше веб-приложение, и у вас есть 3 экземпляра tomcat. Этот пользователь отправляет несколько запросов вашему приложению, затем loadbalancer отправит некоторые из этих запросов первому экземпляру tomcat и отправит некоторые другие из этих запросов второму экземпляру, а другой - третьему.
  • Если вы используете липкий сеанс без репликации: представьте, что у вас есть только один пользователь, использующий ваше веб-приложение, и у вас есть 3 экземпляра tomcat. Этот пользователь отправляет несколько запросов вашему приложению, затем loadbalancer отправит первый пользовательский запрос одному из трех экземпляров tomcat, а все остальные запросы, отправленные этим пользователем во время его сеанса, будут отправлены тому же экземпляру tomcat. Во время этих запросов, если вы выключаете или перезапускаете этот экземпляр tomcat (используется экземпляр tomcat), loadbalancer отправляет оставшиеся запросы одному другому экземпляру tomcat, который все еще работает, НО, поскольку вы не используете репликацию сеанса, экземпляр tomcat, который получает оставшиеся запросы не имеют копии пользовательского сеанса, поэтому для этого кота пользователь начинает сеанс: пользователь теряет свой сеанс и отключается от веб-приложения, хотя веб-приложение все еще работает.
  • Если вы используете липкий сеанс С репликацией сеанса: представьте, что у вас есть только один пользователь, использующий ваше веб-приложение, и у вас есть 3 экземпляра tomcat. Этот пользователь отправляет несколько запросов вашему приложению, затем loadbalancer отправит первый пользовательский запрос одному из трех экземпляров tomcat, а все остальные запросы, отправленные этим пользователем во время его сеанса, будут отправлены тому же экземпляру tomcat. Во время этих запросов, если вы выключаете или перезапускаете этот экземпляр tomcat (используется экземпляр tomcat), loadbalancer отправляет оставшиеся запросы одному другому экземпляру tomcat, который все еще работает, так как вы используете репликацию сеанса, экземпляр tomcat, который получает оставшиеся запросы, имеет копия сеанса пользователя, после чего пользователь продолжает сеанс: пользователь продолжает просматривать ваше веб-приложение, не отключаясь, отключение экземпляра tomcat не влияет на навигацию пользователя.
Источник

Просто чтобы прояснить проблемы конфигурации на JBoss 5.X во "базовой" базовой конфигурации с mod_jk. Установка липких сессий в файле worker.properties

 worker.list=loadbalancer

 ... nodes configuration omitted

 worker.loadbalancer.balance_workers=node1,node2
 worker.loadbalancer.sticky_session=True

не мешает репликации сессии. Чтобы отключить репликацию сеанса на JBoss, нам нужно установить в $JBOSS_HOME\server\YOUR_NODE_NAME\deploy\cluster\jboss-cache-manager.sar\META-INF\jboss-cache-manager-jboss-beans.xml cacheMode параметр для LOCAL,

Обычно в сценарии с фиксированным сеансом нам не нужна репликация сеанса, поскольку нам не нужны дополнительные издержки, связанные со значительным количеством операций ввода-вывода, необходимых для репликации сеансов.

На самом деле, если вы работаете с липкими сессиями, нам не нужно запускать JBoss в конфигурации "все", мы можем использовать конфигурацию "по умолчанию" или "стандартную".

Единственное, что нужно сделать, это изменить в $JBOSS_HOME/server/YOUR_NODE_NAME/deploy/jbossweb.sar/server.xml:

<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">
Источник
Другие вопросы по тегам