Applicazione web per il bilanciamento del carico

Question

Ci sono server Web tomcat con carico bilanciato. Ogni richiesta può essere fornita da un diverso server tomcat.

Come potremmo occuparci di questo durante la scrittura del codice per l'applicazione Web basata su j2ee (struts)?

Answer 1

Prima di tutto, è necessario configurare il bilanciamento del carico per sessioni di affinità di sessione/appiccicose, in modo che continui a inoltrare tutte le richieste allo stesso Tomcat (a condizione che sia attivo) basato su JSESSIONID.

The Tomcat clustering doc afferma due requisiti importanti per l'applicazione per avere successo è sessioni replicato:

• Tutti i tuoi attributi della sessione devono implementare java.io.Serializable
• Assicurati che il tuo web.xml ha l'elemento <distributable/> o impostare a vostra <Context distributable="true" />

Se si inizia a mettere oggetti in sessione che non implementano Serializable (o che hanno proprietà/campi che non implementano Serializable), quindi avrai problemi.

(In realtà questi punti tutti si applicano indipendentemente dal servlet container che si sta utilizzando, credo.)

Aggiornamento: per affrontare alcune delle domande nei commenti sul motivo per utilizzare le sessioni appiccicoso quando si sta bilanciando il caricare tra più server, penso che sia più facile spiegare questo con un esempio.

Prima di tutto, questo è davvero importante se l'applicazione mantiene una sorta di dati in sessione, che potrebbe non essere ogni singola applicazione (anche se probabilmente è la maggior parte). Se non conservi i dati durante la sessione, probabilmente non ti interesserà nulla di tutto ciò e puoi semplicemente smettere di leggere qui.

Avere un ambiente in cui si tengono i dati in sessione, ma si fa non fare una sessione appiccicosa aprirebbe un mondo di mal di testa.

Diciamo che first.jsp aggiorna qualche valore in un particolare attributo di sessione e second.jsp si legge per leggere questo stesso attributo di sessione. È possibile configurare Tomcat per replicare i dati di sessione su tutti i server nel cluster, ma questa replica non si verifica all'istante. Cosa succede se la richiesta iniziale di first.jsp viene gestita da e un nanosecondo dopo il completamento, lo stesso visitatore effettua una richiesta a second.jsp, che nel proprio ambiente non appiccicoso viene gestita da server2. Dal momento che la replica non è istantanea, hai qualche modo di sapere se stai leggendo i dati di sessione più aggiornati? Devi aggiungere una sorta di logica per sincronizzare le tue letture attraverso il cluster? Questo diventerebbe un dolore gigantesco.

L'impostazione di sessioni di affinità/sessioni appiccicose rimuove questo mal di testa; avendo tutte le richieste dallo stesso server client dallo stesso nodo, non ti devi preoccupare di "questo nodo è aggiornato dal momento in cui gestisce la richiesta?" Quando il nodo fallisce, il client può ancora eseguire il failover su un altro nodo nel cluster, che ha una copia dei suoi dati di sessione, ma con sessioni appiccicose questo diventa il caso raro e non la norma.

C'è un altro motivo per volere sessioni appiccicose: caricare tra i nodi nel cluster.Se una richiesta in una sessione può essere gestita da qualsiasi nodo, ciò implicherebbe che si abbia la replica completa del cluster (ovvero i dati della sessione di node1 sono sostituiti a node2, node3, ..., node N, i dati di sessione di node2 vengono replicati su node1, node3, ... nessuno N, ecc.). La replica di tutte le sessioni può diventare larghezza di banda e risorse intensive quando il cluster diventa più grande, perché ogni aggiunta al cluster significa ancora un altro nodo che deve comunicare con ogni altro nodo singolo nel cluster.

Un'alternativa a ciò è che i dati di un nodo sono replicati solo su alcuni "amici" nel cluster, in modo che nel caso in cui il nodo non funzioni, i dati sono disponibili altrove ma senza che ogni singolo nodo debba disporre di una copia. In questo scenario, si configurerebbe il cluster in modo che il nodo1 abbia i dati replicati sui nodi 2 e 3, il nodo 2 ha i suoi dati replicati sui nodi 3 e 4, ecc., Formando una catena. In questo scenario, l'aggiunta di nodi aggiuntivi al cluster non causa un aumento rapido della quantità di comunicazione tra i nodi come avviene in uno schema tutto-tutti.