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

Ответ 1

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

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

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

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

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

Ответ 2

Я ответил на некоторые подробности: fooobar.com/info/46643/...

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

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