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

Question

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

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

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

Answer 1

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

Когда вы используете балансировку нагрузки, это означает, что у вас есть несколько экземпляров 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 не влияет на навигацию пользователя.

Answer 2

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

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

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

Answer 3

Просто чтобы прояснить проблемы конфигурации на 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 в конфигурации «all», мы можем использовать конфигурацию «по умолчанию» или «стандартную».

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

<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">