Load balance web application

Po pierwsze, będziesz chciał skonfigurować load balancer dla sesji affinity/sticky sessions, tak aby kontynuował przekazywanie wszystkich żądań do tego samego Tomcat (tak długo, jak działa) w oparciu o JSESSIONID.

Tomcat clustering doc określa dwa ważne wymagania dla aplikacji, aby pomyślnie zreplikować jej sesje:

• wszystkie atrybuty sesji muszą zaimplementować java.io.Serializable
• upewnij się, że Twoja sieć.xml ma element <distributable/> lub ustawiony na Twoje <Context distributable="true" />

Jeśli zaczniesz umieszczać w sesji obiekty, które nie implementują Serializable (lub które mają właściwości / pola, które nie implementują Serializable), będziesz miał problemy.

(właściwie wszystkie te punkty mają zastosowanie niezależnie od tego, którego kontenera servlet używasz, jak sądzę.)

Update: aby odpowiedzieć na niektóre pytania w komentarzach o tym, dlaczego używasz sticky sessions, gdy równoważysz obciążenie między wieloma serwerami, myślę, że to najłatwiej wyjaśnić to na przykładzie.

Po pierwsze, to naprawdę ma znaczenie tylko wtedy, gdy aplikacja przechowuje jakieś dane w sesji, które mogą nie być każdą pojedynczą aplikacją (chociaż prawdopodobnie jest to większość). Jeśli nie przechowujesz danych w sesji, prawdopodobnie nie będziesz się o to martwić i możesz po prostu przestać czytać TUTAJ.

Posiadanie środowiska, w którym przechowujesz dane w sesji, ale nie masz , a nie sticky session otworzyłoby świat bólów głowy.

Załóżmy, że first.jsp aktualizuje pewną wartość w określonym atrybucie sesji i second.jsp zdarza się odczytać ten sam atrybut sesji. Program Tomcat można skonfigurować tak, aby replikował dane sesji na wszystkich serwerach w klastrze, ale replikacja ta nie występuje natychmiast. Co zrobić, jeśli początkowe żądanie dla {[5] } jest obsługiwane przez server1 i jedna nanosekunda po jego zakończeniu, ten sam użytkownik wysyła żądanie do second.jsp, które w Twoim nieklejącym środowisku jest obsługiwane przez server2. Ponieważ replikacja nie jest czy masz jakiś sposób, aby dowiedzieć się, czy czytasz najbardziej aktualne dane sesji? Czy musisz dodać jakiś rodzaj logiki, aby zsynchronizować odczyty w całym klastrze? To stałoby się wielkim bólem.

Konfiguracja sesji affinity / sticky sessions usuwa ten ból głowy; mając wszystkie żądania z tego samego serwera klienta przez ten sam węzeł, nie musisz się martwić o "Czy ten węzeł jest aktualny do czasu obsługi żądania?"Gdy węzeł zawiedzie, klient może nadal przełączanie awaryjne do innego węzła w klastrze, który ma kopię danych sesji, ale w przypadku sticky sessions staje się to rzadkim przypadkiem, a nie normą.

Jest jeszcze jeden powód, dla którego warto używać sticky sessions: load between the nodes in the cluster. Jeśli żądanie w sesji może być obsługiwane przez dowolny węzeł, to oznaczałoby to, że masz replikację all-to-all ustawioną w klastrze (co oznacza, że dane sesji node1 są replikowane do node2, node3, ..., node N, dane sesji node2 są replikowane do node1, node3, ... brak N, itp.). Replikacja sesji All-to-all może stać się wymagająca przepustowości i zasobów, gdy klaster staje się większy, ponieważ każdy dodatek do klastra oznacza kolejny węzeł, który musi komunikować się z każdym innym pojedynczym węzłem w klastrze.

Alternatywą dla tego jest replikacja danych węzła do kilku "kumpli" w klastrze, tak że w przypadku awarii węzła dane są dostępne gdzie indziej, ale bez konieczności każdego pojedynczego węzła masz kopię. W tym scenariuszu, można skonfigurować klaster tak, że node1 ma swoje dane replikowane do węzłów 2 i 3, węzeł 2 ma swoje dane replikowane do węzłów 3 i 4, itp., tworząc łańcuch. W tym scenariuszu dodanie dodatkowych węzłów do klastra nie powoduje szybkiego wzrostu komunikacji między węzłami, tak jak to ma miejsce w schemacie all-to-all.