Sesje lepkie i niekleiste

254

Chcę poznać różnicę między sesjami lepkimi i niekleistymi. Co zrozumiałem po przeczytaniu z Internetu:

Przyklejony : będzie tam tylko jeden obiekt sesji.

Niekleista sesja : obiekt sesji dla każdego węzła serwera

Sunny Gupta
źródło

Odpowiedzi:

612

Gdy witryna jest obsługiwana tylko przez jeden serwer WWW, dla każdej pary klient-serwer tworzony jest obiekt sesji i pozostaje on w pamięci serwera WWW. Wszystkie żądania od klienta trafiają do tego serwera WWW i aktualizują ten obiekt sesji. Jeśli pewne dane muszą być przechowywane w obiekcie sesji w okresie interakcji, są one przechowywane w tym obiekcie sesji i pozostają tam tak długo, jak sesja istnieje.

Jeśli jednak witryna jest obsługiwana przez wiele serwerów WWW, które znajdują się za modułem równoważenia obciążenia, moduł równoważenia obciążenia decyduje, do którego rzeczywistego (fizycznego) serwera WWW należy skierować każde żądanie. Na przykład, jeśli za modułem równoważenia obciążenia znajdują się 3 serwery WWW A, B i C, możliwe jest, że www.mywebsite.com/index.jsp jest obsługiwany z serwera A, www.mywebsite.com/login.jsp jest obsługiwany z serwer B i www.mywebsite.com/accoutdetails.php są obsługiwane z serwera C.

Teraz, jeśli żądania są obsługiwane z (fizycznie) 3 różnych serwerów, każdy serwer utworzył dla ciebie obiekt sesji, a ponieważ te obiekty sesji znajdują się na trzech niezależnych polach, nie ma bezpośredniego sposobu, aby wiedzieć, co jest w obiekcie sesji z drugiej. Aby zsynchronizować te sesje serwera, może być konieczne zapisanie / odczytanie danych sesji w warstwie wspólnej dla wszystkich - np. DB. Teraz zapisywanie i odczytywanie danych do / z bazy danych dla tego przypadku użycia może nie być dobrym pomysłem. Teraz pojawia się rola sesji lepkiej .

Jeśli moduł równoważenia obciążenia zostanie poinstruowany, aby używać sesji lepkich, wszystkie interakcje będą się odbywać na tym samym serwerze fizycznym, nawet jeśli obecne są inne serwery. Zatem obiekt sesji będzie taki sam przez całą interakcję z tą witryną.

Podsumowując, w przypadku sesji trwałych wszystkie twoje żądania będą kierowane do tego samego fizycznego serwera WWW, podczas gdy w przypadku niekleistego modułu równoważenia obciążenia może wybrać dowolny serwer internetowy, który będzie obsługiwał twoje żądania.

Jako przykład możesz przeczytać o Amazon Elastic Load Balancer i lepkich sesjach tutaj: http://aws.typepad.com/aws/2010/04/new-elastic-load-balancing-feature-sticky-sessions.html

TJ
źródło
4
@ TJ - co się stanie, jeśli jeden węzeł będzie niedostępny?
gstackoverflow
20
W większości przypadków sesja zostanie utracona. W przypadku AWS ESB Jeśli instancja ulegnie awarii lub stanie się niezdrowa, moduł równoważenia obciążenia zatrzymuje żądanie routingu do tej instancji, zamiast tego wybiera nową sprawną instancję na podstawie istniejącego algorytmu równoważenia obciążenia. Moduł równoważenia obciążenia traktuje sesję jako „zatrzymaną” na nowej, zdrowej instancji i kontynuuje wysyłanie żądań do tej instancji, nawet jeśli instancja, która uległa awarii, powróci.
TJ-
8
Według jakich informacji LoadBalancer sprawia, że ​​sesja HTTP jest lepka? Problem ten staje się szczególnie interesujący w przypadku połączeń HTTPS. Czy karmisz LB kluczem prywatnym serwerów WWW, aby mógł on zerwać połączenie SSL i pobrać sesję HTTP? Czy może LB po prostu korzysta z adresu IP klienta? W takim przypadku co z serwerem proxy, na którym wielu klientów używa tego samego adresu IP? A co gorsza, klienci mobilni, w których adres IP często się zmienia? A może jest nawet lepsza technika? Dzięki
g000ze
6
Tak, masz absolutną rację. Aby w tym kontekście skorzystać z nagłówka „x-forwarded-for” lub „cookie sticky-cookie”, należy użyć zakończenia SSL , a zatem żądanie musi zostać odszyfrowane w LB.
TJ-
4
@ g000ze W przypadku aplikacji, które nie są udostępniane bezpośrednio w Internecie, uważam, że włączanie TLS jest możliwe tylko na zewnętrznym serwerze proxy. (Moduł równoważenia obciążenia może być traktowany, być może w uproszczeniu, jako specjalny typ serwera proxy, który może przekazywać żądanie do dowolnego z wielu serwerów.) Ruch między modułem równoważenia obciążenia i innymi serwerami będzie się odbywał w lokalnej, zabezpieczonej sieci , a zatem często nie jest konieczne szyfrowanie go, lub jeśli trzeba go zaszyfrować, wystarczający może być samopodpisany certyfikat (ponieważ serwer proxy można skonfigurować tak, aby mu ufał).
jpmc26
106

