Utrzymywanie stanu na serwerze aplikacji lub w bazie danych?

Question

REST zaleca aplikacje internetowe bez stanu klienta na serwerze. Słynny przykład koszyka zakupów jest tłumaczony na zasób, który zazwyczaj znajduje się w bazie danych.

Zastanawiam się, czy dobrą praktyką jest korzystanie z bazy danych dla tego rodzaju danych, ponieważ baza danych jest już wąskim gardłem w wielu aplikacjach. Czy nie byłoby lepiej używać stateful enterprise Java bean? Serwery aplikacji zostały zaprojektowane z myślą o uwzględnieniu.

Jakie są zalety i wady obu podejść?

Answer 1

Zapisywanie sesji na serwerze aplikacji będzie działać tylko wtedy, gdy:

• Klienci zawsze podłączać do tego samego serwera aplikacji (aka „sesja powinowactwa”)
• klastra aplikacji węzły używają wspólnego punktu montowania (nfs, itp.) do sesji buforowania

Przechowywanie sesji w centralnej bazie danych i/lub EJB będzie działało, jeśli klienci nie będą mieli zagwarantowanego połączenia z tym samym węzłem aplikacji w klastrze.

Innym podejściem do rozważenia jest skorzystanie z usługi, takiej jak memcached. To zadziała w obu przypadkach.

Answer 2

Ogólnie:

Database

• bardziej niezawodne i przetrwa ponownego uruchomienia aplikacji/serwera
• może być udostępniony na serwerach z równoważeniem obciążenia, bez konieczności zajmowania się „lepkie” sesji
• wolniej dostęp

In-Memory (niepodzielony stanowy bobek)

• szybki zapis i odczyt
• Mniej kod
• zostaną utracone, jeśli aplikacja/serwer restartuje

Twój wybór będzie całkowicie zależne od wymagań aplikacji i środowiska. Wszystkie rzeczy są jednakowe, faworyzuję rozwiązanie bazodanowe ze względu na korzyści z równoważenia obciążenia i niezawodności, ale w wielu sytuacjach może to łatwo doprowadzić do przesytu.

Answer 3

Co się stanie, gdy serwer aplikacji zginie. Czy stan sesji jest nadal ważny? Idź po bazę danych.

Czy masz więcej stanów sesji, a serwer może obsłużyć wszystkich współbieżnych użytkowników? Przeniesienie danych do bazy danych i wyciągnięcie tylko tego, czego naprawdę potrzebujesz w danej chwili, może być rozwiązaniem.

Czy Twoja aplikacja jest skupiona? Jeśli tak, centralna baza danych zapewnia, że ​​dane sesji są zawsze dostępne.

W przeciwnym razie: po prostu zapisz w sesji.

Czy masz ekstremalne wymagania skalowania (takie jak stackoverflow lub strony o jeszcze większym ruchu)? Znajdź sposób, aby nie korzystać z bazy danych.

To prawda, że ​​baza danych często jest wąskim gardłem. Ale poprawnie skonfigurowana baza danych powinna obsłużyć kilka bajtów danych sesji. Bardziej złożone dane i zapytania są tym, co kosztuje wydajność.

Answer 4

Wszystkie pozostałe elementy są dobrymi propozycjami. Jeszcze jedno: nie używaj stanu sesji, jeśli nie jest ci absolutnie potrzebny.

Przechowywanie sesji w bazie danych jest (zazwyczaj) to zły pomysł na kilka prostych powodów:

1. Typowe zastosowanie sesji jest na bieżąco z konieczności ładowania wspólnych danych z serwera bazy danych wiele razy. Jeśli sesja jest przechowywana na serwerze db, to znaczy, że naprawdę nie osiągnąłeś zbyt wiele.

2. Sesja musi być przekształcona do postaci szeregowej i przekształcona do postaci szeregowej dla każdego wykonania pojedynczej strony. Oznacza to, że dane sesji musiałyby zostać pobrane z serwera i zapisane z powrotem do serwera po każdej stronie, niezależnie od tego, czy go używasz, czy nie.

Z mojego doświadczenia wynika, że ​​lepiej jest po prostu wyciągnąć dane z serwera bazy danych, kiedy faktycznie go potrzebujesz. W większości przypadków ludzie umieszczają różnego rodzaju krótkotrwałe dane w sesji tylko dlatego, że uważają, że rozwiązują problem z wydajnością, podczas gdy w rzeczywistości go pogarszają.

Co więcej, jeśli ograniczysz ilość danych w dół (powiedzmy do identyfikatora użytkownika, nazwy lub czegoś podobnego), możesz zapisać to po stronie klienta zaszyfrowanego klienta i nie musisz się w ogóle o to martwić.

MemCache jest jedną z opcji; ale znowu poważnie spojrzę na wykorzystanie bazy danych i zobaczę, czy możesz najpierw dostroić zapytania i schematy.