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


255

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

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

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

Ответы:


612

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

Однако, если ваш веб-сайт обслуживается несколькими веб-серверами, которые находятся за балансировщиком нагрузки, балансировщик нагрузки решает, к какому фактическому (физическому) веб-серверу должен обращаться каждый запрос. Например, если за балансировщиком нагрузки находятся 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


4
@ TJ- что будет, если один узел будет недоступен?
gstackoverflow

20
В большинстве случаев сеанс будет потерян. В случае AWS ESB Если экземпляр выходит из строя или выходит из строя, балансировщик нагрузки останавливает запрос маршрутизации к этому экземпляру, а вместо этого выбирает новый исправный экземпляр на основе существующего алгоритма балансировки нагрузки. Балансировщик нагрузки обрабатывает сеанс как «застрявший» в новом работоспособном экземпляре и продолжает направлять запросы этому экземпляру, даже если сбойный экземпляр возвращается.
TJ-

8
Согласно какой информации LoadBalancer делает HTTP-сеанс липким? Особенно на HTTPS-соединениях эта проблема становится интересной. Предоставляете ли вы LB с закрытым ключом веб-серверов, чтобы он мог разорвать соединение SSL и получить сеанс HTTP? Или LB просто использует IP-адрес клиента? В таком случае, как быть с прокси-сервером, где несколько клиентов используют один и тот же IP-адрес? Или еще хуже, мобильные клиенты, где IP-адрес часто меняется? Или для этого есть даже лучшая техника? Спасибо
g000ze

6
Да, вы абсолютно правы. Чтобы использовать заголовок «x-forwarded-for» или sticky-cookie в этом контексте, необходимо использовать SSL Termination, и, следовательно, запрос должен быть дешифрован на LB.
TJ-

4
@ g000ze При работе с приложениями, которые не обслуживаются напрямую через Интернет, я считаю, что обычно TLS разрешается только на самом внешнем прокси-сервере. (Балансировщик нагрузки можно рассматривать, возможно, более упрощенно, как прокси-сервер особого типа, который может передавать запрос на любой из нескольких серверов.) Трафик между балансировщиком нагрузки и другими серверами будет происходить в локальной защищенной сети. и, следовательно, часто нет необходимости шифровать его, или, если он должен быть зашифрован, может быть достаточно самозаверяющего сертификата (поскольку прокси-сервер может быть настроен на доверие к нему).
jpmc26

106

Я сделал ответ с более подробной информацией здесь: 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 не влияет на навигацию пользователя.

8
Хм ... читая это, мне интересно: разве не имеет смысла иметь четвертый вариант: Non-Sticky WITH репликация сессий? Или по-другому: в чем преимущество наличия липкого сеанса, если в любом случае реплицируется сеанс на разные экземпляры? Я имею в виду, если вы реплицируете сеансы между экземплярами, вы можете просто переслать запрос на любой сервер, верно? Чего мне не хватает?
dingalapadum

@dingalapadum вы правы, теоретически вы можете иметь репликацию сессии без липкой сессии. Но в случае большого кластера это плохо влияет на производительность сети. Кроме того, есть несколько стратегий использования репликации сеанса с липким сеансом, например, в tomcat ( tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html ) - поставить липкий сеанс и только одну реплику (здесь один узел). называется диспетчером резервного копирования, который хранит все репликации сеанса узла).
Нико

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

2
Ах, я понимаю - если я правильно понимаю, вы имеете в виду, что репликация всех сеансов по всему кластеру затопит кластер внутри - я вижу проблему. О, и теперь, внимательно присмотревшись к вашему ответу, я только что увидел, что это фактически первый случай, который вы описываете ... «Дух мне» ..
dingalapadum

@dingalapadum ваш вопрос можно только приветствовать, это позволяет улучшить ответ
Нико
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.