Odpowiedziałem z kilkoma szczegółami tutaj: https://stackoverflow.com/a/11045462/592477

Lub możesz go przeczytać ==>

Kiedy używasz równoważenia obciążenia, oznacza to, że masz kilka instancji tomcat i musisz podzielić obciążenia.

  • Jeśli używasz replikacji sesji bez sesji trwałej: wyobraź sobie, że masz tylko jednego użytkownika korzystającego z aplikacji internetowej i masz 3 instancje tomcat. Ten użytkownik wysyła kilka żądań do Twojej aplikacji, a następnie moduł równoważenia obciążenia wyśle ​​niektóre z tych żądań do pierwszej instancji tomcat i wyśle ​​niektóre z tych innych żądań do drugiej instancji, a inne do trzeciej.
  • Jeśli używasz sesji trwałej bez replikacji:Wyobraź sobie, że masz tylko jednego użytkownika korzystającego z aplikacji internetowej i masz 3 instancje tomcat. Ten użytkownik wysyła kilka żądań do Twojej aplikacji, a następnie moduł równoważenia obciążenia wyśle ​​pierwsze żądanie użytkownika do jednej z trzech instancji tomcat, a wszystkie pozostałe żądania wysłane przez tego użytkownika podczas jego sesji zostaną wysłane do tej samej instancji tomcat. Podczas tych żądań, jeśli zamkniesz lub zrestartujesz tę instancję tomcat (używana instancja tomcat), moduł równoważenia obciążenia wysyła pozostałe żądania do jednej jeszcze działającej instancji tomcat, ALE ponieważ nie używasz replikacji sesji, tomcat instancji, który odbiera pozostałe żądania nie mają kopii sesji użytkownika, a następnie dla tego kocurka użytkownik rozpoczyna sesję: użytkownik traci sesję i jest odłączony od aplikacji internetowej, chociaż aplikacja internetowa jest nadal uruchomiona.
  • Jeśli używasz sesji trwałej z replikacją sesji:Wyobraź sobie, że masz tylko jednego użytkownika korzystającego z aplikacji internetowej i masz 3 instancje tomcat. Ten użytkownik wysyła kilka żądań do Twojej aplikacji, a następnie moduł równoważenia obciążenia wyśle ​​pierwsze żądanie użytkownika do jednej z trzech instancji tomcat, a wszystkie pozostałe żądania wysłane przez tego użytkownika podczas jego sesji zostaną wysłane do tej samej instancji tomcat. Podczas tych żądań, jeśli zamkniesz lub zrestartujesz tę instancję tomcat (używana instancja tomcat), moduł równoważenia obciążenia wysyła pozostałe żądania do jednej jeszcze działającej instancji tomcat, gdy używasz replikacji sesji, instancja tomcat, która odbiera pozostałe żądania, ma kopia sesji użytkownika, a następnie użytkownik kontynuuje sesję: użytkownik kontynuuje przeglądanie aplikacji internetowej bez rozłączenia, zamknięcie instancji tomcat nie ma wpływu na nawigację użytkownika.
Nico
źródło
8
Hmm .. czytam to Zastanawiam się: czy nie ma sensu mieć czwartej opcji: Niekleiste Z replikacją sesji? Lub inaczej: jaka jest zaleta posiadania lepkiej sesji, jeśli zreplikuje się sesję w różnych instancjach? Mam na myśli, że jeśli replikujesz sesje między instancjami, możesz po prostu przesłać żądanie również do dowolnego serwera, prawda? czego mi brakuje?
dingalapadum
@dingalapadum masz rację, teoretycznie możesz mieć replikację sesji bez sesji lepkiej. Ale w przypadku dużego klastra ma to negatywny wpływ na wydajność sieci. Następnie istnieją pewne strategie korzystania z replikacji sesji z sesją lepką, takie jak ta w tomcat ( tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html ) polega na umieszczeniu sesji trwałej i tylko jednej repliki (tutaj jeden węzeł nazywany menedżerem kopii zapasowych, który utrzymuje całą replikację sesji węzła).
Nico
Następnie sesja lepka pozwala mieć tylko jedną replikę sesji, co najlepiej sprawdza się w dużym klastrze.
Nico
2
Ach, rozumiem - jeśli dobrze rozumiem, masz na myśli to, że replikacja wszystkich sesji w całym klastrze zalałaby klaster wewnętrznie - widzę problem. Aha, a teraz, kiedy przyjrzałem się bliżej twojej odpowiedzi, właśnie zobaczyłem, że to właściwie pierwszy opisany przez ciebie przypadek ... „duh me” ..
dingalapadum
@dingalapadum twoje pytanie jest mile widziane, pozwala poprawić odpowiedź
Nico