Sessioni appiccicose e replica della sessione

Question

Sto valutando il caso dell'uso di sessioni appiccicose con la replica della sessione in Tomcat. Dalla mia valutazione iniziale, ho pensato che se abilitiamo la replica della sessione, la sessione iniziata in un nodo Tomcat verrà copiata in tutti gli altri nodi Tomcat e quindi non abbiamo bisogno di una sessione appiccicosa per continuare le sessioni e la richiesta può essere ritirata da qualsiasi nodo .

Ma sembra che la replica della sessione sia in generale utilizzata con sessioni appiccicose, altrimenti l'ID di sessione deve essere modificato ogni volta che la richiesta va a qualche altro nodo. Rif: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#bind_session_after_crash_to_failover_node

Qualcuno può spiegare qual è l'uso reale della replica della sessione se devi abilitare la sessione appiccicosa? Perché allora si copriresti inutilmente la sessione su ciascun nodo, quando la richiesta con un determinato ID sessione va sempre allo stesso nodo. Potrebbe essere utile in caso di crash di un nodo, ma ciò non accade frequentemente e l'utilizzo della replica della sessione solo per questo sembra un overkill.

Answer 1

Penso che l'unico vero vantaggio sia quello di essere in grado di chiudere le istanze di Tomcat senza pensare molto. Soprattutto questo vale oggi in Cloud World (pensa alle istanze di Amazon AWS Spot) quando i nodi possono andare avanti e spegnere molto spesso. Alternativa a ciò sarebbe quella di acquistare un bilanciamento del carico decente che supporta il drenaggio del nodo. Ma i bilanciatori di carico decenti sono costosi e il drenaggio richiede tempo.

Un altro scenario a cui riesco a pensare è un carrello della spesa (scarsa implementazione) in cui gli articoli sono conservati nel HttpSession E la chiusura richiederebbe all'utente di ripercuperarli (il che probabilmente porterebbe a una vendita persa).

Ma nella maggior parte dei casi hai ragione, il vantaggio di avere sessioni appiccicose e replica della sessione è molto trascurabile.

Answer 2

Come Mindas lo ha spiegato prima:

Quando si utilizza il carico significa che hai diversi istanze di Tomcat e devi dividere i carichi.

• Se stai utilizzando la replica della sessione senza sessione appiccicosa: Immagina di avere un solo utente che utilizza la tua app Web e hai 3 istanze Tomcat. Questo utente invia diverse richieste alla tua app, quindi il LoadBalancer invierà alcune di queste richieste alla prima istanza di Tomcat e invierà alcune altre di queste richieste alla seconda istanza e altre al terzo.
• Se stai usando Sticky Session senza replica: Immagina di avere un solo utente che utilizza la tua app Web e hai 3 istanze Tomcat. Questo utente invia diverse richieste alla tua app, quindi loadBalancer invierà la prima richiesta dell'utente a una delle tre istanze Tomcat e tutte le altre richieste inviate da questo utente durante la sua sessione verranno inviate alla stessa istanza Tomcat. Durante queste richieste, se si spegne o riavvia questa istanza Tomcat (istanza Tomcat che viene utilizzata), il LoadBalancer invia le restanti richieste a un'altra istanza Tomcat che è ancora in esecuzione, ma poiché non usi la replica della sessione, l'istanza Tomcat che riceve Le restanti richieste non hanno una copia della sessione utente, quindi per questo tomcat l'utente inizia una sessione: l'utente perde la sua sessione ed è disconnesso dall'app Web sebbene l'app Web sia ancora in esecuzione.
• Se stai usando Sticky Session con la replica della sessione: Immagina di avere un solo utente che utilizza la tua app Web e hai 3 istanze Tomcat. Questo utente invia diverse richieste alla tua app, quindi loadBalancer invierà la prima richiesta dell'utente a una delle tre istanze Tomcat e tutte le altre richieste inviate da questo utente durante la sua sessione verranno inviate alla stessa istanza Tomcat. Durante queste richieste, se si spegne o riavvia questa istanza Tomcat (istanza Tomcat che viene utilizzata), il carico invia le richieste rimanenti a un'altra istanza Tomcat che è ancora in esecuzione, mentre utilizza la replica della sessione, l'istanza Tomcat che riceve le richieste rimanenti Una copia della sessione dell'utente, quindi l'utente mantiene la sua sessione: l'utente continua a sfogliare la tua app Web senza essere scollegato, l'arresto dell'istanza Tomcat non influisce sulla navigazione dell'utente.

Answer 3

Solo per chiarire i problemi di configurazione su JBoss 5.x in configurazione base "all" con mod_jk. Impostazione di sessioni appiccicose nel file Workers.Properties

 worker.list=loadbalancer

 ... nodes configuration omitted

 worker.loadbalancer.balance_workers=node1,node2
 worker.loadbalancer.sticky_session=True

non impedisce la replica della sessione. Per disattivare la replica della sessione su jboss dobbiamo impostare in $ jboss_home server your_node_name Deploy cluster jboss-cache-manager.sar meta-infe jboss-cache-manager-jboss-beans.xml cacheMode parametro a LOCAL.

Di solito nello scenario di sessione appiccicosa non vogliamo la replica della sessione, dal momento che non vogliamo overhead aggiuntivi collegati con una quantità significativa di operazioni I/O necessarie per replicare le sessioni.

In effetti, se vai con sessioni appiccicose, non è necessario eseguire JBoss in configurazione "all", potremmo usare la configurazione basata su "predefinita" o "standard".

L'unica cosa che deve essere fatta è cambiare in $ jboss_home/server/your_node_name/deploy/jbossweb.sar/server.xml:

<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">