Липкие и не липкие сессии

Я хочу знать разницу между липкими и нелипкими сессиями. Что я понял после прочтения из интернета:

Важно : только один объект сеанса будет там.

Non-sticky session : объект сеанса для каждого узла сервера

Когда ваш веб-сайт обслуживается только одним веб-сервером, для каждой пары клиент-сервер создается объект сеанса, который остается в памяти веб-сервера. Все запросы от клиента отправляются на этот веб-сервер и обновляют этот объект сеанса. Если некоторые данные необходимо хранить в объекте сеанса в течение периода взаимодействия, они сохраняются в этом объекте сеанса и остаются там до тех пор, пока существует сеанс.

Однако, если ваш веб-сайт обслуживается несколькими веб-серверами, которые находятся за балансировщиком нагрузки, балансировщик нагрузки решает, к какому фактическому (физическому) веб-серверу должен обращаться каждый запрос. Например, если за балансировщиком нагрузки находятся 3 веб-сервера A, B и C, возможно, что www.mywebsite.com/index.jsp будет обслуживаться с сервера A, а www.mywebsite.com/login.jsp - с сервер B и www.mywebsite.com/accoutdetails.php обслуживаются с сервера C.

Теперь, если запросы обслуживаются (физически) с 3 разных серверов, каждый сервер создал для вас объект сеанса и поскольку эти объекты сеанса располагаются в трех независимых ящиках, нет прямого способа узнать, что находится в объекте сеанса другого. Для синхронизации между этими сеансами сервера вам может потребоваться записать / прочитать данные сеанса в общий для всех уровень, например, в БД. Теперь запись и чтение данных в / из БД для этого варианта использования может быть плохой идеей. Теперь здесь идет роль Sticky-сессии .

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

Подводя итог, можно сказать, что в случае Sticky Sessions все ваши запросы будут направлены на один и тот же физический веб-сервер, а в случае несвязанного loadbalancer может выбрать любой веб-сервер для обслуживания ваших запросов.

В качестве примера вы можете прочитать об Amazon Elastic Load Balancer и липких сессиях здесь: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html

Я сделал ответ с более подробной информацией здесь: https://stackoverflow.com/a/11045462/592477

Или вы можете прочитать это там ==>

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