Jak osiąga się lepkość sesji na wielu serwerach WWW?

Ile serwerów WWW ma StackOverflow / ServerFault?

Jeśli odpowiedź brzmi „więcej niż jeden”, to czy osiąga lepkość sesji podczas odpytywania DNS?

Duże witryny mogą być „równoważone obciążeniem” na wielu komputerach. W wielu konfiguracjach z równoważeniem obciążenia użytkownik może uderzyć w dowolny komputer zaplecza podczas sesji. Z tego powodu istnieje wiele metod umożliwiających wielu komputerom współużytkowanie sesji użytkowników.

Wybrana metoda będzie zależeć od zastosowanego stylu równoważenia obciążenia, a także od dostępności / pojemności pamięci wewnętrznej:

Informacje o sesji przechowywane tylko w plikach cookie : Informacje o sesji (nie tylko identyfikator sesji) są przechowywane w pliku cookie użytkownika. Na przykład plik cookie użytkownika może zawierać zawartość koszyka. Aby zapobiec manipulowaniu danymi sesji przez użytkowników, plik cookie HMAC może zostać udostępniony. Ta metoda jest prawdopodobnie najmniej odpowiednia dla większości aplikacji:

• Nie jest wymagane przechowywanie wewnętrznej bazy danych
• Użytkownik nie musi za każdym razem uderzać w tę samą maszynę, więc można zastosować równoważenie obciążenia DNS
• Nie ma żadnych opóźnień związanych z pobieraniem informacji o sesji z maszyny bazy danych (ponieważ jest ona dostarczana z żądaniem HTTP). Przydatne, jeśli Twoja witryna jest równoważona przez maszyny na różnych kontynentach.
• Ilość danych, które mogą być przechowywane w sesji jest ograniczona (przez limit wielkości plików cookie 4K)
• Szyfrowanie musi zostać zastosowane, jeśli użytkownik nie powinien widzieć zawartości swojej sesji
• Należy zastosować HMAC (lub podobny), aby zapobiec manipulowaniu danymi sesji przez użytkownika
• Ponieważ dane sesji nie są przechowywane po stronie serwera, programistom trudniej jest debugować

Moduł równoważenia obciążenia zawsze kieruje użytkownika do tego samego komputera : wiele modułów równoważenia obciążenia może ustawić własny plik cookie sesji, wskazując, z której maszyny zaplecza użytkownik wysyła żądania, i kieruje go do tej maszyny w przyszłości. Ponieważ użytkownik jest zawsze kierowany na ten sam komputer, udostępnianie sesji między wieloma komputerami nie jest wymagane. Może to być dobre w niektórych sytuacjach:

• Obsługa sesji istniejącej aplikacji może nie wymagać zmiany, aby stała się rozpoznawalna przez wiele komputerów
• Do przechowywania sesji nie jest wymagany wspólny system bazy danych (lub podobny), co może zwiększyć niezawodność, ale kosztem złożoności
• Spadająca maszyna zaplecza usunie wszystkie rozpoczęte na niej sesje użytkownika.
• Wyłączenie maszyn z eksploatacji jest trudniejsze. Użytkownicy z sesjami na komputerze, które mają zostać zdjęte w celu konserwacji, powinni mieć możliwość wykonania swoich zadań przed wyłączeniem urządzenia. Aby to obsługiwać, moduły równoważenia obciążenia sieciowego mogą mieć funkcję „odpompowywania” żądań do określonej maszyny zaplecza.

Współużytkowana baza danych zaplecza lub magazyn kluczy / wartości : informacje o sesji są przechowywane w bazie danych zaplecza, do której wszystkie serwery mają dostęp do zapytań i aktualizacji. Przeglądarka użytkownika przechowuje plik cookie zawierający identyfikator (taki jak identyfikator sesji), wskazujący informacje o sesji. Jest to prawdopodobnie najczystsza metoda z trzech:

• Użytkownik nigdy nie musi być narażony na przechowywane informacje o sesji.
• Użytkownik nie musi za każdym razem uderzać w tę samą maszynę, więc można zastosować równoważenie obciążenia DNS
• Wadą jest wąskie gardło, które można umieścić na dowolnym systemie przechowywania zaplecza.
• Informacje o sesji mogą wygasać i być regularnie archiwizowane.

Ogólnie rzecz biorąc, większość dynamicznych aplikacji internetowych wykonuje szereg zapytań do bazy danych lub żądań magazynu kluczy / wartości, więc baza danych lub magazyn kluczy / wartości jest logicznym miejscem przechowywania danych sesji.

Jeśli Twoim pytaniem jest, jak utrzymywać sesje na wielu frontonowych serwerach WWW, odpowiedzią jest zazwyczaj użycie scentralizowanej bazy danych. Zamiast polegać na instancjach serwera WWW w celu śledzenia plików sesji w lokalnych systemach plików, zapisujesz identyfikatory sesji i dane w centralnej bazie danych, a wszystkie serwery WWW pobierają dane z tego miejsca.

Korzystanie z nemcached wydaje się dobrym rozwiązaniem, o którym nie wspomniał @David Pashley

Oznacza to, że zdalna instancja pamięci podręcznej jest współużytkowana przez wszystkie serwery i korzysta z rozszerzenia PECL memcache, które zapewnia własny moduł obsługi sesji.

Wymaga tylko zmiany dwóch parametrów w konfiguracji php!

Oto dobry poradnik http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/

IIRC w DotNetRocks # 440 powiedzieli jeden okres serwera. Nie wiem, czy nadal tak jest.

Edycja: Właściwie to był Hanselminutes # 134 . Przepraszam.

Możesz ustawić ciasteczko.

Możesz obliczyć skrót zdalnego adresu IP (w najprostszym zdalnym hoście, nieparzyste hosty, przechodzą na serwer A, a nawet parzyste hosty - serwer B).

Wygląda na to, że możesz to zrobić za pomocą niektórych wartości, które pozostają w systemie źródłowym, jeśli używasz tunelu ssl.

Zazwyczaj każdy z powyższych mechanizmów wymaga serwera „odwrotnego proxy” lub pewnego rodzaju modułu równoważenia obciążenia. Ten moduł równoważenia obciążenia akceptuje ruch, a następnie kieruje go do dowolnego serwera, który początkowo miał sesję, na podstawie jednego z powyższych kryteriów.

Nie jestem jednak pewien, co rozumiesz przez „odpytywanie DNS”

a) Możesz przechowywać informacje o sesji w pliku cookie użytkownika. Zobacz bezstanowe zahartowane pliki cookie, które nie przechowują żadnych danych po stronie serwera, ale zachowują stan sesji http://www.cl.cam.ac.uk/~sjm217/papers/protocols08cookies.pdf . b) Możesz zmienić pamięć zaplecza sesji na bazę danych lub memcached. Aby wyeliminować pojedynczy punkt awarii, można ustawić replikację bazy danych lub wiele węzłów memcached. Pamiętaj, że memcached jest zalecany w takich konfiguracjach, w których utrata stanu użytkownika w sesji nie jest dużym błędem i nie czyni go bardzo niezadowolonym. W przypadkach, w których zachowanie stanu jest niezbędne, użyj baz danych. Zarówno PHP, Django, jak i Rails pozwalają programistom pisać niestandardowe zaplecze sesji.