Клейкі та НЕ липкі сесії

255

Я хочу знати різницю між сеансами, що не впадають в липку та не липнуть. Що я зрозумів, прочитавши з Інтернету:

Липкий : там буде лише один об’єкт сеансу.

Не липкий сеанс : об’єкт сеансу для кожного вузла сервера

session

Відповіді:

612

Коли ваш веб-сайт обслуговується лише одним веб-сервером, для кожної пари клієнт-сервер створюється об’єкт сеансу і залишається в пам'яті веб-сервера. Усі запити від клієнта переходять на цей веб-сервер та оновлюють цей об’єкт сеансу. Якщо деякі дані потрібно зберігати в об’єкт сеансу протягом періоду взаємодії, він зберігається в цьому об’єкті сеансу і залишається там, поки існує сесія.

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

Тепер, якщо запити обслуговуються з (фізично) трьох різних серверів, кожен сервер створив для вас об’єкт сеансу, і оскільки ці об’єкти сеансу сидять на трьох незалежних полях, немає прямого способу дізнатися, що там у об’єкт сеансу з іншого. Для синхронізації між цими сеансами на сервері, можливо, доведеться записати / прочитати дані сеансу в загальний для всіх рівень - наприклад, БД. Тепер записування та читання даних в / з db для цього випадку використання може бути не дуже хорошою ідеєю. Тепер ось тут іде роль липкого сеансу .

Якщо балансиру навантажень доручено використовувати клейкі сеанси, всі ваші взаємодії відбуватимуться з тим же фізичним сервером, навіть якщо присутні інші сервери. Таким чином, об’єкт сеансу буде однаковим протягом усієї вашої взаємодії з цим веб-сайтом.

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

Як приклад, ви можете прочитати про Еластичний балансир завантаження Amazon та про липкі сеанси тут: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sesions.html

— TJ-
джерело

@ TJ - що буде, якщо один вузол буде недоступний?

— gstackoverflow

У більшості випадків сеанс буде втрачено. У випадку AWS ESB Якщо екземпляр виходить з ладу або стає нездоровим, балансир навантаження припиняє запит маршрутизації до цього екземпляра, замість цього вибирає новий здоровий екземпляр на основі існуючого алгоритму балансування навантаження. Балансир навантаження розглядає сеанс як зараз "застряг" у новому здоровому екземплярі та продовжує маршрутизацію запитів до цього екземпляра, навіть якщо невдалий екземпляр повернеться.

— TJ-

Згідно з якою інформацією LoadBalancer робить сеанс HTTP липким? Особливо щодо HTTPS-підключень це питання стає цікавим. Чи годуєте ви LB приватним ключем веб-серверів, щоб він міг розірвати з'єднання SSL та отримувати сеанс HTTP? Або LB просто використовує IP-адресу клієнта? У цьому випадку, що про проксі-сервер, де кілька клієнтів використовують одну і ту ж IP-адресу? Або ще гірше, мобільні клієнти, де IP-адреса часто змінюється? Або є для цього навіть краща техніка? Дякую

— g000ze

Так, ви абсолютно праві. Щоб використовувати заголовок "x-forwarded-for" або "cookie-cookie" в цьому контексті, потрібно використовувати SSL-завершення, і, отже, запит потрібно розшифрувати в LB.

— TJ–

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

— jpmc26

106

Я зробив відповідь із ще деякими деталями тут: https://stackoverflow.com/a/11045462/592477

Або ви можете прочитати його там ==>

Якщо ви використовуєте балансування навантаження, це означає, що у вас є кілька примірників tomcat, і вам потрібно розділити навантаження.

Якщо ви використовуєте реплікацію сеансу без липкого сеансу: уявіть, що у вас за допомогою веб-програми використовується лише один користувач, і у вас є 3 екземпляри tomcat. Цей користувач надсилає декілька запитів до вашої програми, потім навантажувач відправить деякі з цих запитів до першого екземпляра tomcat, а деякі інші запити - до другої інстанції, а інші до третьої.
Якщо ви використовуєте липкий сеанс без тиражування:Уявіть, що у вас є лише один користувач, який використовує ваш веб-додаток, і у вас є 3 екземпляри tomcat. Цей користувач надсилає вашій програмі кілька запитів, тоді навантажувач надішле перший запит користувача одному з трьох екземплярів tomcat, а всі інші запити, надіслані цим користувачем під час його сеансу, будуть надіслані в той самий екземпляр tomcat. Під час цих запитів, якщо ви вимикаєте або перезапускаєте цей екземпляр tomcat (використовуваний екземпляр tomcat), балансир завантажує залишки запитів в інший екземпляр tomcat, який все ще працює, АЛЕ, оскільки ви не використовуєте реплікацію сеансу, екземпляр tomcat, який отримує в інших запитах немає копії сеансу користувача, тоді для цього tomcat користувач починає сеанс: користувач втрачає сеанс і відключається від веб-програми, хоча веб-додаток все ще працює.
Якщо ви використовуєте липкий сеанс З реплікацією сеансу:Уявіть, що у вас є лише один користувач, який використовує ваш веб-додаток, і у вас є 3 екземпляри tomcat. Цей користувач надсилає вашій програмі кілька запитів, тоді навантажувач надішле перший запит користувача одному з трьох екземплярів tomcat, а всі інші запити, надіслані цим користувачем під час його сеансу, будуть надіслані в той же екземпляр tomcat. Під час цих запитів, якщо ви вимикаєте або перезапускаєте цей екземпляр tomcat (використовуваний екземпляр tomcat), балансоутримувач відправляє залишки запитів до іншого екземпляра tomcat, який все ще працює, при використанні реплікації сеансу, екземпляр tomcat, який отримує інші запити, має копію сеансу користувача, потім користувач продовжує вести свій сеанс: користувач продовжує переглядати ваш веб-додаток без відключення, відключення екземпляра tomcat не впливає на навігацію користувача.

— Ніко
джерело

Хм .. читаючи це, мені цікаво: чи не було б сенсу мати четвертий варіант: Неприличний З реплікацією сеансу? Або по-іншому: яка перевага мати липкий сеанс, якщо ви все-таки повторюєте сеанс у різні екземпляри? Я маю на увазі, якщо ти реплікуєш сеанси по всіх екземплярах, ти можеш просто переслати цей запит на будь-який сервер, правда? Що я пропускаю?

— dingalapadum

@dingalapadum Ви маєте рацію, теоретично ви можете мати реплікацію сеансу без липкого сеансу. Але у випадку великого кластера це погано для роботи мережі. Тоді є деякі стратегії використання реплікації сеансу з таким липким сеансом, як цей у tomcat ( tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html ) - це встановити липкий сеанс і лише одну репліку (один вузол тут називається менеджером резервного копіювання, який зберігає всі реплікації сеансу вузла).

— Ніко

Тоді липкий сеанс дозволяє мати лише одну репліку сеансу, що найкраще у великому кластері.

— Ніко

Ах, я бачу - якщо я правильно розумію, ви маєте на увазі, що повторне повторення всіх сеансів у всьому кластері перекриє кластер внутрішньо - я бачу проблему. О, і тепер, придивившись більш детально до вашої відповіді, я щойно побачив, що це насправді перший ви описуєте ви справу ... 'duh me' ..

— dingalapadum

@dingalapadum ваше питання вітається, це дозволяє покращити відповідь

— Ніко