Udostępnianie sesji między instancjami tomcat (bez używania sesji lepkiej)

Question

Mam 3 serwery Tomcat i moduł równoważenia obciążenia, który rozsyła żądania bez "sticky sessions".
Chcę udostępniać dane sesji między serwerami i myślę o ich utrzymaniu w DB. Chciałbym użyć memcached jako warstwy przed moim DB, aby obsłużyć żądania szybciej i do don't put my db under heavy load.
Zastanawiam się nad dostarczeniem spersonalizowanego menedżera tomcat, który używa memcached przed pobraniem/utrwaleniem danych sesji do DB, ponieważ w tej chwili nie widzę przezroczystego sposobu działania (to znaczy, że będę musiał to zarządzać ponownie w przypadku, gdy przełączam się na inny serwer aplikacji).
Czy to dobre rozwiązanie, czy też widzisz lepsze podejście?

Answer 1

Podobnie postępujemy w naszej aplikacji (Weblogic, ale to nie ma znaczenia), gdzie mamy unikalny klucz sesji przechowywany jako cookie w przeglądarce. Klucz ten zostanie następnie użyty przy każdym żądaniu, aby przywrócić odpowiednie dane sesji z bazy danych.

Stosując tę ​​zasadę, zawsze możemy przełączyć się na inny serwer za pomocą modułu równoważenia obciążenia bez powiadomienia użytkownika. Poza tym nie przechowujemy niczego istotnego w sesji użytkownika i pracujemy z wieloma ukrytymi polami w przeglądarce (moduł równoważenia obciążenia obsługuje szyfrowanie adresów URL i ochronę formularzy, więc jesteśmy bezpieczni ...) .

Answer 2

Myślę, że Terracotta Web Sessions jest tym, czego potrzebujesz.

Answer 3

Przechowywanie stanu sesji poza serwerami aplikacji (Tomcat w Twoim przypadku), jest bardzo powszechną i zalecaną konfiguracją dla dużych stron internetowych. Zwykle odbywa się to w ramach stylu architektury o nazwie Shared Nothing.

Możesz przechowywać swój stan w kilku różnych miejscach: db, memcached, komercyjne replikowane pamięci podręczne itp. Wszystkie działają z różnymi mieszankami kompromisów. Osobiście odniosłem wielki sukces dzięki memcached. Memcached jest niezwykle szybki i stabilny.

Generalnie, wybieram prostotę i używam N serwerów memcache, gdzie N> 1, powiedzmy 2. Gdy użytkownicy się logują, serwery aplikacji rzucają monetą, aby zdecydować, który serwer przechowuje stan użytkowników. Plik cookie wysłany do przeglądarki zawiera informacje o tym, do którego serwera memcache należy się przekierować. Kolejne żądania od przeglądarki pobierają stan z odpowiedniego serwera memcache przy każdym żądaniu. W przypadku awarii serwera memcache, użytkownik będzie musiał ponownie się zalogować, ponieważ serwery aplikacji ponownie wybierają nowy serwer, ale jest to niezwykle rzadkie.

Answer 4

Trwałe sesje w bazie danych ograniczają skalowalność. Jeśli skalowalność nie jest dla ciebie tak ważna (db + memcached) to prawidłowe podejście.

Jedną z rzeczy, o których należy pamiętać podczas korzystania z nietradycyjnych sesji, są równoległe żądania: gdy masz np. ajax-requests (wykonywane równolegle/współbieżnie) będą obsługiwane przez różne kocury (ze względu na brak klejenia), a zatem dostęp do sesji jednocześnie. Tak długo, jak masz współbieżne żądania, które mogą modyfikować sesję, musisz zaimplementować pewien rodzaj synchronizacji/blokady sesji.

Być może jest to dla Ciebie interesujące: Stworzyłem memcached-session-manager w celu zapewnienia optymalnej wydajności i nieograniczonej skalowalności. Może pracować z dowolnym backendem kompatybilnym z memcached (np. Memcachedb, membase itp. Lub memcached). Mimo że został stworzony z myślą o podejściu typu sticky-sessions, istnieje już branch for nonsticky-sessions istniejący i sample app pokazujący jak/on działa. Teraz jest thread on the mailing list on further improvements for nonsticky-sessions (obsługa równoczesnych żądań i zapobieganie pojedynczemu punktowi awarii).