Вопрос по session – Липкие и не липкие сессии

199

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

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

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

Ваш Ответ

2   ответа
81

https://stackoverflow.com/a/11045462/592477

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

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

If you're using session replication without sticky session : Imagine you have only one user using your web app, and you have 3 tomcat instances. This user sends several requests to your app, then the loadbalancer will send some of these requests to the first tomcat instance, and send some other of these requests to the secondth instance, and other to the third. If you're using sticky session without replication : Imagine you have only one user using your web app, and you have 3 tomcat instances. This user sends several requests to your app, then the loadbalancer will send the first user request to one of the three tomcat instances, and all the other requests that are sent by this user during his session will be sent to the same tomcat instance. During these requests, if you shutdown or restart this tomcat instance (tomcat instance which is used) the loadbalancer sends the remaining requests to one other tomcat instance that is still running, BUT as you don't use session replication, the instance tomcat which receives the remaining requests doesn't have a copy of the user session then for this tomcat the user begin a session : the user loose his session and is disconnected from the web app although the web app is still running. If you're using sticky session WITH session replication : Imagine you have only one user using your web app, and you have 3 tomcat instances. This user sends several requests to your app, then the loadbalancer will send the first user request to one of the three tomcat instances, and all the other requests that are sent by this user during his session will be sent to the same tomcat instance. During these requests, if you shutdown or restart this tomcat instance (tomcat instance which is used) the loadbalancer sends the remaining requests to one other tomcat instance that is still running, as you use session replication, the instance tomcat which receives the remaining requests has a copy of the user session then the user keeps on his session : the user continue to browse your web app without being disconnected, the shutdown of the tomcat instance doesn't impact the user navigation.
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceededtomcat.apache.org/tomcat-9.0-doc/cluster-howto.htmlError: User Rate Limit Exceeded
528

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

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

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

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

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

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

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit ExceededAWS ESB If an instance fails or becomes unhealthy, the load balancer stops routing request to that instance, instead chooses a new healthy instance based on the existing load balancing algorithm. The load balancer treats the session as now "stuck" to the new healthy instance, and continues routing requests to that instance even if the failed instance comes back.
Error: User Rate Limit Exceeded
Error: User Rate Limit ExceededSSL TerminationError: User Rate Limit Exceeded

Похожие вопросы