Sticky Sessions i replikacja sesji

Question

Sticky Sessions i replikacja sesji

Oceniam przypadek użycia sticky sessions z replikacją sesji w tomcat. Z mojej wstępnej oceny, pomyślałem, że jeśli włączymy replikację sesji, wtedy sesja rozpoczęta w jednym węźle tomcat zostanie skopiowana do wszystkich innych węzłów tomcat i dlatego nie potrzebujemy sticky session, aby kontynuować sesje i żądanie może być odebrane przez dowolny węzeł.

Ale wygląda na to, że replikacja sesji jest ogólnie używana z sesjami sticky, w przeciwnym razie id sesji musi zostać zmienione gdy żądanie trafia do innego węzła. ref: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind_session_after_crash_to_failover_node

Czy ktoś może wyjaśnić, na czym polega replikacja sesji, jeśli trzeba włączyć sticky session? Ponieważ wtedy niepotrzebnie kopiowałbyś sesję na każdym węźle, gdy żądanie o podanym identyfikatorze sesji zawsze trafia do tego samego węzła. Może to być korzystne w przypadku awarii węzła, ale to nie zdarza się to często i używanie replikacji sesji tylko w tym celu wydaje się przesadą.

20

session tomcat session-replication

Author: Ashish, 2011-06-16

Source

3 answers

Jak Mindas wyjaśnił to wcześniej:

Gdy używasz loadbalancing oznacza to, że masz kilka instancji tomcat i musisz podzielić obciążenia.

Jeśli używasz replikacji sesji bez sticky session: wyobraź sobie, że masz tylko jednego użytkownika używającego Twojej aplikacji internetowej i masz 3 Tomcat. Ten użytkownik wysyła kilka żądań do Twojej aplikacji, a następnie loadbalancer wyśle niektóre z tych próśb do pierwszego Tomcata instancji, i wysłać kilka innych z tych prośby do drugiego instancji, a inne do trzeciego.
Jeśli używasz sticky session bez replikacji: wyobraź sobie, że masz tylko jednego użytkownika korzystającego z aplikacji internetowej i masz 3 tomcat przypadki. Ten użytkownik wysyła kilka żądań do Twojej aplikacji, a następnie loadbalancer wyśle pierwsze żądanie użytkownika do jednego z trzech instancji tomcat, oraz wszystkie inne żądania, które są wysyłane przez to użytkownik podczas jego sesji zostanie wysłany do tej samej instancji tomcat. Podczas tych żądań, jeśli zamykasz lub restartujesz tego Tomcata instancja (używana instancja tomcat) loadbalancer wysyła Pozostałe żądania do innej instancji tomcat, która jest nadal uruchomiony, ale ponieważ nie używa się replikacji sesji, instancja tomcat, który odbiera Pozostałe żądania, nie ma kopii sesji użytkownika następnie dla tego tomcat użytkownik rozpoczyna sesję : the użytkownik traci swoją sesję i jest odłączony od aplikacji internetowej, chociaż aplikacja internetowa nadal działa.
Jeśli używasz sticky session WITH session replication: wyobraź sobie, że masz tylko jednego użytkownika używającego aplikacji internetowej i masz 3 tomcat przypadki. Ten użytkownik wysyła kilka żądań do Twojej aplikacji, a następnie loadbalancer wyśle pierwsze żądanie użytkownika do jednego z trzech instancji tomcat, oraz wszystkie inne żądania, które są wysyłane przez to użytkownik podczas jego sesji zostanie wysłany do tej samej instancji tomcat. Podczas tych żądań, jeśli wyłączysz lub zrestartujesz ten tomcat instancja (używana instancja tomcat) loadbalancer wysyła Pozostałe żądania do innej instancji tomcat, która jest nadal uruchamianie, podczas korzystania z replikacji sesji, instancji tomcat, która odbiera Pozostałe żądania ma kopię sesji użytkownika, a następnie Użytkownik utrzymuje swoją sesję : Użytkownik kontynuuje przeglądanie sieci aplikacja bez rozłączania, wyłączenie instancji tomcat nie wpływa na nawigację użytkownika.

58

Author: Nico,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-06-15 06:09:58

Aby wyjaśnić problemy z konfiguracją w JBoss 5.X w konfiguracji podstawowej " all " z mod_jk. Ustawianie lepkich sesji w robotnikach.Plik Właściwości

 worker.list=loadbalancer

 ... nodes configuration omitted

 worker.loadbalancer.balance_workers=node1,node2
 worker.loadbalancer.sticky_session=True

Nie zapobiega replikacji sesji. Aby wyłączyć replikację sesji w JBoss musimy ustawić $jboss_home \ server\YOUR_NODE_NAME\deploy\cluster\jboss-Cache-manager.sar \ META-INF\jboss-Cache-manager-jboss-beans.parametr xml cacheMode do LOCAL.

Zazwyczaj w scenariuszu sticky session nie chcemy sesji replikacji, ponieważ nie chcemy dodatkowych kosztów związanych ze znaczną ilością operacji We/Wy potrzebnych do replikacji sesji.

W rzeczywistości, jeśli go with sticky sessions, nie musimy uruchamiać Jbossa w konfiguracji "all", możemy użyć konfiguracji "default" lub "standard".

Jedyne co należy zrobić to zmienić w $jboss_home / server/YOUR_NODE_NAME/deploy / jbossweb.SAR / serwer.xml:

<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">

0

Author: Piotr Kochański,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-03-30 19:18:22

score 7 · Accepted Answer

Myślę, że jedyną realną korzyścią jest możliwość wyłączenia instancji Tomcat bez większego namysłu. Szczególnie dotyczy to dzisiaj w świecie chmury (pomyśl o instancjach Amazon AWS spot), gdy węzły mogą często włączać i wyłączać się. Alternatywą dla tego byłoby kupić przyzwoity load balancer, który obsługuje opróżnianie węzłów. Ale przyzwoite load balancers są drogie, a opróżnianie wymaga czasu.

Inny scenariusz, jaki przychodzi mi do głowy, to (słaba implementacja) koszyk na zakupy, w którym przedmioty trzymane są w HttpSession i wyłączenie wymagałoby od użytkownika ponownego zakupu (co prawdopodobnie doprowadziłoby do utraty sprzedaży).

Ale w większości przypadków masz rację-korzyści z posiadania zarówno lepkich sesji, jak i replikacji sesji są bardzo znikome.