Важные сессии и репликация сеанса

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

Просто для уточнения проблем конфигурации на JBoss 5.X в конфигурации "все" с mod_jk. Установка липких сеансов в файле employees.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">

Ответ 4

Как реализовать репликацию сеанса без закрепления сеанса в моем приложении, которое распределено по трем серверам IIS.